Re: [PATCH v6 1/3] dma: at_xdmac: creation of the atmel eXtended DMA Controller driver

On Fri, Oct 17, 2014 at 08:53:57AM +0200, Ludovic Desroches wrote:

quoted

quoted

quoted

For memcpy why should we need slave_config. The system memory source and
destination width could be assumed to relastic values and then burst sizes
maxed for performance. These values make more sense for periphral where we
have to match up with the periphral

I don't tell I need slave_config. We have already talked about this. I don't
see the problem. It is only a comment, a reminder. The only information
I may need, one day, is the direction because we have to set src and dst
interfaces. At the moment, all our products are done in a way nand flash
and DDR are on the same interface so we don't have to care about
direction.
Since we don't have the direction, two solutions:
- remember this limitation for next products, that's why there is this reminder,
- change our nand driver in order to see nand as a peripheral instead of
  a memory. 

I think treating NAND as memory may not be a right model. It should be
treated as periphral with incrementing and decrementing address value. That
way you should be able to set the right properties for it.

The system memory copy is right model for memcpy.

Ok, I'll discuss of it with the atmel nand maintener. Even if there is
something to improve here, I hope it is not considered as a blocking point
to get the xdmac driver included into 3.19 because at the moment we have no
DMA on the SAMA5D4 recently introduced.

That sounds good to me, no this is non blocker here

And yes keeping the comment here is fine to warn folks.

-- 
~Vinod

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html