GPIO chips often have data input and output registers aliased to the
same offset. The output register is non-valitile and could in theory be
cached. The input register however is volatile by nature and hence
should not be cached, resulting in different requirements for reads and
writes.
The generic gpiochip implementation stores a shadow value of the pin
output data, which is updated and written to hardware on output data
changes. Pin input values are always obtained by reading the aliased
data register from hardware.
For gpio-regmap the output data could be in multiple registers, but we
can use the regmap cache support to shadow the output values by marking
the data registers as non-volatile. By using regmap_read_bypassed() we
can still treat the input values as volatile, irrespective of the regmap
config. This ensures proper functioning of writing the output register
with regmap_write_bits(), which will then use and update the cache only
on data writes, gaining some performance from the cached output values.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
---
drivers/gpio/gpio-regmap.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-regmap.c b/drivers/gpio/gpio-regmap.c
index ba3c19206ccf..afecacf7607f 100644
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -81,7 +81,11 @@ static int gpio_regmap_get(struct gpio_chip *chip, unsigned int offset)
if (ret)
return ret;
- ret = regmap_read(gpio->regmap, reg, &val);
+ /* ensure we don't spoil any register cache with pin input values */
+ if (gpio->reg_dat_base == gpio->reg_set_base)
+ ret = regmap_read_bypassed(gpio->regmap, reg, &val);
+ else
+ ret = regmap_read(gpio->regmap, reg, &val);
if (ret)
return ret;
--
2.51.0
On Mon Oct 20, 2025 at 1:56 PM CEST, Sander Vanheule wrote: > GPIO chips often have data input and output registers aliased to the > same offset. The output register is non-valitile and could in theory be > cached. The input register however is volatile by nature and hence > should not be cached, resulting in different requirements for reads and > writes. > > The generic gpiochip implementation stores a shadow value of the pin > output data, which is updated and written to hardware on output data > changes. Pin input values are always obtained by reading the aliased > data register from hardware. > > For gpio-regmap the output data could be in multiple registers, but we > can use the regmap cache support to shadow the output values by marking > the data registers as non-volatile. By using regmap_read_bypassed() we > can still treat the input values as volatile, irrespective of the regmap > config. This ensures proper functioning of writing the output register > with regmap_write_bits(), which will then use and update the cache only > on data writes, gaining some performance from the cached output values. > > Signed-off-by: Sander Vanheule <sander@svanheule.net> Reviewed-by: Michael Walle <mwalle@kernel.org>
On Mon, Oct 20, 2025 at 1:56 PM Sander Vanheule <sander@svanheule.net> wrote: > GPIO chips often have data input and output registers aliased to the > same offset. The output register is non-valitile and could in theory be > cached. The input register however is volatile by nature and hence > should not be cached, resulting in different requirements for reads and > writes. > > The generic gpiochip implementation stores a shadow value of the pin > output data, which is updated and written to hardware on output data > changes. Pin input values are always obtained by reading the aliased > data register from hardware. > > For gpio-regmap the output data could be in multiple registers, but we > can use the regmap cache support to shadow the output values by marking > the data registers as non-volatile. By using regmap_read_bypassed() we > can still treat the input values as volatile, irrespective of the regmap > config. This ensures proper functioning of writing the output register > with regmap_write_bits(), which will then use and update the cache only > on data writes, gaining some performance from the cached output values. > > Signed-off-by: Sander Vanheule <sander@svanheule.net> That looks good to me for sure! Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
Hi Linus, Michael, On Tue, 2025-10-21 at 09:18 +0200, Linus Walleij wrote: > On Mon, Oct 20, 2025 at 1:56 PM Sander Vanheule <sander@svanheule.net> wrote: > > > GPIO chips often have data input and output registers aliased to the > > same offset. The output register is non-valitile and could in theory be > > cached. The input register however is volatile by nature and hence > > should not be cached, resulting in different requirements for reads and > > writes. > > > > The generic gpiochip implementation stores a shadow value of the pin > > output data, which is updated and written to hardware on output data > > changes. Pin input values are always obtained by reading the aliased > > data register from hardware. > > > > For gpio-regmap the output data could be in multiple registers, but we > > can use the regmap cache support to shadow the output values by marking > > the data registers as non-volatile. By using regmap_read_bypassed() we > > can still treat the input values as volatile, irrespective of the regmap > > config. This ensures proper functioning of writing the output register > > with regmap_write_bits(), which will then use and update the cache only > > on data writes, gaining some performance from the cached output values. > > > > Signed-off-by: Sander Vanheule <sander@svanheule.net> > > That looks good to me for sure! > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Thanks for the reviews, I'll prepare the full respin for the RTL8231 patches and send them later today or tomorrow. Best, Sander
On Tue, Oct 21, 2025 at 11:01 AM Sander Vanheule <sander@svanheule.net> wrote: > > Thanks for the reviews, I'll prepare the full respin for the RTL8231 patches and > send them later today or tomorrow. I take it, you'll include these patches in that series? Bart
Hi, On Tue, 2025-10-21 at 14:21 +0200, Bartosz Golaszewski wrote: > On Tue, Oct 21, 2025 at 11:01 AM Sander Vanheule <sander@svanheule.net> wrote: > > > > Thanks for the reviews, I'll prepare the full respin for the RTL8231 patches > > and > > send them later today or tomorrow. > > I take it, you'll include these patches in that series? Yes, I will. Since this was just an RFC, I don't know if everybody pays as much attention. I will include Linus' and Michael's tags when I send the series. Best, Sander
© 2016 - 2026 Red Hat, Inc.