[PATCH] dmaengine: at_hdmac: add device tree probe
Nicolas Ferre
nicolas.ferre at atmel.com
Tue Aug 16 12:33:28 EDT 2011
Le 07/08/2011 06:09, Grant Likely :
> On Fri, Aug 05, 2011 at 01:58:40PM +0100, Nicolas Ferre wrote:
>> Add device tree probe support for atmel at_hdmac DMA driver.
>> Bindings are added to specify the number of channels that the implementation of
>> the controller actually has. They also allow to tell if the peripherals/DMA
>> transfer is supported by the IP.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre at atmel.com>
>> ---
>> .../devicetree/bindings/dma/atmel-hdmac.txt | 23 +++++++++
>> drivers/dma/at_hdmac.c | 51 ++++++++++++++++----
>> 2 files changed, 65 insertions(+), 9 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/dma/atmel-hdmac.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/atmel-hdmac.txt b/Documentation/devicetree/bindings/dma/atmel-hdmac.txt
>> new file mode 100644
>> index 0000000..0e48553
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/atmel-hdmac.txt
>> @@ -0,0 +1,23 @@
>> +* Atmel Direct Memory Access Controller
>> +
>> +Required properties:
>> +- compatible: Should be "atmel,<chip>-hdmac"
>> +- reg: Should contain DMA registers location and length
>> +- interrupts: Should contain DMA interrupt
>> +- atmel,hdmac-nr-channels: Should contain number of channels
>> + available in the controller
>> +
>> +Optional properties:
>> +- atmel,hdmac-cap-memcpy: Chip can do memory to memory transfers
>> +- atmel,hdmac-cap-slave: Chip can do peripherals/memory transfers
>
> Heh, ignore my comments on the other patch about missing documentation
> for the dma engine. :-)
>
> Otherwise the patch looks pretty good.
[..]
Grant, Vinod,
Don't you think it would make sense to generalize nr-channels and maybe
also the capabilities properties for other dmaengine drivers?
I have seen other dmaengine drivers taking the number of channels from
platform data so that would make sense.
It would be new dmaengine device tree properties, but on the other hand,
I do not know if code can also be centralized for handling of those
properties... maybe it is better to let drivers deal with them if
required...
Your thoughts?
Best regards,
--
Nicolas Ferre
More information about the linux-arm-kernel
mailing list