Den 11.04.2019 18.42, skrev Noralf Trønnes:
> From: Meghana Madhyastha <meghana.madhyas...@gmail.com>
>
> 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.madhyas...@gmail.com>
> Signed-off-by: Noralf Trønnes <nor...@tronnes.org>
> ---
> 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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
