LKML Archive on
help / color / mirror / Atom feed
From: Jiri Kosina <>
To: Douglas Anderson <>
Cc: Benjamin Tissoires <>,
	Dan Carpenter <>,,
Subject: Re: [PATCH v2] HID: i2c-hid: goodix: Tie the reset line to true state of the regulator
Date: Thu, 15 Jul 2021 21:50:21 +0200 (CEST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <20210625081818.v2.1.I358cae5e33f742765fd38485d6ddf1a4a978644d@changeid>

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 <>

Applied, thanks Doug.

Jiri Kosina

  reply	other threads:[~2021-07-15 19:54 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 [this message]
2021-07-20  8:01   ` Benjamin Tissoires
2021-07-20 16:09     ` Doug Anderson

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2] HID: i2c-hid: goodix: Tie the reset line to true state of the regulator' \

* 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).