From: "sudheer.v" <open.sudheer@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Vinod <vkoul@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
Russell King <linux@armlinux.org.uk>,
Dan Williams <dan.j.williams@intel.com>,
Jiri Slaby <jslaby@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Michael Moese <mmoese@suse.de>,
Hendrik Brueckner <brueckner@linux.vnet.ibm.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
Philippe Ombredanne <pombredanne@nexb.com>,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org,
Sudheer V <sudheer.veliseti@aspeedtech.com>,
ShivahShankar Shakarnarayan rao
<shivahshankar.shankarnarayanrao@aspeedtech.com>
Subject: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500
Date: Fri, 19 Oct 2018 12:41:56 +0530 [thread overview]
Message-ID: <20181019071154.GE13642@Pilot130> (raw)
On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> >
> > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > use a dedicated DMA engine.
> >
> > Then I see no reason for it to use dmaengine APIs. The framework allows
> > people to share a controller for many clients, but if you have dedicated
> > one then you may use it directly
>
> Well... the engine is shared by a few UARTs, they have dedicated rings
> but there's a common set of regs for interrupt handling etc.
>
> That said, I still think it could be contained within a UART driver,
> there's little benefit in adding the framework overhead, esp since
> these are really weak cores, any overhead will be felt.
>
> Ben.
>
> > > It's unclear whether it should be split into two drivers, or just have
> > > the serial driver directly use the dma engine since that engine is
> > > dedicated in HW to only work on those UARTs and nothing else...
> > >
> > > Cheers,
> > > Ben.
Initially we wanted to have a single driver,
however we had an informal discussion with one of the maintainer
and based on the feedback, followed the Linux DMA and UART architecture.
If this seperate DMA-engine driver adds more overhead than benifit,
we will merge them into a single UART driver and resubmitt the patches.
Vinod,
can this dma-controller driver sit under dma subsystem?.
or better to move it under UART framework.
Thank you.
-- Sudheer
WARNING: multiple messages have this Message-ID (diff)
From: sudheer.v <open.sudheer@gmail.com>
To: linux-aspeed@lists.ozlabs.org
Subject: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500
Date: Fri, 19 Oct 2018 12:41:56 +0530 [thread overview]
Message-ID: <20181019071154.GE13642@Pilot130> (raw)
In-Reply-To: <a3fecf7913d6a85a6294afbc5a1a18b7714d6756.camel@kernel.crashing.org>
On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> >
> > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > use a dedicated DMA engine.
> >
> > Then I see no reason for it to use dmaengine APIs. The framework allows
> > people to share a controller for many clients, but if you have dedicated
> > one then you may use it directly
>
> Well... the engine is shared by a few UARTs, they have dedicated rings
> but there's a common set of regs for interrupt handling etc.
>
> That said, I still think it could be contained within a UART driver,
> there's little benefit in adding the framework overhead, esp since
> these are really weak cores, any overhead will be felt.
>
> Ben.
>
> > > It's unclear whether it should be split into two drivers, or just have
> > > the serial driver directly use the dma engine since that engine is
> > > dedicated in HW to only work on those UARTs and nothing else...
> > >
> > > Cheers,
> > > Ben.
Initially we wanted to have a single driver,
however we had an informal discussion with one of the maintainer
and based on the feedback, followed the Linux DMA and UART architecture.
If this seperate DMA-engine driver adds more overhead than benifit,
we will merge them into a single UART driver and resubmitt the patches.
Vinod,
can this dma-controller driver sit under dma subsystem?.
or better to move it under UART framework.
Thank you.
-- Sudheer
WARNING: multiple messages have this Message-ID (diff)
From: "sudheer.v" <open.sudheer@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Vinod <vkoul@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
Russell King <linux@armlinux.org.uk>,
Dan Williams <dan.j.williams@intel.com>,
Jiri Slaby <jslaby@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Michael Moese <mmoese@suse.de>,
Hendrik Brueckner <brueckner@linux.vnet.ibm.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
Philippe Ombredanne <pombredanne@nexb.com>,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradea
Subject: Re: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500
Date: Fri, 19 Oct 2018 12:41:56 +0530 [thread overview]
Message-ID: <20181019071154.GE13642@Pilot130> (raw)
In-Reply-To: <a3fecf7913d6a85a6294afbc5a1a18b7714d6756.camel@kernel.crashing.org>
On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> >
> > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > use a dedicated DMA engine.
> >
> > Then I see no reason for it to use dmaengine APIs. The framework allows
> > people to share a controller for many clients, but if you have dedicated
> > one then you may use it directly
>
> Well... the engine is shared by a few UARTs, they have dedicated rings
> but there's a common set of regs for interrupt handling etc.
>
> That said, I still think it could be contained within a UART driver,
> there's little benefit in adding the framework overhead, esp since
> these are really weak cores, any overhead will be felt.
>
> Ben.
>
> > > It's unclear whether it should be split into two drivers, or just have
> > > the serial driver directly use the dma engine since that engine is
> > > dedicated in HW to only work on those UARTs and nothing else...
> > >
> > > Cheers,
> > > Ben.
Initially we wanted to have a single driver,
however we had an informal discussion with one of the maintainer
and based on the feedback, followed the Linux DMA and UART architecture.
If this seperate DMA-engine driver adds more overhead than benifit,
we will merge them into a single UART driver and resubmitt the patches.
Vinod,
can this dma-controller driver sit under dma subsystem?.
or better to move it under UART framework.
Thank you.
-- Sudheer
WARNING: multiple messages have this Message-ID (diff)
From: open.sudheer@gmail.com (sudheer.v)
To: linux-arm-kernel@lists.infradead.org
Subject: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500
Date: Fri, 19 Oct 2018 12:41:56 +0530 [thread overview]
Message-ID: <20181019071154.GE13642@Pilot130> (raw)
In-Reply-To: <a3fecf7913d6a85a6294afbc5a1a18b7714d6756.camel@kernel.crashing.org>
On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> >
> > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > use a dedicated DMA engine.
> >
> > Then I see no reason for it to use dmaengine APIs. The framework allows
> > people to share a controller for many clients, but if you have dedicated
> > one then you may use it directly
>
> Well... the engine is shared by a few UARTs, they have dedicated rings
> but there's a common set of regs for interrupt handling etc.
>
> That said, I still think it could be contained within a UART driver,
> there's little benefit in adding the framework overhead, esp since
> these are really weak cores, any overhead will be felt.
>
> Ben.
>
> > > It's unclear whether it should be split into two drivers, or just have
> > > the serial driver directly use the dma engine since that engine is
> > > dedicated in HW to only work on those UARTs and nothing else...
> > >
> > > Cheers,
> > > Ben.
Initially we wanted to have a single driver,
however we had an informal discussion with one of the maintainer
and based on the feedback, followed the Linux DMA and UART architecture.
If this seperate DMA-engine driver adds more overhead than benifit,
we will merge them into a single UART driver and resubmitt the patches.
Vinod,
can this dma-controller driver sit under dma subsystem?.
or better to move it under UART framework.
Thank you.
-- Sudheer
WARNING: multiple messages have this Message-ID (diff)
From: "sudheer.v" <open.sudheer@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Vinod <vkoul@kernel.org>, Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>,
Russell King <linux@armlinux.org.uk>,
Dan Williams <dan.j.williams@intel.com>,
Jiri Slaby <jslaby@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Michael Moese <mmoese@suse.de>,
Hendrik Brueckner <brueckner@linux.vnet.ibm.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
Philippe Ombredanne <pombredanne@nexb.com>,
dmaengine@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org,
Sudheer V <sudheer.veliseti@aspeedtech.com>,
ShivahShankar Shakarnarayan rao
<shivahshankar.shankarnarayanrao@aspeedtech.com>
Subject: Re: [[PATCH] 8/9] DMA-UART-Driver-for-AST2500
Date: Fri, 19 Oct 2018 12:41:56 +0530 [thread overview]
Message-ID: <20181019071154.GE13642@Pilot130> (raw)
In-Reply-To: <a3fecf7913d6a85a6294afbc5a1a18b7714d6756.camel@kernel.crashing.org>
On Fri, Oct 19, 2018 at 10:32:24AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2018-10-18 at 15:25 +0530, Vinod wrote:
> >
> > > It's not a dmaengine driver. It's a serial UART driver that happens to
> > > use a dedicated DMA engine.
> >
> > Then I see no reason for it to use dmaengine APIs. The framework allows
> > people to share a controller for many clients, but if you have dedicated
> > one then you may use it directly
>
> Well... the engine is shared by a few UARTs, they have dedicated rings
> but there's a common set of regs for interrupt handling etc.
>
> That said, I still think it could be contained within a UART driver,
> there's little benefit in adding the framework overhead, esp since
> these are really weak cores, any overhead will be felt.
>
> Ben.
>
> > > It's unclear whether it should be split into two drivers, or just have
> > > the serial driver directly use the dma engine since that engine is
> > > dedicated in HW to only work on those UARTs and nothing else...
> > >
> > > Cheers,
> > > Ben.
Initially we wanted to have a single driver,
however we had an informal discussion with one of the maintainer
and based on the feedback, followed the Linux DMA and UART architecture.
If this seperate DMA-engine driver adds more overhead than benifit,
we will merge them into a single UART driver and resubmitt the patches.
Vinod,
can this dma-controller driver sit under dma subsystem?.
or better to move it under UART framework.
Thank you.
-- Sudheer
next reply other threads:[~2018-10-19 7:11 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-19 7:11 sudheer.v [this message]
2018-10-19 7:11 ` [[PATCH] 8/9] DMA-UART-Driver-for-AST2500 sudheer.v
2018-10-19 7:11 ` sudheer.v
2018-10-19 7:11 ` sudheer.v
2018-10-19 7:11 ` sudheer.v
-- strict thread matches above, loose matches on Subject: below --
2018-10-26 7:07 sudheer.v
2018-10-26 7:07 ` sudheer.v
2018-10-26 7:07 ` sudheer.v
2018-10-26 7:07 ` sudheer.v
2018-10-26 7:07 ` sudheer.v
2018-10-20 16:26 Vinod Koul
2018-10-20 16:26 ` Vinod
2018-10-20 16:26 ` Vinod
2018-10-20 16:26 ` Vinod
2018-10-20 16:26 ` Vinod
2018-10-18 23:32 Benjamin Herrenschmidt
2018-10-18 23:32 ` Benjamin Herrenschmidt
2018-10-18 23:32 ` Benjamin Herrenschmidt
2018-10-18 23:32 ` Benjamin Herrenschmidt
2018-10-18 23:32 ` Benjamin Herrenschmidt
2018-10-18 9:55 Vinod Koul
2018-10-18 9:55 ` Vinod
2018-10-18 9:55 ` Vinod
2018-10-18 9:55 ` Vinod
2018-10-18 9:55 ` Vinod
2018-10-17 8:56 Benjamin Herrenschmidt
2018-10-17 8:56 ` Benjamin Herrenschmidt
2018-10-17 8:56 ` Benjamin Herrenschmidt
2018-10-17 8:56 ` Benjamin Herrenschmidt
2018-10-17 8:56 ` Benjamin Herrenschmidt
2018-10-17 6:05 Vinod Koul
2018-10-17 6:05 ` Vinod
2018-10-17 6:05 ` Vinod
2018-10-17 6:05 ` Vinod
2018-10-17 6:05 ` Vinod
2018-10-17 4:11 sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:11 [[PATCH] 4/9] Documentation-DTbindings-DMA-controller-of-AST2500 sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:11 ` sudheer.v
2018-10-17 4:10 [[PATCH] 2/9] Defconfig-changes-for-DMA-UART-of-AST2500 sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 [[PATCH] 1/9] DT-changes-for-DMA-UART-of-AST2500 sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 [[PATCH] 0/9] *** DMA support for UART in ASPEED's AST2500 *** sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-17 4:10 ` sudheer.v
2018-10-25 14:48 ` Rob Herring
2018-10-25 14:48 ` Rob Herring
2018-10-25 14:48 ` Rob Herring
2018-10-25 14:48 ` Rob Herring
2018-10-26 7:23 ` sudheer.v
2018-10-26 7:23 ` sudheer.v
2018-10-26 7:23 ` sudheer.v
2018-10-26 7:23 ` sudheer.v
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181019071154.GE13642@Pilot130 \
--to=open.sudheer@gmail.com \
--cc=andrew@aj.id.au \
--cc=benh@kernel.crashing.org \
--cc=borntraeger@de.ibm.com \
--cc=brueckner@linux.vnet.ibm.com \
--cc=dan.j.williams@intel.com \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=joel@jms.id.au \
--cc=jslaby@suse.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=mmoese@suse.de \
--cc=pombredanne@nexb.com \
--cc=robh+dt@kernel.org \
--cc=shivahshankar.shankarnarayanrao@aspeedtech.com \
--cc=sudheer.veliseti@aspeedtech.com \
--cc=tglx@linutronix.de \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.