[PATCH v4 2/4] spi: Split spi message into max_dma_len size chunks

Noralf Trønnes noralf at tronnes.org
Thu Apr 11 20:39:26 UTC 2019



Den 11.04.2019 18.42, skrev Noralf Trønnes:
> From: Meghana Madhyastha <meghana.madhyastha at 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.madhyastha at gmail.com>
> Signed-off-by: Noralf Trønnes <noralf at 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.


More information about the dri-devel mailing list