On Thursday 14 June 2012, Jon Hunter wrote:

On 06/14/2012 06:48 AM, Arnd Bergmann wrote:

quoted

On Wednesday 13 June 2012, Jon Hunter wrote:

quoted

So in that case, I don't see why the first cell after the phandle could
not be an index which could be either a direction or request-id and then
the next cell after that be a secondary match variable.

So simple case with just a index (either req-id or direction) ...

dmas = <&dmac0 index>

More complex case ...

dmas = <&dmac0 index match>

For example, for OMAP index = req-id and match = direction ...

dmas = <&dmac0 req-id direction>

Or am I way off the page?

The intention was instead to remove the need for the /index/ in those
cases, because having a client-specific index in here makes it inconsistent
with other similar bindings (reg, interrupts, gpios, ...) that people
are familiar with. They use an implicit index by counting the
fields in the respective properties.

So maybe "index" was not the right term to use here. What I meant was
that this is really the req/chan-id associated with this device. It is
not an arbitrary index that in turn gets resolved into the req-id. So in
other words, just like gpio where you have the gpio number, here you
have the dma req-id.

Ok, we're on the same page then.

I got confused because you were quoting Stephen's example of

multiple dmacs:
dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>;

which used an aribitrary slave-side index (0, 1), the dmaengine phandle
and the dmaengine specific request id (xxx,yyy,zzz).

Leaving out the index means that we require at least one of "dma-names"
strings or adding the direction.

quoted

The existing method we have for avoiding index numbers is to use
named fields, like

	dmas = <&dmac0 matchA>, <dmac1 matchB>, <dmac2 matchC>;
	dma-names = "rx", "rx", "tx";

This is similar to how we use named interrupt and mmio resources, but
it requires that we always request the dma lines by name, which is
slightly more complex than we might want it to be.

Ok, but how do you get the req-id from the above binding? Doesn't it
need to be stored there somewhere even for the most simplest case? Or
are you saying that in this case you are just returning a name and the
dma driver resolves that into a req-id?

the req-id is what I called matchA, matchB, matchC here, it could be
a set of multiple cells, the number of which gets determined by the
dmaengine's #dma-cells property.

quoted

Because the vast majority of cases just use a single channel, or one
channel per direction, my idea was to encode the direction in the
dmas property, which lets us request a dma channel by direction from
the driver side, without explicitly encoding the name.

Yes, thats fine and so the direction is really the match criteria in
this case.

No, it's not :(

quoted

This would let us handle the following cases very easily:

1. one read-write channel

	dmas = <&dmac 0x3 match>;

Where 0x3 is the req-id? Just to confirm ;-)

Why not have match after the phandle to be consistent with the simple
example using name fields above?

The 0x3 is the direction, 1 for read, 2 for write, and 3 for read-write
in this example. Sorry for being unclear.

The direction has to come before the dma-engine specific request ID
data so that the common code can interpret it, while the variable-length
data after it is only interpreted by the dmaengine driver.

	Arnd