[PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2

[Martin Sperl]

Hi Stephen!

> On 28.07.2015, at 04:51, Stephen Warren <swarren at wwwdotorg.org> wrote:
> 
> 
>> If this is not acceptable, then where should such a driver go in the
>> kernel tree?
>> 
>> It would essentially implement the following:
>> bcm2835aux_enable(dev, device-id);
>> bcm2835aux_disable(dev, device-id);
>> 
>> Which would just set/clean the bits in the register while holding a lock.
> 
> That sounds reasonable. I'd also expect a function that the client
> drivers could call during probe() to look up the device (and implement
> deferred probe) and another to release the reference during the client's
> remove().
But the bigger question you have not answered is: “where should such an
auxiliar driver go in the kernel tree?” i.e. which directory?

I really do not want to implement it and then get told: “that should not
go here” - been thru too many iterations already…

Also I am not sure I understood the “defer” thingy.
I thought of actually implementing only 2 functions to use during probe
and removal:
* bcm2835aux_enable(dev)
* bcm2835aux_disable(dev)

Both would pick up the “bcrm,aux” property from the device tree (as per 
“bcrm,aux = <&bcm2835aux 4>”) and set the enable register accordingly
holding a lock.

I still could leave those 2 functions in the spi driver for now and
when someone wants to implement the uart1, then they would need to pull
that out into a separate driver.

As for interrupt-handler: it was a simple idea that would work fine for
the bcm2835aux case to avoid configuring things for the uart, but then
you do not want the uart1 to get configured as 'compatible=“ns16650”;’
inside the device-tree, so this is not acceptable anyway (unless there
were some way to define “additional” compatibility for a driver without
modifying the driver itself).
This means we will need to implement a minimal driver for uart1 that
wraps ns16650.

But as all the drivers (spi-bcm2835aux as well as ns16650) can use
FIRQ_SHARED (and do not need to read/write the shared aux_irg registers)
the need for a interrupt controller is not there.