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

Stephen Warren swarren at wwwdotorg.org
Fri Jul 10 21:41:06 PDT 2015


On 07/04/2015 07:14 PM, Martin Sperl wrote:
> 
>> On 02.07.2015, at 06:57, Noralf Trønnes <noralf at tronnes.org> wrote:
>>
>>
>> Den 01.07.2015 21:39, skrev Martin Sperl:
>>>> On 30.06.2015, at 19:42, Mark Brown <broonie at kernel.org> wrote:
>>>>
>>>> This looks relevant:
>>>>
>>>>>>> On 22.06.2015, at 16:55, Jakub Kiciński <moorray3 at wp.pl> wrote:
>>>>>>> As mentioned by Noralf UART1 is quite commonly used on Compute Modules.
>>>>>>> Proper driver - perhaps modelled as a bus - seems like a prerequisite
>>>>>>> for this work.  You are also not using IRQ mux in DT binding example
>>>>>>> which is very misleading.
>>
>> [...]
>>
>>> Finally asking for a recommendation with regards to using a bus
>>> to arbitrate access to the enable register there was no feedback
>>> how this could be get implemented...
>>
>> Maybe you can use drivers/mfd/syscon.c to enable shared access to the
>> aux enable register. Then the spi driver could get the regmap with:
>> aux_regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
> 
> Seems as if you found an answer to my original question of if
> there is a framework to handle this.

I'd suggest avoiding syscon. IIUC, it just exposes raw register IO for
the shared register region, which is very "non-semantic", hence
completely hides what the reason the registers are being touched. I'd
much prefer a custom driver with use-case-specific APIs. If the
registers implement an IRQ mux/demux, an explicit IRQ controller driver
would be much better.

>> About sharing the aux interrupt, could this be implemented in irq-bcm2835
>> as a Bank 3?
>
> Obviously it could, but the question is if it is not more overhead than using
> a shared interrupt (requesting an interrupt with the shared flag set) in the
> first place (like this driver currently does or i2c and USB do).

IIUC, these registers aren't part of the main IRQ controller's register
set, and hence shouldn't be touched by the main IRQ controller driver.
Create a separate driver for entirely separate HW blocks/functionality/...

> I am working on a new version to make use of syscon.

:-(




More information about the linux-rpi-kernel mailing list