RfC: Handle SPI controller limitations like maximum message length

[Mark Brown]

On Thu, Nov 19, 2015 at 04:00:45PM +0100, Martin Sperl wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> 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.

Alignment is a general issue which all clients should be trying to
ensure as a matter of course - never mind individual blocks of hardware,
some common CPU architectures suffer noticable penalties from unaligned
accesses so it's just generally good practice to try to avoid them.

You shouldn't be doing anything about transfer size limitations in your
driver, if you have this restriction you should be adding code to the
core and just flagging the limit in your driver.

> 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);

Please don't do things this way, please make this more data driven -
have the drivers declare their capabilities so the core can just do
these things based on those flags rather than requiring active code in
drivers.  This keeps the code central which in turn helps keep things
maintainable.

> 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.

You've got this back to front - drivers are responsible for initialising
the master when they instantiate it.  There's nothing stopping them
using the data if they have variants to handle but they shouldn't be
speculatively looking at it on the off chance there's some limit.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20151119/647b491d/attachment-0001.sig>