RfC: Handle SPI controller limitations like maximum message length
Brian Norris
computersforpeace at gmail.com
Thu Nov 19 16:07:46 PST 2015
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
More information about the linux-mtd
mailing list