On Fri, May 31, 2013 at 2:31 AM, Nicolas Ferre <nicolas.fe...@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.desroc...@atmel.com : >>>>> >>>>> From: Ludovic Desroches <ludovic.desroc...@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 <plagn...@jcrosoft.com> >>>>> Signed-off-by: Ludovic Desroches <ludovic.desroc...@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 _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
