Hi, On Tue, Jul 20, 2021 at 1:01 AM Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote: > > On Thu, Jul 15, 2021 at 9:50 PM Jiri Kosina <jikos@xxxxxxxxxx> 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@xxxxxxxxxxxx> > > > > 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
