[PATCH 2/3] spi: add initial set of spi_transfer transformation methods

Mark Brown broonie at kernel.org
Thu Dec 3 10:04:39 PST 2015


On Thu, Dec 03, 2015 at 04:33:52PM +0100, Martin Sperl wrote:
> > On 03.12.2015, at 15:34, Mark Brown <broonie at kernel.org> wrote:

> > There are still a couple of users and someone needs to go through and
> > fix them.  I don't know which if any systems they run on, it's possible
> > that they manage to work as a result of the DMA mappings not getting in
> > the way the systems they're being used on (if they're being used at all)
> > or the controller drivers they're used with being equally aged.

> So if we make use of this “optimization” globally we will need to support it,
> otherwise we break it.

I'm relatively OK with breaking these users TBH, I'm not convinced any
of them are actually being run and it's probably easier to fix by fixing
the users when they're engaged.  Also if we do this in the message queue
thread then we're OK anyway since anything that uses these will old
enough to be using a custom message queue anyway so the risk is less
than it might appear.

> > Remember that we can't do any allocations in _verify() as it can run in
> > atomic context so while we want to check if we can take the message then
> > we are most likely going to be unable to implement transformations.

> I came to realize that in the meantime as well - it was just an idea
> how we could defer such things to a second CPU...

We could potentially try doing this in both call sites - we already have
special casing for spi_sync().  It's more fiddly but it could be done as
a future step.
-------------- 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-rpi-kernel/attachments/20151203/ad0d5ae7/attachment.sig>


More information about the linux-rpi-kernel mailing list