From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Runyu Xiao <runyu.xiao@seu.edu.cn>, Mark Brown <broonie@kernel.org>
Cc: Viresh Kumar <vireshk@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Clark Williams <clrkwllms@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
linux-arm-kernel@lists.infradead.org, soc@lists.linux.dev,
linux-gpio@vger.kernel.org, linux-rt-devel@lists.linux.dev,
linux-kernel@vger.kernel.org, jianhao.xu@seu.edu.cn
Subject: Re: Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates
Date: Thu, 18 Jun 2026 10:15:54 +0200 [thread overview]
Message-ID: <20260618081554.zifCwv4I@linutronix.de> (raw)
In-Reply-To: <20260618023418.213453-1-runyu.xiao@seu.edu.cn>
On 2026-06-18 10:34:18 [+0800], Runyu Xiao wrote:
> Hi,
Hi,
…
> The repair I am considering is to keep the gpiolib resource updates in
> the fast irq_enable/irq_disable callbacks, but defer the actual PLGPIO
> IE/EIT register writes to irq_bus_sync_unlock(), after the IRQ core has
> dropped desc->lock. The driver would keep per-line shadow state for:
>
> - IRQ disabled/enabled state
> - pending IE update
> - edge direction state
> - pending EIT update
>
> and then synchronize those shadow updates from irq_bus_sync_unlock()
> under a mutex.
Not sure how this will look like, but okay. I was looking at making the
a lock a raw_spinlock_t for fast_io. Since it is just a read and write
it shouldn't be a problem. But then there is the regcache and the sync
of many registers might be painful. The actual problem is the type MAPLE
and RBTREE which have an allocation in their write callback. That is a
no but the FLAT ones should work since there is just one alloc during
init. Well, wouldn't it be for the lock that is acquired during the
callback.
I don't think this is required given that it is init time so
holding the lock shouldn't be required. This was introduced in commit
fd4ebc07b4dff ("regmap: Hold the regmap lock when allocating and freeing
the cache"). This change broke gpio-104-idio-16.c, pio-pci-idio-16.c,
pio-pcie-idio-24, gpio-ws16c48.c and pinctrl-apple-gpio.c.
So unless there is something that I miss…
> In other words, the fast callbacks would only update local shadow state
> and call gpiochip_enable_irq()/gpiochip_disable_irq(), while the sleepable
> regmap writes would be batched into the irq bus sync phase.
>
> Does that sound like an acceptable direction for SPEAr PLGPIO, or would
> you prefer a different fix, such as changing the underlying syscon regmap
> locking model or handling only the IE register path?
>
> The draft patch I have locally is roughly:
>
> pinctrl: spear: defer PLGPIO IRQ updates to bus sync
>
> and it changes only drivers/pinctrl/spear/pinctrl-plgpio.c.
>
> Thanks,
> Runyu
Sebastian
next prev parent reply other threads:[~2026-06-18 8:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-18 2:34 Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates Runyu Xiao
2026-06-18 7:40 ` Viresh Kumar
2026-06-18 9:54 ` Herve Codina
2026-06-18 8:15 ` Sebastian Andrzej Siewior [this message]
2026-06-18 14:49 ` Runyu Xiao
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=20260618081554.zifCwv4I@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=broonie@kernel.org \
--cc=clrkwllms@kernel.org \
--cc=jianhao.xu@seu.edu.cn \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=runyu.xiao@seu.edu.cn \
--cc=soc@lists.linux.dev \
--cc=vireshk@kernel.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: link
Be 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