On 05/04/2012 09:56 AM, Arnd Bergmann wrote:
> On Monday 30 April 2012, Jon Hunter wrote:
>> From: Jon Hunter <jon-hunter@xxxxxx>
>>
>> This is based upon the work by Benoit Cousson [1] and Nicolas Ferre [2]
>> to add some basic helpers to retrieve a DMA controller device_node and the
>> DMA request/channel information.
...
>> Forgetting device tree for now, some drivers use strings to represent a
>> DMA channel instead of using an integer. I assume that these drivers then
>> employ some sort of look-up table to convert the string into a channel
>> number/index that the hardware understands. If this assumption is correct
>> then when moving to a device tree implementation having such look-up tables
>> in the driver should no longer be necessary as the device tree will provide
>> the mapping of channel index/number to the device. Furthermore, it makes
>> sense that device tree uses integers to represent channel as opposed to
>> strings to save the driver having to convert the string into a integer at
>> some later stage.
...
> I think you can actually use strings, too, as long as you use a fixed number
> of cells.
>
> Wouldn't something like this work:?
...
> some-device {
> compatible = "something";
> dmas = <&dma-controller1>, "some-dma",
> <&dma-controller2 1 2 3>;
> }
The idea of mixing integer cells and strings in the same property has
come up before for other bindings, but been rejected. IIRC, there are
issues such as alignment of the integers after the string (they are not
aligned in the DTB) which can cause unaligned accesses, and perhaps
other issues I fail to recall - perhaps because it's no longer possible
to skip from the &dma-controller1 phandle to the &dma-controller2
phandle using #dma-cells, but rather you need to use strlen() and hence
involve the DMA controller driver itself (otherwise, how do you know
it's a string?) rather than just the core DMA property parsing code.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
