LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Jiri Kosina <jikos@kernel.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	"open list:HID CORE LAYER" <linux-input@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] HID: i2c-hid: goodix: Tie the reset line to true state of the regulator
Date: Tue, 20 Jul 2021 09:09:59 -0700	[thread overview]
Message-ID: <CAD=FV=U980_xkfMt-x9cv6LgyK0qfRt81HYEtu_sW3c+PqFN9A@mail.gmail.com> (raw)
In-Reply-To: <CAO-hwJJp-qg0pRZNk1PKhha6S=Zd2_r1UDjZUgm9Yq0MFL69MQ@mail.gmail.com>

Hi,

On Tue, Jul 20, 2021 at 1:01 AM Benjamin Tissoires
<benjamin.tissoires@redhat.com> wrote:
>
> 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 :)

Yeah, it was a bunch of work to split it but I think it worked out
pretty well overall. :-)

Looking at this patch today with fresh eyes, I just spotted a bug
though! :( I should have used the "devm" variant of
regulator_register_notifier() since otherwise nothing is
unregistering. Oops. I'll quickly send a fixup.

OK, it's should show up here:

https://lore.kernel.org/r/20210720090736.1.Idc6db7d0f2c2ecc6e533e5b918a651a66f337b2f@changeid

-Doug

      reply	other threads:[~2021-07-20 16:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-25 15:18 Douglas Anderson
2021-07-15 19:50 ` Jiri Kosina
2021-07-20  8:01   ` Benjamin Tissoires
2021-07-20 16:09     ` Doug Anderson [this message]

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='CAD=FV=U980_xkfMt-x9cv6LgyK0qfRt81HYEtu_sW3c+PqFN9A@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=benjamin.tissoires@redhat.com \
    --cc=dan.carpenter@oracle.com \
    --cc=jikos@kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH v2] HID: i2c-hid: goodix: Tie the reset line to true state of the regulator' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).