[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E4A9BD8.1040302@atmel.com>
Date: Tue, 16 Aug 2011 18:33:28 +0200
From: Nicolas Ferre <nicolas.ferre@...el.com>
To: Grant Likely <grant.likely@...retlab.ca>, vinod.koul@...el.com
CC: linux-arm-kernel@...ts.infradead.org,
devicetree-discuss@...ts.ozlabs.org, dan.j.williams@...el.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dmaengine: at_hdmac: add device tree probe
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@...el.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists