Re: [PATCH v2 05/11] drm/tinydrm: Remove tinydrm_spi_max_transfer_size()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 15, 2019 at 5:59 PM Andy Shevchenko
<andriy.shevchenko@xxxxxxxxx> wrote:
>
> On Tue, Oct 15, 2019 at 05:41:53PM +0200, Noralf Trønnes wrote:
> > Den 15.10.2019 16.32, skrev Andy Shevchenko:
> > > On Fri, Jul 19, 2019 at 05:59:10PM +0200, Noralf Trønnes wrote:
> > >> spi-bcm2835 can handle >64kB buffers now so there is no need to check
> > >> ->max_dma_len. The tinydrm_spi_max_transfer_size() max_len argument is
> > >> not used by any callers, so not needed.
> > >>
> > >> Then we have the spi_max module parameter. It was added because
> > >> staging/fbtft has support for it and there was a report that someone used
> > >> it to set a small buffer size to avoid popping on a USB soundcard on a
> > >> Raspberry Pi. In hindsight it shouldn't have been added, I should have
> > >> waited for it to become a problem first. I don't know it anyone is
> > >> actually using it, but since tinydrm_spi_transfer() is being moved to
> > >> mipi-dbi, I'm taking the opportunity to remove it. I'll add it back to
> > >> mipi-dbi if someone complains.
> > >>
> > >> With that out of the way, spi_max_transfer_size() can be used instead.
> > >>
> > >> The chosen 16kB buffer size for Type C Option 1 (9-bit) interface is
> > >> somewhat arbitrary, but a bigger buffer will have a miniscule impact on
> > >> transfer speed, so it's probably fine.
> > >
> > > This breaks the SPI PXA2xx case I'm using. The world is not a Pi:e.
> > >
> > > [  388.445752] mi0283qt spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
> > > [  388.634437] mi0283qt spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
> > > [  388.822933] mi0283qt spi-PRP0001:01: DMA disabled for transfer length 153600 greater than 65536
> > >
> > > The crucial thing is to check the transfer size against maximum DMA length
> > > of the master.
> > >
> >
> > Isn't this a spi controller driver problem?
>
> It doesn't matter. This patch made a regression. Before it worked,
> now it doesn't.

Yes this is clear.

> > spi_max_transfer_size() tells the client what the maximum transfer
> > length is. The controller driver can use ctlr->max_transfer_size if it
> > has restrictions.
>
> It might be a problem of the SPI core.
>
> > AFAIUI max_dma_len is used when splitting up the buffer for the sg table
> > in spi_map_buf().
>
> > > Please, fix.
>
> Should I send the revert?

Can we please not roll in with the cavalry before everyone had a
chance to wake up and look at this properly? It's less than 1h since
your initial bug report.

Also, you _do_ have a test patch in your inbox ...

Seriously.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux