On Wednesday 27 June 2012, Vinod Koul wrote:

On Tue, 2012-06-26 at 20:27 +0000, Arnd Bergmann wrote:

quoted

On Tuesday 26 June 2012, Vinod Koul wrote:

quoted

On Tue, 2012-06-26 at 14:59 +0000, Arnd Bergmann wrote:

If we instead modify the dmaengine code itself to know about DT
rather than wrapping around it, we would not need this filter
function, but we should still have a probe() function that is
called by dmaengine code to interpret the data that is specific
to one dmaengine driver.

I was hoping we can have dmaengine binding, that way dmaengine core code
knows about what to do when some client requests a channel.

quoted

quoted

IMHO dmaengine driver should *not* know anything about mapping. By
mapping I refer to platform information which tells me which client can
use which channel from which dmac.

Agreed too. That information shoudd be part of the slave device-node
in DT, as I have argued in this thread already. The slave device driver
does not need to care about the format or the contents of it,
but we need some code to interpret the contents. From all I can tell,
the structure of this data cannot be completely generic because of
all the special cases, so the code to interpret it would live in the
probe() function I mentioned about that the dmaengine driver provides.

rather than slave driver, why dont we keep this binding within
dmaengine. That would make slave and clients completely independent.

Sorry, I believe I was just using the wrong terminology, and what I named
the slave here would just be the client.

This may have contributed to a lot of confusion before, so let's make
sure I use the right terms now:

a) slave == dmac == dmaengine driver
b) client == device driver, e.g. mmc
c) common code == dmaengine layer

Is this correct?

quoted

quoted

quoted

I think encoding a description for a dma request in a single number is
the last thing we want to do here. We've tried that with IRQ and GPIO
numbers and it got us into a huge mess that will need a long time to
get out of.

No i wasn't thinking of a number. The mapping shouldn't be a global
number at all, though that is a very easy but not very scalable
solution.
We need to take care of 1:1 mapping of client and channels as well as
many:1  cases as well. A single global number cannot represent that
properly.

My idea is platform gives this information to dmaengine. Clients and
dmaengine driver do not worry about it. That also paves way for arch
independent clients and drivers.

IMO the platform should have no part in this. I absolutely want to
get rid of any platform-specific hardcoded tables in the kernel for
stuff that can easily be run-time detected from the device tree.
There are cases where hard-coding in the kernel is easier, but I don't
think this is one of them.

Again, you got me wrong. We don't want any hardcoded table is kernel.
The information in table should come from whatever way that platform can
give me. For your case it should be DT.

Ok, good.

We can have the map of which client can use which channel as DT binding
of dmaengine core. So dmaengine can easily arbitrate about channel
requests. Again this mapping information is not some even linux
independent.

Why can't it be OS independent?

Do you mean there must be a global table, or are you ok with putting
the information about a channel into the device that uses the channel,
as we do for most other subsystems (IRQ, GPIO, pinctrl, ...).
If not, what is the problem with that approach?

	Arnd