All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Jassi Brar <jassisinghbrar@gmail.com>
Cc: linux-samsung-soc@vger.kernel.org,
	Boojin Kim <boojin.kim@samsung.com>,
	Vinod Koul <vinod.koul@intel.com>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Dan Williams <dan.j.williams@intel.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V4 03-1/13] DMA: PL330: Support DMA_SLAVE_CONFIG command
Date: Thu, 21 Jul 2011 16:23:42 +0100	[thread overview]
Message-ID: <20110721152342.GE28942@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CABb+yY2p8VNSvhv+LjoYnunrYS8+3+841bKM-4aUsg5vNx=Mig@mail.gmail.com>

On Thu, Jul 21, 2011 at 08:42:40PM +0530, Jassi Brar wrote:
> On Thu, Jul 21, 2011 at 4:59 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Does your hardware have a hardware block from the device itself containing
> > all the systems FIFOs ?
> I am not sure what you ask, but let me say what I know.
> In this case atleast, all PL330 DMA channels have fixed source/destination
> address on the device side. So it's not like developer doesn't know
> fifo_addr here.

Even so, your approach is _conceptually_ wrong.  Think about it.

You declare your devices giving the bus address where they're located.
So, lets say for argument that your UART is located at 0x10001000.

Your UART driver knows that the FIFO register is at offset 0x20 from
the base address.  Your platform data provides the UART driver with a
DMA match function and data specific for that match function.  This
data encodes the specific DMA channel.

Now, why should you have to encode into the DMA drivers platform data
that DMA channel X has its FIFO at 0x10001020?  Not only do you have
to declare the base address of the UART but also you have to know the
offset into the UART.

Why not just let the UART driver - which knows that the base address
is 0x10001000, and the FIFO is at offset 0x20 above that - tell the
DMA driver that's where the FIFO is located?

Finally, your specific SoC may have a PL330, which may have FIFOs tied
to specific DMA request signals.  That's an _implementation_ _detail_.
That doesn't mean that's always going to be the case.

I've heard that ARM Ltd may start using the PL330 on their evaluation
boards.  They have a habbit of muxing several DMA request signals to
several different peripherals.  Will I need to rewrite all the Samsung
users of PL330 when that happens because they've decided they don't
like the DMA engine API and have gone off and done their own thing
instead?

So no, encoding the FIFO addresses into platform data for the DMA
controller is brain dead and totally the wrong thing to do.  And when
you come to moving stuff over to DT, you'll see that's even more true
there.

So don't make the mistake now.  Do things sensibly and follow the DMA
engine API.  Arrange for all your drivers to call DMA_SLAVE_CONFIG
with the address of the FIFO.

WARNING: multiple messages have this Message-ID (diff)
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 16:23:42 +0100	[thread overview]
Message-ID: <20110721152342.GE28942@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CABb+yY2p8VNSvhv+LjoYnunrYS8+3+841bKM-4aUsg5vNx=Mig@mail.gmail.com>

On Thu, Jul 21, 2011 at 08:42:40PM +0530, Jassi Brar wrote:
> On Thu, Jul 21, 2011 at 4:59 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > Does your hardware have a hardware block from the device itself containing
> > all the systems FIFOs ?
> I am not sure what you ask, but let me say what I know.
> In this case atleast, all PL330 DMA channels have fixed source/destination
> address on the device side. So it's not like developer doesn't know
> fifo_addr here.

Even so, your approach is _conceptually_ wrong.  Think about it.

You declare your devices giving the bus address where they're located.
So, lets say for argument that your UART is located at 0x10001000.

Your UART driver knows that the FIFO register is at offset 0x20 from
the base address.  Your platform data provides the UART driver with a
DMA match function and data specific for that match function.  This
data encodes the specific DMA channel.

Now, why should you have to encode into the DMA drivers platform data
that DMA channel X has its FIFO at 0x10001020?  Not only do you have
to declare the base address of the UART but also you have to know the
offset into the UART.

Why not just let the UART driver - which knows that the base address
is 0x10001000, and the FIFO is at offset 0x20 above that - tell the
DMA driver that's where the FIFO is located?

Finally, your specific SoC may have a PL330, which may have FIFOs tied
to specific DMA request signals.  That's an _implementation_ _detail_.
That doesn't mean that's always going to be the case.

I've heard that ARM Ltd may start using the PL330 on their evaluation
boards.  They have a habbit of muxing several DMA request signals to
several different peripherals.  Will I need to rewrite all the Samsung
users of PL330 when that happens because they've decided they don't
like the DMA engine API and have gone off and done their own thing
instead?

So no, encoding the FIFO addresses into platform data for the DMA
controller is brain dead and totally the wrong thing to do.  And when
you come to moving stuff over to DT, you'll see that's even more true
there.

So don't make the mistake now.  Do things sensibly and follow the DMA
engine API.  Arrange for all your drivers to call DMA_SLAVE_CONFIG
with the address of the FIFO.

  reply	other threads:[~2011-07-21 15:23 UTC|newest]

Thread overview: 52+ 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 ` 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 10:46   ` Boojin Kim
2011-07-20 18:35   ` Jassi Brar
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 10:46   ` Boojin Kim
2011-07-20 19:17   ` Jassi Brar
2011-07-20 19:17     ` Jassi Brar
2011-07-21  4:13     ` Boojin Kim
2011-07-21  4:13       ` Boojin Kim
2011-07-21  5:00       ` Jassi Brar
2011-07-21  5:00         ` Jassi Brar
2011-07-21  6:34         ` Boojin Kim
2011-07-21  6:34           ` Boojin Kim
2011-07-21  7:31           ` Jassi Brar
2011-07-21  7:31             ` Jassi Brar
2011-07-21  8:11     ` Russell King - ARM Linux
2011-07-21  8:11       ` Russell King - ARM Linux
2011-07-21  9:14       ` Jassi Brar
2011-07-21  9:14         ` Jassi Brar
2011-07-21 10:23         ` Linus Walleij
2011-07-21 10:23           ` Linus Walleij
2011-07-21 14:28           ` Jassi Brar
2011-07-21 14:28             ` Jassi Brar
2011-07-21 15:28             ` Russell King - ARM Linux
2011-07-21 15:28               ` Russell King - ARM Linux
2011-07-22 13:59             ` Linus Walleij
2011-07-22 13:59               ` Linus Walleij
2011-07-21 11:29         ` Russell King - ARM Linux
2011-07-21 11:29           ` Russell King - ARM Linux
2011-07-21 15:12           ` Jassi Brar
2011-07-21 15:12             ` Jassi Brar
2011-07-21 15:23             ` Russell King - ARM Linux [this message]
2011-07-21 15:23               ` Russell King - ARM Linux
2011-07-21 15:56               ` Jassi Brar
2011-07-21 15:56                 ` Jassi Brar
2011-07-21 16:02                 ` Russell King - ARM Linux
2011-07-21 16:02                   ` Russell King - ARM Linux
2011-07-22  5:42   ` Jassi Brar
2011-07-22  5:42     ` Jassi Brar
2011-07-25  2:10     ` Boojin Kim
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   ` Boojin Kim
2011-07-20 10:46 ` [PATCH V4 05/13] ARM: SAMSUNG: Add common DMA operations Boojin Kim
2011-07-20 10:46   ` Boojin Kim
2011-07-20 16:04 ` [PATCH V4 00/13] To use DMA generic APIs for Samsung DMA Kukjin Kim
2011-07-20 16:04   ` Kukjin Kim
2011-07-22 12:07 ` Koul, Vinod
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=20110721152342.GE28942@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=boojin.kim@samsung.com \
    --cc=dan.j.williams@intel.com \
    --cc=jassisinghbrar@gmail.com \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=vinod.koul@intel.com \
    /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.