RfC: Handle SPI controller limitations like maximum message length

[Martin Sperl]

> On 19.11.2015, at 12:40, Mark Brown <broonie at kernel.org> wrote:
> 
> On Wed, Nov 18, 2015 at 11:50:00PM +0100, Heiner Kallweit wrote:
>> Am 18.11.2015 um 22:57 schrieb Mark Brown:
>>> On Wed, Nov 18, 2015 at 10:19:29PM +0100, Heiner Kallweit wrote:
> 
>>>> There have been few discussions in the past about how to handle SPI controller
>>>> limitations like max message length. However they don't seem to have resulted
>>>> in accepted patches yet.
> 
>>> No, they've resulted in people writing code.  We've got a bunch of
>>> things in the spi_master struct like the limits on speeds and bits per
>>> word.
> 
>> Sure, I'm aware of this. To you it might sound obvious to handle such
>> limitations in the SPI core, however there have been several attempts
>> to deal with such limitations in controller or protocol drivers.
> 
> They're documented using terms like "limits" and "constraints" - it's
> hard to see what we're missing there.
> 
>>>> Maybe a better approach would be to introduce a new member of spi_master
>>>> dealing with controller limitations.
> 
>>> That's what we've been doing...
> 
>> Primary addressees of my comment were users of the SPI core trying to deal
>> in their own code with things which might be better dealt with in the core.
> 
> Well, we do to the extent we can do anything useful in the core we have
> code to deal with them - we constrain clocks and we have error checking
> for the bits per word settings for example.
> 
>> In case there should be more need to reflect such limitations in spi_master
>> it might be good to encapsulate them in a separate struct instead of adding
>> more such members to spi_master directly.
> 
> It's going to be annoying to move everything over and TBH I'm not sure
> it really helps much.  This is honestly the first time I can recall
> anyone expressing any confusion here.

On the bcm2835 there are also some “limitations” (when transfers are not aligned
to word, transfers>65535 can’t DMA) which we work around right now inefficiently.

I am in the progress of writing a (minimal) spi-core extension, that would allow 
a spi_master to have a prepare_message function that would call some “message
translation functions”.

The ones I have currently come up with are:
int spi_split_transfer_alignment(struct spi_message *msg, int alignment);
int spi_split_transfer_maxsize(struct spi_message *msg, size_t max_size);

These would make the spi message conform to the drivers requirements for
alignment and max_size splitting transfers in the appropriate way before they
are are dma-mapped.

I guess this is a more transparent approach that does not require the
individual device drivers to query the spi_master about limitations
and replicate code in several drivers - also there is no maintenance cost on
individual device drivers to track when there is a new limitation introduced.

This may not handle every possible case/limitation, but could help in some cases.

Thanks,
	Martin