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.
Attachment:
signature.asc
Description: PGP signature
