On Thu, Dec 03, 2015 at 04:33:52PM +0100, Martin Sperl wrote: > > On 03.12.2015, at 15:34, Mark Brown <broonie@xxxxxxxxxx> 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.
Attachment:
signature.asc
Description: PGP signature
