On 07/30/2013 11:45 AM, jonsmirl at gmail.com wrote:

On Tue, Jul 30, 2013 at 1:34 PM, Stephen Warren [off-list ref] wrote:

quoted

On 07/30/2013 11:29 AM, jonsmirl at gmail.com wrote:

quoted

On Tue, Jul 30, 2013 at 1:19 PM, Stephen Warren [off-list ref] wrote:

quoted

On 07/30/2013 07:14 AM, jonsmirl at gmail.com wrote:

quoted

On Tue, Jul 30, 2013 at 6:25 AM, Mark Brown [off-list ref] wrote:

quoted

On Mon, Jul 29, 2013 at 08:30:29PM -0400, jonsmirl at gmail.com wrote:

quoted

This...
tx-dma-channel = <&pdma0 7>; /* preliminary */
rx-dma-channel = <&pdma0 6>; /* preliminary */

quoted

Probably should be
dmas = <&pdma0 7>,<&pdma0 6>;
dma-names = "tx", "rx";

It should be - the latter is the generic DMA binding.  There's a lot of
bindings in the kernel that predate that but people are currently
working to transfer over, this is one of the examples of instability
that everyone is talking about.

Is something similar to this possible in device tree syntax?
dmas =  <"tx" &pdma0 7>,  <"rx"  &pdma0 6>;

I /think/ you can physically write that in *.dts, or something very
similar; with the strings outside the <>:

dmas = "tx", <&pdma0 7>, "rx", <&pdma0 6>;

However, there's been strong push-back (i.e. doing that has not been
allowed at all) on attempting to mix variable-length strings and
fixed-length/alignment integer cells in the same property. This is
primarily because you then can't ensure that the integer cell data is
aligned in the DTB (dtc and/or the DTB format spec does/requires/allows

The PowerPC FDT doc says that strings are indirected into a string
table. So they aren't variable length in the data structures.

Do you have a link to the document; I'm not sure which one you mean.

I was wondering how dmas = "tx", "rx" was implemented. It is two
pointers into the indirect block. So this should work, there is no
variable length data to worry about in the structure.

If you look at of_property_read_string_index() in drivers/of/base.c,
you'll see that it expects the strings to just be packed together inline.

What you say may be correct for node and property names, just not
property values.