Re: RfC: Handle SPI controller limitations like maximum message length

[Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Thu, Nov 19, 2015 at 05:15:38PM +0000, Mark Brown wrote:
> On Thu, Nov 19, 2015 at 04:00:45PM +0100, Martin Sperl wrote:
> > 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.

So for transfer size limitations, are you speaking of the same thing as
Heiner (who began this post mentioning *message* size limitations)? I
read a difference between the two, where a transfer size limitation
might mean that one could improve the SPI core to just split transfers
up into multiple sub-transfers, and still complete the whole
spi_message (and therefore the protocol driver has less to worry about).
But if we're talking about spi_message limitations, then this would be
more exposed to the protocol driver.

Or maybe I'm just reading this all wrong and am confused. Please
enlighten.

Regards,
Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html