Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <cover.1620735871.git.sander@svanheule.net> <cover.1621809029.git.sander@svanheule.net>
 <YKr9G3EfrM34gCsL@lunn.ch> <CAHp75VewCw8ES_9S48qmeCtSXMkGWt0s4iub0Fu4ZuwWANHpaQ@mail.gmail.com>
 <02bbf73ea8a14119247f07a677993aad2f45b088.camel@svanheule.net>
 <f03d5cdc958110fc7d95cfc4258dac4e@walle.cc> <84352c93f27d7c8b7afea54f3932020e9cd97d02.camel@svanheule.net>
 <a644b8fa-c90a-eab6-9cca-08344abec532@redhat.com>
In-Reply-To: <a644b8fa-c90a-eab6-9cca-08344abec532@redhat.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Sun, 30 May 2021 21:16:24 +0300
Message-ID: <CAHp75VcFmU4rJ6jL204xGFM=s2LV=KQmsV8E75BpuSAZMXBn0w@mail.gmail.com>
Subject: Re: [PATCH v3 0/6] RTL8231 GPIO expander support
To:     Hans de Goede <hdegoede@redhat.com>
Cc:     Sander Vanheule <sander@svanheule.net>,
        Michael Walle <michael@walle.cc>, Andrew Lunn <andrew@lunn.ch>,
        Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
        Lee Jones <lee.jones@linaro.org>,
        Mark Brown <broonie@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        "Rafael J . Wysocki" <rafael@kernel.org>,
        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>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sun, May 30, 2021 at 7:51 PM Hans de Goede <hdegoede@redhat.com> wrote:
> On 5/30/21 6:19 PM, Sander Vanheule wrote:
> > On Fri, 2021-05-28 at 08:37 +0200, Michael Walle wrote:

...

> > I think I found a solution!
> >
> > As Michael suggested, I tried raw register reads and writes, to eliminate any
> > side effects of the intermediate code. I didn't use the ioctls (this isn't a
> > netdev), but I found regmap's debugfs write functionality, which allowed me to
> > do the same.
> >
> > I was trying to reproduce the behaviour I reported earlier, but couldn't. The
> > output levels were always the intended ones. At some point I realised that the
> > regmap_update_bits function does a read-modify-write, which might shadow the
> > actual current output value.
> > For example:
> >  * Set output low: current out is low
> >  * Change to input with pull-up: current out is still low, but DATAx reads high
> >  * Set output high: RMW reads a high value (the input), so assumes a write is
> >    not necessary, leaving the old output value (low).
> >
> > Currently, I see two options:
> >  * Use regmap_update_bits_base to avoid the lazy RMW behaviour
> >  * Add a cache for the output data values to the driver, and only use these
> >    values to write to the output registers. This would allow keeping lazy RMW
> >    behaviour, which may be a benefit on slow busses.
> >
> > With either of these implemented, if I set the output value before the
> > direction, everything works! :-)
> >
> > Would you like this to be added to regmap-gpio, or should I revert back to a
> > device-specific implementation?
>
> Regmap allows you to mark certain ranges as volatile, so that they will not
> be cached, these GPIO registers containing the current pin value seems like
> a good candidate for this. This is also necessary to make reading the GPIO
> work without getting back a stale, cached value.

After all it seems a simple missed proper register configuration in
the driver for regmap.
Oh, as usual something easy-to-solve requires tons of time to find it. :-)

Sander, I think you may look at gpio-pca953x.c to understand how it
works (volatility of registers).

-- 
With Best Regards,
Andy Shevchenko