[PATCH] pinctrl: mediatek: common-v1: Use a raw spinlock for the pinctrl regmap

Sebastian Andrzej Siewior bigeasy at linutronix.de
Tue Oct 20 00:32:36 PDT 2026


On 2026-10-06 19:57:01 [-0500], Ryan Brue wrote:
> Hi Chen-Yu and Sebastian,
> 
> Thanks for looking at this.
> 
> On 9/30/26 3:17 AM, Chen-Yu Tsai wrote:
> > The syscon node is the provider of the regmap. You need to fix it there,
> > not duplicate it in the consumer.
> 
> Unless I'm misunderstanding, no driver binds to that node, so its regmap
> comes from the generic syscon code, and changing it there would affect every
> syscon. Lee, Arnd, Mark, would that be acceptable?
> 
> These are the options I see. Please let me know if there's a better one:
> 
> - Do what Sebastian suggested and make syscon use a raw spinlock, except
> when the node has a clock, since regmap-mmio calls clk_enable() under the
> lock. Off PREEMPT_RT, nothing changes. On RT the lock would no longer be
> preemptible for most syscons, including across bulk writes. Most syscon
> users that do bulk writes only write a few registers, but enabling the
> Amlogic G12A PCIe PLL writes a sequence with 40 us of udelay() under the
> lock.

bulk writes could be a concern. The 40us delay is within the lock
acquired? If so, could this be done without the lock? I assume this is
part of the init sequence so nothing should use the HW so the writes
should not be interrupted by other writes to the device.

> - Have the pinctrl ioremap() the node a second time alongside syscon's
> mapping and read the input register (DIN) with readl(). That read is the
> only access the EINT code makes in raw context. This would go around the
> syscon, and it requires that DIN never be written in a multi-step sequence,
> which is currently the case.

So it would be safe for now…

> I'd like to know the best approach before sending out a v2.
> 
> Best regards,
> Ryan Brue

Sebastian



More information about the Linux-mediatek mailing list