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: <20210625081818.v2.1.I358cae5e33f742765fd38485d6ddf1a4a978644d@changeid>
 <nycvar.YFH.7.76.2107152150060.8253@cbobk.fhfr.pm>
In-Reply-To: <nycvar.YFH.7.76.2107152150060.8253@cbobk.fhfr.pm>
From:   Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date:   Tue, 20 Jul 2021 10:01:20 +0200
Message-ID: <CAO-hwJJp-qg0pRZNk1PKhha6S=Zd2_r1UDjZUgm9Yq0MFL69MQ@mail.gmail.com>
Subject: Re: [PATCH v2] HID: i2c-hid: goodix: Tie the reset line to true state
 of the regulator
To:     Jiri Kosina <jikos@kernel.org>
Cc:     Douglas Anderson <dianders@chromium.org>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        "open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
        lkml <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, Jul 15, 2021 at 9:50 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Fri, 25 Jun 2021, Douglas Anderson wrote:
>
> > The regulator for the touchscreen could be:
> > * A dedicated regulator just for the touchscreen.
> > * A regulator shared with something else in the system.
> > * An always-on regulator.
> >
> > How we want the "reset" line to behave depends a bit on which of those
> > three cases we're in. Currently the code is written with the
> > assumption that it has a dedicated regulator, but that's not really
> > guaranteed to be the case.
> >
> > The problem we run into is that if we leave the touchscreen powered on
> > (because someone else is requesting the regulator or it's an always-on
> > regulator) and we assert reset then we apparently burn an extra 67 mW
> > of power. That's not great.
> >
> > Let's instead tie the control of the reset line to the true state of
> > the regulator as reported by regulator notifiers. If we have an
> > always-on regulator our notifier will never be called. If we have a
> > shared regulator then our notifier will be called when the touchscreen
> > is truly turned on or truly turned off.
> >
> > Using notifiers like this nicely handles all the cases without
> > resorting to hacks like pretending that there is no "reset" GPIO if we
> > have an always-on regulator.
> >
> > NOTE: if the regulator is on a shared line it's still possible that
> > things could be a little off. Specifically, this case is not handled
> > even after this patch:
> > 1. Suspend goodix (send "sleep", goodix stops requesting regulator on)
> > 2. Other regulator user turns off (regulator fully turns off).
> > 3. Goodix driver gets notified and asserts reset.
> > 4. Other regulator user turns on.
> > 5. Goodix driver gets notified and deasserts reset.
> > 6. Nobody resumes goodix.
> >
> > With that set of steps we'll have reset deasserted but we will have
> > lost the results of the I2C_HID_PWR_SLEEP from the suspend path. That
> > means we might be in higher power than we could be even if the goodix
> > driver thinks things are suspended. Presumably, however, we're still
> > in better shape than if we were asserting "reset" the whole time. If
> > somehow the above situation is actually affecting someone and we want
> > to do better we can deal with it when we have a real use case.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
>
> Applied, thanks Doug.

Thanks Jiri for taking this one in.

FWIW, I am really glad Doug made the effort of splitting i2c-hid-core
and i2c-hid-goodix, because this is the kind of patch that would have
been a nightmare to make it generic :)

Cheers,
Benjamin

>
> --
> Jiri Kosina
> SUSE Labs
>