On 07/04/2015 07:14 PM, Martin Sperl wrote: > >> On 02.07.2015, at 06:57, Noralf Trønnes <noralf@xxxxxxxxxxx> wrote: >> >> >> Den 01.07.2015 21:39, skrev Martin Sperl: >>>> On 30.06.2015, at 19:42, Mark Brown <broonie@xxxxxxxxxx> wrote: >>>> >>>> This looks relevant: >>>> >>>>>>> On 22.06.2015, at 16:55, Jakub Kiciński <moorray3@xxxxx> 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. :-( -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
