On Wed, 2014-10-29 at 22:15 +0000, Mark Brown wrote: > 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?
I have a hack patch to register the spidev and I run internal test suite written by Mika Westerberg. It uses a loop back mode to send and check data. > > > > 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. That is exactly my intention with the additional thing — to use dw_dmac instead of intel-mid-dma. -- Andy Shevchenko <[email protected]> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
