LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Arnd Bergmann <email@example.com> To: Vladimir Oltean <firstname.lastname@example.org> Cc: Arnd Bergmann <email@example.com>, Vladimir Oltean <firstname.lastname@example.org>, Mark Brown <email@example.com>, Rasmus Villemoes <firstname.lastname@example.org>, Lee Jones <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Marc Zyngier <email@example.com>, Hou Zhiqiang <Zhiqiang.Hou@nxp.com>, Biwen Li <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, "Rafael J. Wysocki" <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com> Subject: Re: [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for some devices Date: Thu, 26 Aug 2021 11:24:24 +0200 [thread overview] Message-ID: <CAK8P3a3FnsWbGRU7BNc8uwt0nFAHa7K4c+qpoZixwdW9kihC5w@mail.gmail.com> (raw) In-Reply-To: <20210825220023.rqskspy2usvleoqr@skbuf> On Thu, Aug 26, 2021 at 12:01 AM Vladimir Oltean <firstname.lastname@example.org> wrote: > On Wed, Aug 25, 2021 at 11:24:52PM +0200, Arnd Bergmann wrote: > > > 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. I was not suggesting changing the DT files. The way we describe syscon devices is generally meant to allow replacing them with a custom driver as an implementation detail of the OS, you just have a driver that binds against the more specific compatible string as opposed to the generic compatible="syscon" check, and you replace all syscon_regmap_lookup_by_phandle() calls with direct function calls into exported symbols from that driver that perform high-level functions. In this particular case, I think a high-level interface from a drviers/soc/ driver works just as well as the syscon method if there was raw_spinlock requirement, but with the irqchip driver needing the regmap, the custom driver would a better interface. Arnd
next prev parent reply other threads:[~2021-08-26 9:24 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-08-25 20:50 [PATCH 0/2] Use raw spinlocks in the ls-extirq driver Vladimir Oltean 2021-08-25 20:50 ` [PATCH 1/2] regmap: teach regmap to use raw spinlocks if requested in the config Vladimir Oltean 2021-08-26 23:01 ` Thomas Gleixner 2021-08-27 16:12 ` Vladimir Oltean 2021-08-27 19:59 ` Thomas Gleixner 2021-08-30 10:49 ` Vladimir Oltean 2021-08-30 11:02 ` Rasmus Villemoes 2021-08-30 12:42 ` Mark Brown 2021-08-30 12:19 ` Mark Brown 2021-08-30 14:16 ` Thomas Gleixner 2021-09-01 16:05 ` Mark Brown 2021-09-02 8:35 ` Thomas Gleixner 2021-08-25 20:50 ` [PATCH 2/2] mfd: syscon: request a regmap with raw spinlocks for some devices Vladimir Oltean 2021-08-25 21:24 ` Arnd Bergmann 2021-08-25 22:00 ` Vladimir Oltean 2021-08-26 9:24 ` Arnd Bergmann [this message] 2021-08-26 13:57 ` Vladimir Oltean 2021-08-26 14:48 ` Arnd Bergmann 2021-09-06 9:18 ` Lee Jones 2021-08-26 12:51 ` (subset) [PATCH 0/2] Use raw spinlocks in the ls-extirq driver Mark Brown
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAK8P3a3FnsWbGRU7BNc8uwt0nFAHa7K4c+qpoZixwdW9kihC5w@mail.gmail.com \ --email@example.com \ --cc=Zhiqiang.Hou@nxp.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).