On Tue, 2 Dec 2008, Dan Williams wrote:

On Tue, Dec 2, 2008 at 8:52 AM, Guennadi Liakhovetski
[off-list ref] wrote:

quoted

Hi Dan,

I think, there is a problem with your dma_request_channel() /
private_candidate() implementation: your current version only tries one
channel from a dma device list, which matched capabilities. If this
channel is not accepted by the client, you do not try other channels from
this device and just go to the next one...

Which dma driver are you using?

This is the idmac dmaengine driver I submitted a few weeks ago, that I am 
porting to your modified dmaengine framework. Initial version:

http://marc.info/?l=linux-arm-kernel&m=122607472721145&w=2

BTW - it does look nicer and more simple now, so, in general, I like the 
change.

The dmaengine code assumes that all
channels on a device are equal.  It sounds like there are differences
between peer-channels on the device in this case.  If the driver
registers a device per channel that should give the flexibility you
want.

Ooh... Do you really think registering 32 dma-devices is a better solution 
than allowing non-equal dma-channels? As I explained in the commit 
comment, this is a specialised Image Processing DMA Controller, and each 
its channel has a fixed role. So, each client has to get a specific 
channel.

quoted

Another problem I encountered with my framebuffer is the initialisation
order. You initialise dmaengine per subsys_initcall(), whereas the only
way to guarantee the order:

dmaengine
dma-device driver
framebuffer

hmm... can the framebuffer be moved to late_initcall?

I assumed, that one wants to register the framebuffer as early as 
possible...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer