lkml.org 
[lkml]   [2014]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Documentation: dmaengine: Add a documentation for the dma controller API
On 07/31/2014 09:44 AM, Maxime Ripard wrote:
[...]
> - Having to set device_slave_caps or not?

Yes. This should in my opinion be mandatory for new drivers. One of the
issues with the DMAengine API is that it is really hard to write generic
drivers that do not already know about the capabilities of the DMA
controller. E.g. if you have a peripheral that is used on SoC A it assumes
that the DMA controller it is connected to has the capabilities of the DMA
controller in SoC A. If the same peripheral is now used on SoC B with a DMA
controller with different capabilities this often ends up with ugly ifdefery
in the peripheral driver. The peripheral driver shouldn't have to know which
specific DMA controller it is connected to (It's a bit as if a GPIO consumer
needed to know which GPIO controller is connected to). We got away with the
current approach since there is not that much diversity in the mixing of
peripherals and DMA controllers (each vendor pretty has their own DMA
controller which it uses for their own peripherals). But with more recent
code consolidation we are on a path to generic DMA support within subsystem
frameworks (there is generic DMA support for audio, there is generic DMA
support for SPI and I also have a (currently) out of tree patch for generic
DMA support for IIO). Also these generic drivers need to be able to discover
the capabilities of the DMA controller to be able to make the right decisions.

- Lars


\
 
 \ /
  Last update: 2014-07-31 15:21    [W:0.111 / U:1.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site