Den 11.04.2019 18.42, skrev Noralf Trønnes: > From: Meghana Madhyastha <meghana.madhyastha@xxxxxxxxx> > > Some drivers like spi_bcm2835 have a max size on DMA transfers. Work > around this by splitting up the transfer if necessary. > > ->max_transfer_size is MAX_INT if the driver doesn't set it, so this change > will only affect drivers that set the value. > > Signed-off-by: Meghana Madhyastha <meghana.madhyastha@xxxxxxxxx> > Signed-off-by: Noralf Trønnes <noralf@xxxxxxxxxxx> > --- > drivers/spi/spi.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > index 05875e63be43..22bc658032b3 100644 > --- a/drivers/spi/spi.c > +++ b/drivers/spi/spi.c > @@ -1299,6 +1299,11 @@ static void __spi_pump_messages(struct spi_controller *ctlr, bool in_kthread) > > trace_spi_message_start(ctlr->cur_msg); > > + ret = spi_split_transfers_maxsize(ctlr, ctlr->cur_msg, ctlr->max_dma_len, > + GFP_KERNEL | GFP_DMA); > + if (ret) > + goto out; > + > if (ctlr->prepare_message) { > ret = ctlr->prepare_message(ctlr, ctlr->cur_msg); > if (ret) { > This doesn't work. I started to wonder why it was necessary to lift the upper bound in spi-bcm2835, so I put the test back and it triggered. Adding some printk's show that the split transfer are mapped correctly, but when unmap happens there's only the one big transfer: [ 70.935524] __spi_map_msg: msg=ae711dd4 [ 70.935572] xfer=95c5acd8, xfer->len=65532 [ 70.955800] xfer=aee3f198, xfer->len=65532 [ 70.956034] xfer=7fc3464e, xfer->len=22536 [ 70.982802] __spi_unmap_msg: msg=ae711dd4 [ 70.982889] xfer=d5b5dbbf, xfer->len=153600 I need to study this more tomorrow to find out why this is, unless someone knows off hand what the problem is. Noralf.