[PATCH V2 - RESEND] SPI: BCM2835: allow arbitrary GPIO to act as SPI-chip_select

[Martin Sperl]

> On 25.03.2015, at 19:50, Mark Brown <broonie at kernel.org> wrote:
> 
> This sounds like you're trying to work aroud the core rather than work
> with the core - enhance the core so that it can express what you need.
> 

Working in a single driver makes things more local without having
a "moving" target with lots of other patches. If done right most of it
then can get moved to the core - if needed...

>> From my perspective I want to minimize the dependencies while I create
>> this proof of concept.
>> And for my testing this with several different devices I need support
>> for multiple devices and for that I need this patch go in first.
>> Taking baby steps here.
> 
> I had been under the impression that you had already done a lot of proof
> of concept work with this stuff?

I had an Idea - that specific one has not been tested yet, but from the
measurements on interrupt and scheduling latencies these seem low hanging
fruit.

> 
>> Also there is another point here, that Stephen pointed out:
>> Would not a switch from the use of the "native-cs" to "gpio-only" mean
>> a required change in Device-tree? And isn't DT assumed to be a stabe API?
> 
> Can you be more specific about what change you think might be required?
> Currently the driver doesn't support GPIOs as chip selects at all so
> anything enabling them is going to be new.
Well, if we say we "need" gpio_cs to be set in DT of the master, then
that might be assumed an API change that might break some custom 
device-trees - I was mostly referring to that.

So how would that situation be with the requirement to use the GPIO_CS 
explicitly?

>> So to summarize: do you want me to move to transfer_one instead and
>> then revert back for the optimizations?
> 
> Drivers should in general be moving to use modern APIs.  If current APIs
> need enhancing then look into doing that.
OK, so I will try to take the "modernization" approach, but a quick look
shows some headaches, that the current driver is hiding behind scheduling
latencies...

Martin