public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
Date: Thu, 21 Jul 2011 12:29:20 +0100	[thread overview]
Message-ID: <20110721112920.GM26574@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CABb+yY2obv5JMBiRSXS-4tSCYX+7nVVaA0Q7gurA+NndrGVuvA@mail.gmail.com>

On Thu, Jul 21, 2011 at 02:44:28PM +0530, Jassi Brar wrote:
> On Thu, Jul 21, 2011 at 1:41 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Thu, Jul 21, 2011 at 12:47:49AM +0530, Jassi Brar wrote:
> >> On Wed, Jul 20, 2011 at 4:16 PM, Boojin Kim <boojin.kim@samsung.com> wrote:
> >> > + ? ? ? ? ? ? ? if (slave_config->direction == DMA_TO_DEVICE) {
> >> > + ? ? ? ? ? ? ? ? ? ? ? if (slave_config->dst_addr)
> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? peri->fifo_addr = slave_config->dst_addr;
> >> > + ? ? ? ? ? ? ? ? ? ? ? if (slave_config->dst_addr_width)
> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? peri->burst_sz = __ffs(slave_config->dst_addr_width);
> >> > + ? ? ? ? ? ? ? } else if (slave_config->direction == DMA_FROM_DEVICE) {
> >> > + ? ? ? ? ? ? ? ? ? ? ? if (slave_config->src_addr)
> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? peri->fifo_addr = slave_config->src_addr;
> >> > + ? ? ? ? ? ? ? ? ? ? ? if (slave_config->src_addr_width)
> >> > + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? peri->burst_sz = __ffs(slave_config->src_addr_width);
> >> > + ? ? ? ? ? ? ? }
> >> PL330 has fixed channels to peripherals.
> >> So FIFO addresses(burst_sz too?) should already be set via platform data.
> >> Client drivers shouldn't bother.
> >
> > That's utter crap, and isn't what the DMA engine API is about.
> >
> > The above looks correctly implemented. ?Slave DMA engine users are
> > supposed to supply the device DMA register address via this
> > DMA_SLAVE_CONFIG call. ?Doing this via platform data for the DMA
> > device is braindead.
> 
> Rather than have 32 client drivers expect fifo_address from the
> platform and then
> provide to the DMAC, IMHO it is better for a single driver(DMAC) to
> get 32 addresses
> from the platform.
> Esp when the DMAC driver already expect similar h/w parameter -- *direction*.

Conversely, when a platform doesn't know where the FIFOs are because
they're located inside the actual devices, and the device driver does,
then it makes much more sense for the device driver to provide the
DMA engine with the bus address of that.

Does your hardware have a hardware block from the device itself containing
all the systems FIFOs ?

> I don't understand why is 'fifo_address' a property much different
> than 'direction' of the channel ?

Some channels can do memory-to-peripheral and peripheral-to-memory
transfers.  Some peripherals provide a single set of DMA request/ack
lines to perform this function.  Some peripherals have different
addresses for the TX and RX FIFOs within the device.

> If a channel is flexible enough to change it's 'fifo_address', most
> probably it could also change direction of transfers.

There are DMA engines and setups where that's true.

>  So, why do we want to take seriously 'fifo_address' provided by the
> client drivers and not the 'direction' ?

The direction in the DMA slave config call I believe to be an annoying
overdesign which shouldn't be there - the DMA slave config call should
configure the DMA channel for the peripherals characteristics.

The actual channel direction should be setup at preparation time along
with the DMA buffer mapping etc.

  parent reply	other threads:[~2011-07-21 11:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-20 10:46 [PATCH V4 00/13] To use DMA generic APIs for Samsung DMA Boojin Kim
2011-07-20 10:46 ` [PATCH V4 01/13] DMA: PL330: Add support runtime PM for PL330 DMAC Boojin Kim
2011-07-20 18:35   ` Jassi Brar
2011-07-20 10:46 ` [PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command Boojin Kim
2011-07-20 19:17   ` Jassi Brar
2011-07-21  4:13     ` Boojin Kim
2011-07-21  5:00       ` Jassi Brar
2011-07-21  6:34         ` Boojin Kim
2011-07-21  7:31           ` Jassi Brar
2011-07-21  8:11     ` Russell King - ARM Linux
2011-07-21  9:14       ` Jassi Brar
2011-07-21 10:23         ` Linus Walleij
2011-07-21 14:28           ` Jassi Brar
2011-07-21 15:28             ` Russell King - ARM Linux
2011-07-22 13:59             ` Linus Walleij
2011-07-21 11:29         ` Russell King - ARM Linux [this message]
2011-07-21 15:12           ` Jassi Brar
2011-07-21 15:23             ` Russell King - ARM Linux
2011-07-21 15:56               ` Jassi Brar
2011-07-21 16:02                 ` Russell King - ARM Linux
2011-07-22  5:42   ` Jassi Brar
2011-07-25  2:10     ` Boojin Kim
2011-07-20 10:46 ` [PATCH V4 03-2/13] DMA: PL330: Add DMA_CYCLIC capability Boojin Kim
2011-07-20 10:46 ` [PATCH V4 05/13] ARM: SAMSUNG: Add common DMA operations Boojin Kim
2011-07-20 16:04 ` [PATCH V4 00/13] To use DMA generic APIs for Samsung DMA Kukjin Kim
2011-07-22 12:07 ` Koul, Vinod

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=20110721112920.GM26574@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox