Messages in this thread | | | Date | Thu, 26 Aug 2021 01:00:23 +0300 | From | Vladimir Oltean <> | Subject | Re: [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for some devices |
| |
On Wed, Aug 25, 2021 at 11:24:52PM +0200, Arnd Bergmann wrote: > On Wed, Aug 25, 2021 at 10:50 PM Vladimir Oltean > <vladimir.oltean@nxp.com> wrote: > > > > This patch solves a ls-extirq irqchip driver bug in a perhaps > > non-intuitive (at least non-localized) way. > > > > The issue is that ls-extirq uses regmap, and due to the fact that it is > > being called by the IRQ core under raw spinlock context, it needs to use > > raw spinlocks itself. So it needs to request raw spinlocks from the > > regmap config. > > > > All is fine so far, except the ls-extirq driver does not manage its own > > regmap, instead it uses syscon_node_to_regmap() to get it from the > > parent syscon (this driver). > > > > Because the syscon regmap is initialized before any of the consumer > > drivers (ls-extirq) probe, we need to know beforehand whether to request > > raw spinlocks or not. > > > > The solution seems to be to check some compatible string. The ls-extirq > > driver probes on quite a few NXP Layerscape SoCs, all with different > > compatible strings. This is potentially fragile and subject to bit rot > > (since the fix is not localized to the ls-extirq driver, adding new > > compatible strings there but not here seems plausible). Anyway, it is > > probably the best we can do without major rework. > > > > Suggested-by: Mark Brown <broonie@kernel.org> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> > > This should work, but how hard would it be to change the ls-extirq > driver instead to not use the syscon driver at all but make the extirq > driver set up the regmap itself? > > Are there any other users of the syscon?
Not that I can see, but that doesn't make the fact that it uses a syscon a bad decision.
For context, Layerscape devices have a "Misc" / "And Others" memory region called "Supplemental Configuration Unit" (SCFG) which "provides the chip-specific configuration and status registers for the device. It is the chip-defined module for extending the device configuration unit (DCFG) module." to quote the documentation.
The ls-extirq file is a driver around _a_single_register_ of SCFG. SCFG provides an option of reversing the interrupt polarity of the external IRQ pins: make them active-low instead of active-high, or rising instead of falling.
The reason for the existence of the driver is that we got some pushback during device tree submission: while we could describe in the device tree an interrupt as "active-high" and going straight to the GIC, in reality that interrupt is "active-low" but inverted by the SCFG (the inverted is enabled by default). Additionally, the GIC cannot process active-low interrupts in the first place AFAIR, which is why an inverter exists in front of it.
Some other SCFG registers are (at least on LS1021A):
Deep Sleep Control Register eTSEC Clock Deep Sleep Control Register (eTSEC is our Ethernet controller) Pixel Clock Control Register PCIe PM Write Control Register PCIe PM Read Control Register USB3 parameter 1 control register ETSEC MAC1 ICID SATA ICID QuadSPI configuration Endianness Control Register Snoop configuration Interrupt Polarity <- this is the register controlled by ls-extirq etc etc.
Also, even if you were to convince me that we shouldn't use a syscon, I feel that the implication (change the device trees for 7 SoCs) just to solve a kernel splat would be like hitting a nail with an atomic bomb. I'm not going to do it.
| |