From: Sander Vanheule <sander@svanheule.net>
To: Andy Shevchenko <andy.shevchenko@gmail.com>,
Mark Brown <broonie@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
Lee Jones <lee.jones@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Michael Walle <michael@walle.cc>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
Linux LED Subsystem <linux-leds@vger.kernel.org>,
devicetree <devicetree@vger.kernel.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
Andrew Lunn <andrew@lunn.ch>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v5 2/8] gpio: regmap: Add quirk for aliased data registers
Date: Wed, 07 Jul 2021 22:53:19 +0200 [thread overview]
Message-ID: <dee12a4f5dc1a37feb14e20074cf365dbb86bc05.camel@svanheule.net> (raw)
In-Reply-To: <CAHp75VeOMb2xUJ+g2UQJnBybmehmYr0dGPEzDZObUGr=Q95+wA@mail.gmail.com>
Hi Andy, Mark,
My apologies for the delay in replying, work has been keeping me a bit busy.
On Sun, 2021-06-13 at 00:29 +0300, Andy Shevchenko wrote:
> On Sun, Jun 13, 2021 at 12:13 AM Sander Vanheule <sander@svanheule.net> wrote:
> >
> > Some chips have the read-only input and write-only output data registers
> > aliased to the same offset. As a result it is not possible to perform
> > read-modify-writes on the output values, when a line is still configured
> > as input.
> >
> > Add a quirk for aliased data registers, and document how the regmap
> > should be set up for correct operation.
>
> I still believe that there is no issue with gpio-regmap and we don't
> need any quirk there.
>
> The issue is in the regmap APIs (implementation) itself. Hardware with
> the concept of reading X / writing Y at the same offset is okay per
> se. regmaps doesn't support it properly and should be fixed (amended)
> in a way that you provide this kind of register description thru
> regmap configuration or so.
I've made an attempt at implementing a "regmap_aliased()", similar to
"regmap_volatile()". However, this meant I had to make _regmap_read() aware of
wether the read- or write-alias was being read (from cache), touching some parts
of the regmap code I'm not using myself. Furthermore, this "aliased" property
isn't really perpendicular to "volatile", since writes should never be volatile,
and non-volatile reads don't make much sense (to me) on a read-only register.
In addition to entire registers having different meanings on reads or writes,
individual bitfields could also have different properties. Some bits of a
register could be aliased, while other bits are just 'plain' volatile. This is
the case for the last register of the RTL8231, where the low bits are GPIO data
(so aliased), and the highest bit is a self-clearing "latch new data" command
bit (i.e. RW-volatile).
If a regmap_field could overwrite the specifiers of it's parent register, I
think this may provide quite a natural solution to the aliasing problem: just
create two regmap_field defintions. One definition would be 'write-only' (and
cached for RMW), the other 'volatile read-only'. All regmap_fields could still
rely on a single cached register value, I think. I didn't try to implement this
though, so maybe I'm missing some behaviour that would disqualify this solution.
Would you think this could be an acceptable way to move forward here?
> I expressed the idea of trying to implement regmap-8250 as an example
> of the support for such hardware. And OTOH that this kind of hardware
> is not unusual.
This implementation indeed requires the same aliasing support, in addition to
register paging even. I've never touched that subsystem before though, so I
would need some more time if I wanted to try this.
Best,
Sander
next prev parent reply other threads:[~2021-07-07 20:53 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-12 21:12 [PATCH v5 0/8] RTL8231 GPIO expander support Sander Vanheule
2021-06-12 21:12 ` [PATCH v5 1/8] regmap: Support atomic forced uncached reads Sander Vanheule
2021-06-12 21:23 ` Andy Shevchenko
2021-06-14 10:33 ` Mark Brown
2021-06-12 21:12 ` [PATCH v5 2/8] gpio: regmap: Add quirk for aliased data registers Sander Vanheule
2021-06-12 21:29 ` Andy Shevchenko
2021-07-07 20:53 ` Sander Vanheule [this message]
2021-07-08 14:23 ` Mark Brown
2021-06-12 21:12 ` [PATCH v5 3/8] dt-bindings: leds: Binding for RTL8231 scan matrix Sander Vanheule
2021-06-12 21:12 ` [PATCH v5 4/8] dt-bindings: mfd: Binding for RTL8231 Sander Vanheule
2021-06-12 21:12 ` [PATCH v5 5/8] mfd: Add RTL8231 core device Sander Vanheule
2021-06-12 21:12 ` [PATCH v5 6/8] pinctrl: Add RTL8231 pin control and GPIO support Sander Vanheule
2021-06-12 21:12 ` [PATCH v5 7/8] leds: Add support for RTL8231 LED scan matrix Sander Vanheule
2021-06-12 21:12 ` [PATCH v5 8/8] MAINTAINERS: Add RTL8231 MFD driver Sander Vanheule
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=dee12a4f5dc1a37feb14e20074cf365dbb86bc05.camel@svanheule.net \
--to=sander@svanheule.net \
--cc=andrew@lunn.ch \
--cc=andy.shevchenko@gmail.com \
--cc=bgolaszewski@baylibre.com \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=michael@walle.cc \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=robh+dt@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.