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

[Martin Sperl]

> On 03.12.2015, at 15:34, Mark Brown <broonie at kernel.org> wrote:
> 
> On Thu, Dec 03, 2015 at 07:22:10AM +0100, Martin Sperl wrote:
>>> On 03.12.2015, at 01:36, Mark Brown <broonie at kernel.org> wrote:
> 
>>>> Rx/tx_dma is handled because it is there and it's address needs also to be
>>>> accurately Shifted by that offset. I know that it is a depreciated interface,
>>>> but as it is still there it needs to be supported...
> 
>>> It's really quite broken already for most users.
> 
>> If it is broken, then why not remove those members?
> 
> 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.

That was one of the reasons why I am advocating (for now) that we
make it an option that has to get enabled in the individual drivers.

But we could minimize the coding by providing a “default” implementation
that could get assigned to spi_master.prepare_message.

So an spi_master would only need to assign that, which makes it clear that
this has been tested with this specific HW (which is my biggest concern).

We could also create a separate spi_master.transform_message method, which
the drivers assign to the default or custom implementation and which
(eventually) may get assigned a default if NULL and dma_alignment
as well as (the future) max_transfer_size is set.

The advantage of this would be that we could (at a later stage) move the
invocation translation method to a different location - say: queuing it
in a different worker thread for translation when there are more than one
spi_message in the queue (if it is submitted from idle we would execute in
place at somewhere in __spi_pump_messages).

Just exploring some options...

Would it make any sense to separate it out as described, so that we can do
something like this later?

>> One last thing:
>> Where do you prefer to run those transfer transformations?
>> In the master-loop (before/after prepare message)?
>> During spi_verify (or after it)?
> 
> 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...