Re: [PATCH] dma: sun4i: expose block size and wait cycle configuration to DMA users

[Maxime Ripard]

On Fri, Mar 11, 2016 at 03:39:02PM +0530, Vinod Koul wrote:
> On Fri, Mar 11, 2016 at 10:45:52AM +0100, Boris Brezillon wrote:
> > On Fri, 11 Mar 2016 11:56:07 +0530
> > Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
> > 
> > > On Wed, Mar 09, 2016 at 12:06:27PM +0100, Boris Brezillon wrote:
> > > > On Tue, 8 Mar 2016 08:25:47 +0530
> > > > Vinod Koul <vinod.koul@xxxxxxxxx> wrote:
> > > > > 
> > > > > Why does dmaengine need to wait? Can you explain that
> > > > 
> > > > I don't have an answer for that one, but when I set WAIT_CYCLES to 1
> > > > for the NAND use case it does not work. So I guess it is somehow
> > > > related to how the DRQ line is controlled on the device side...
> > > 
> > > Is the WAIT cycle different for different usages or same for all
> > > usages/channels?
> > > 
> > 
> > In Allwinner BSP they adapt it on a per slave device basis, but since
> > DMA channels are dynamically allocated, you can't know in advance which
> > physical channel will be attached to a specific device.
> 
> And we have the correct values availble in datasheet for all usages

No, we don't.

If you look at the datasheet in question, page 169.
https://github.com/allwinner-zh/documents/blob/master/A20/A20_User_Manual_v1.4_20150510.pdf

This is the only documentation we have. And as you can see, it is very
sparse (and that's an understament).

So we cannot make that assumption, so far the values have been found
through trial and error for the devices in question.

> > Another option I considered was adding a new cell to the sun4i DT
> > binding to encode these WAIT_CYCLES and BLOCK_SIZE information. But I'm
> > not sure adding that to the DT is a good idea (not to mention that it
> > would break DT ABI again, and given the last discussions on this topic,
> > I'm not sure it's a good idea :-/).
> 
> Yes i was veering towards DT as well. This is a new property so ABI rules
> wont break as long as driver still works with old properties.

Yeah, we can always default to our current hardcoded value if the
property is missing. And since no-one is using the engine at the
moment anyway, so it's not really a big deal.

> But this nees to be property for clients and not driver. Client can then
> program these

Yes, totally. The question here is how the clients give that
information to the driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Attachment: signature.asc
Description: Digital signature