On Wed, Oct 29, 2014 at 03:20:48PM +0200, Andy Shevchenko wrote: > On Wed, 2014-10-29 at 11:17 +0000, Mark Brown wrote: > > - how exactly has this been tested? > I don't know how it was tested before, but, besides intel-mid-dma is > somehow broken (I won't spend time to patch it), I'm using patch I > already published which converts driver to use dw_dmac driver. With it I > run tests on a loop back. How exactly do you run those tests though, what is the client driver? > > tx_dma and rx_dma > > *can* be provided by users but vanishingly few actually do so. Drivers > > must not rely on the caller doing this, the feature will be going away > > apart from anything else. If the driver is relying on this it probably > > needs to have the DMA support that's there removed as a fix and should > > be converted to use the core DMA mapping functionality in -next. > So, regarding to above what would you like me to do as next step? Looking at map_dma_buffers() it's probably actually safe since it checks that the message has is_dma_mapped set which virtually no clients will do. However this means that we're not bothering to DMA almost all the time which is silly - I'd like to see the driver converted to provide a can_dma() operation and let the core worry about mapping, that will mean a substantial performance win for most clients.
Attachment:
signature.asc
Description: Digital signature
