[PATCH 1/2] spi: bcm2835: add spi-bcm2835aux driver for the auxiliar spi1 and spi2
kernel at martin.sperl.org
Mon Jul 27 23:18:25 PDT 2015
> 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
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
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
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.
More information about the linux-rpi-kernel