Re: [PATCH v1 0/2] spi: dw-mid: fix simplex DMA transfers

[Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>]

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 <andriy.shevchenko@xxxxxxxxx>
Intel Finland Oy

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html