[PATCH 3/3] at_hdmac: add FIFO configuration parameter to DMA DT binding

[Olof Johansson]

On Fri, May 31, 2013 at 2:31 AM, Nicolas Ferre <nicolas.ferre at atmel.com> wrote:
> On 31/05/2013 11:16, Ludovic Desroches :
>>
>> On Thu, May 30, 2013 at 06:39:36PM +0200, Jean-Christophe PLAGNIOL-VILLARD
>> wrote:
>>>
>>> On 18:32 Thu 30 May     , Nicolas Ferre wrote:
>>>>
>>>> On 30/05/2013 18:08, ludovic.desroches at atmel.com :
>>>>>
>>>>> From: Ludovic Desroches <ludovic.desroches at atmel.com>
>>>>>
>>>>> For most devices the FIFO configuration is the same i.e. when half FIFO
>>>>> size is
>>>>> available/filled, a source/destination request is serviced. But USART
>>>>> devices
>>>>> have to do it when there is enough space/data available to perform a
>>>>> single
>>>>> AHB access so the ASAP configuration.
>>>>>
>>>>> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com>
>>>>> Signed-off-by: Ludovic Desroches <ludovic.desroches at atmel.com>
>>>>
>>>>
>>>> Clear and neat: thanks Ludo.
>>>
>>>
>>> agreed
>>>
>>> can we apply this via AT91 as this depends on some cleanup I did on DT
>>> and
>>> could result on some nigthmware conflict
>>>
>>
>> In fact, I am not sure it's the best solution. I have noticed that there
>> is a
>> conflict with a patch sent by Nicolas (dmaengine: at_hdmac: extend
>> hardware
>> handshaking interface identification) which is already in Vinod's tree but
>> which is not present on Jean-Christophe's cleanup tree on which I based
>> these
>> patches.
>>
>> Moreover this patch doesn't use macros introduced by Nicolas' patch. I may
>> update it and it should go through Vinod's tree with a dependence on patch
>> 1/3.
>>
>> What's your point of view?
>
>
> Indeed. Another option could be to push patches 1 and 3 in dmaengine's tree
> and make the 2nd patch go through arm-soc with a dependency on slave-dma GIT
> tree (it seems it is an usual patern).
>
> Arnd, Jean-Christophe, what do you think?

I'm not sure patch 1 needs to go through the dma-engine tree? Sure,
it's a dma-related header file but it's only used to craft the device
tree in patch 2, it doesn't affect the driver.

(Arnd has comments on the patch that should be resolved though).


-Olof