On Fri, Apr 12, 2019 at 12:46:44PM +0200, Lukas Wunner wrote:
> On Thu, Apr 11, 2019 at 11:02:26PM +0200, Noralf Trønnes wrote:
> > Den 11.04.2019 20.18, skrev Lukas Wunner:

> > > Note that spi_map_buf() already splits every transfer's sglist into
> > > segments that are smaller than ctlr->max_dma_len.  Now all that needs
> > > to be done is to amend spi-bcm2835.c to iterate over the sglist
> > > and transmit it in portions which do not exceed 65535.  Addressing the
> > > problem at this lower level would drastically reduce the overhead
> > > compared to the approach in the present patch and hence appears to be
> > > more recommendable.

> > In a previous version of this I suggested to Meghana to put this in the
> > driver, but Mark wanted it in the core.

> Do you have a link to these comments of Mark?  The first version of
> this patchset that I have here is v2 of March 2018 and it already
> uses spi_split_transfers_maxsize().  I've never seen a version which
> splits the sglist in spi-bcm2835.c (instead of splitting the transfers
> in spi.c, which, again, is significantly more expensive).

The basic theory is that we shouldn't be open coding the same handling
in multiple drivers, they should just be able to declare their
capabilities and have the core handle things as far as possible.  Since
we're already iterating over the whole message I'd be surprised if there
were a particularly big hit in cases where we don't need to split things
out, though obviously that's not been tested yet.

There have also been discussions in the past about pre-cooking some of
the messages so that if the client is sending the same thing a lot (or
things that vary only by data) we can do a lot of the validation one
time which would help.