In the beginning, commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the
reset line to true state of the regulator") introduced a change to tie
the reset line of the Goodix touchscreen to the state of the regulator
to fix a power leakage issue in suspend.
After some time, the change was deemed unnecessary and was reverted in
commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to
the regulator") due to difficulties in managing regulator notifiers for
designs like Evoker, which provides a second power rail to touchscreen.
However, the revert caused a power regression on another Chromebook
device Steelix in the field, which has a dedicated always-on regulator
for touchscreen and was covered by the workaround in the first commit.
To address both cases, this patch adds the support for the
`powered-in-suspend` property in the driver that allows the driver to
determine whether the touchscreen is still powered in suspend, and
handle the reset GPIO accordingly as below:
- When set to true, the driver does not assert the reset GPIO in power
down. To ensure a clean start and the consistent behavior, it does the
assertion in power up instead.
This is for designs with a dedicated always-on regulator.
- When set to false, the driver uses the original control flow and
asserts GPIO and disable regulators normally.
This is for the two-regulator and shared-regulator designs.
Signed-off-by: Fei Shao <fshao@chromium.org>
---
drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 46 +++++++++++++++++++++----
1 file changed, 39 insertions(+), 7 deletions(-)
diff --git a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
index 0060e3dcd775..b438db8ca6f4 100644
--- a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
+++ b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c
@@ -28,6 +28,7 @@ struct i2c_hid_of_goodix {
struct regulator *vdd;
struct regulator *vddio;
struct gpio_desc *reset_gpio;
+ bool powered_in_suspend;
const struct goodix_i2c_hid_timing_data *timings;
};
@@ -37,13 +38,34 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops)
container_of(ops, struct i2c_hid_of_goodix, ops);
int ret;
- ret = regulator_enable(ihid_goodix->vdd);
- if (ret)
- return ret;
-
- ret = regulator_enable(ihid_goodix->vddio);
- if (ret)
- return ret;
+ /*
+ * This is to ensure that the reset GPIO will be asserted and the
+ * regulators will be enabled for all cases.
+ */
+ if (ihid_goodix->powered_in_suspend) {
+ /*
+ * This is not mandatory, but we assert reset here (instead of
+ * in power-down) to ensure that the device will have a clean
+ * state later on just like the normal scenarios would have.
+ *
+ * Also, since the regulators were not disabled in power-down,
+ * we don't need to enable them here.
+ */
+ gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
+ } else {
+ /*
+ * In this case, the reset is already asserted (either in
+ * probe or power-down).
+ * All we need is to enable the regulators.
+ */
+ ret = regulator_enable(ihid_goodix->vdd);
+ if (ret)
+ return ret;
+
+ ret = regulator_enable(ihid_goodix->vddio);
+ if (ret)
+ return ret;
+ }
if (ihid_goodix->timings->post_power_delay_ms)
msleep(ihid_goodix->timings->post_power_delay_ms);
@@ -60,6 +82,13 @@ static void goodix_i2c_hid_power_down(struct i2chid_ops *ops)
struct i2c_hid_of_goodix *ihid_goodix =
container_of(ops, struct i2c_hid_of_goodix, ops);
+ /*
+ * Don't assert reset GPIO or disable regulators if we're keeping the
+ * device powered in suspend.
+ */
+ if (ihid_goodix->powered_in_suspend)
+ return;
+
gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1);
regulator_disable(ihid_goodix->vddio);
regulator_disable(ihid_goodix->vdd);
@@ -91,6 +120,9 @@ static int i2c_hid_of_goodix_probe(struct i2c_client *client)
if (IS_ERR(ihid_goodix->vddio))
return PTR_ERR(ihid_goodix->vddio);
+ ihid_goodix->powered_in_suspend =
+ of_property_read_bool(client->dev.of_node, "powered-in-suspend");
+
ihid_goodix->timings = device_get_match_data(&client->dev);
return i2c_hid_core_probe(client, &ihid_goodix->ops, 0x0001, 0);
--
2.40.0.634.g4ca3ef3211-goog
Hi Fei, On Tue, Apr 18, 2023 at 08:49:52PM +0800, Fei Shao wrote: > In the beginning, commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the > reset line to true state of the regulator") introduced a change to tie > the reset line of the Goodix touchscreen to the state of the regulator > to fix a power leakage issue in suspend. > > After some time, the change was deemed unnecessary and was reverted in > commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to > the regulator") due to difficulties in managing regulator notifiers for > designs like Evoker, which provides a second power rail to touchscreen. > > However, the revert caused a power regression on another Chromebook > device Steelix in the field, which has a dedicated always-on regulator > for touchscreen and was covered by the workaround in the first commit. > > To address both cases, this patch adds the support for the > `powered-in-suspend` property in the driver that allows the driver to > determine whether the touchscreen is still powered in suspend, and > handle the reset GPIO accordingly as below: > - When set to true, the driver does not assert the reset GPIO in power > down. To ensure a clean start and the consistent behavior, it does the > assertion in power up instead. > This is for designs with a dedicated always-on regulator. > - When set to false, the driver uses the original control flow and > asserts GPIO and disable regulators normally. > This is for the two-regulator and shared-regulator designs. > > Signed-off-by: Fei Shao <fshao@chromium.org> > > --- > > drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 46 +++++++++++++++++++++---- > 1 file changed, 39 insertions(+), 7 deletions(-) > > diff --git a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c > index 0060e3dcd775..b438db8ca6f4 100644 > --- a/drivers/hid/i2c-hid/i2c-hid-of-goodix.c > +++ b/drivers/hid/i2c-hid/i2c-hid-of-goodix.c > @@ -28,6 +28,7 @@ struct i2c_hid_of_goodix { > struct regulator *vdd; > struct regulator *vddio; > struct gpio_desc *reset_gpio; > + bool powered_in_suspend; > const struct goodix_i2c_hid_timing_data *timings; > }; > > @@ -37,13 +38,34 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops) > container_of(ops, struct i2c_hid_of_goodix, ops); > int ret; > > - ret = regulator_enable(ihid_goodix->vdd); > - if (ret) > - return ret; > - > - ret = regulator_enable(ihid_goodix->vddio); > - if (ret) > - return ret; > + /* > + * This is to ensure that the reset GPIO will be asserted and the > + * regulators will be enabled for all cases. > + */ > + if (ihid_goodix->powered_in_suspend) { > + /* > + * This is not mandatory, but we assert reset here (instead of > + * in power-down) to ensure that the device will have a clean > + * state later on just like the normal scenarios would have. > + * > + * Also, since the regulators were not disabled in power-down, > + * we don't need to enable them here. > + */ > + gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1); > + } else { > + /* > + * In this case, the reset is already asserted (either in > + * probe or power-down). > + * All we need is to enable the regulators. > + */ > + ret = regulator_enable(ihid_goodix->vdd); > + if (ret) > + return ret; > + > + ret = regulator_enable(ihid_goodix->vddio); > + if (ret) > + return ret; > + } Please let me know in case I have misunderstood, but I don't see a need to change the regulator_enable/disable() logic if this property is set. If the regulators are truly always-on, the regulator core already knows what to do and we should not duplicate that logic here. Based on the alleged silicon erratum discussed in patch [1/2], it seems we only want to control the behavior of the reset GPIO. Therefore, only the calls to gpiod_set_value_cansleep() should be affected and the name of the property updated to reflect what it's actually doing. > > if (ihid_goodix->timings->post_power_delay_ms) > msleep(ihid_goodix->timings->post_power_delay_ms); > @@ -60,6 +82,13 @@ static void goodix_i2c_hid_power_down(struct i2chid_ops *ops) > struct i2c_hid_of_goodix *ihid_goodix = > container_of(ops, struct i2c_hid_of_goodix, ops); > > + /* > + * Don't assert reset GPIO or disable regulators if we're keeping the > + * device powered in suspend. > + */ > + if (ihid_goodix->powered_in_suspend) > + return; > + > gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1); > regulator_disable(ihid_goodix->vddio); > regulator_disable(ihid_goodix->vdd); > @@ -91,6 +120,9 @@ static int i2c_hid_of_goodix_probe(struct i2c_client *client) > if (IS_ERR(ihid_goodix->vddio)) > return PTR_ERR(ihid_goodix->vddio); > > + ihid_goodix->powered_in_suspend = > + of_property_read_bool(client->dev.of_node, "powered-in-suspend"); > + > ihid_goodix->timings = device_get_match_data(&client->dev); > > return i2c_hid_core_probe(client, &ihid_goodix->ops, 0x0001, 0); > -- > 2.40.0.634.g4ca3ef3211-goog > Kind regards, Jeff LaBundy
Hi, On Sun, Apr 23, 2023 at 8:38 PM Jeff LaBundy <jeff@labundy.com> wrote: > > > @@ -37,13 +38,34 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops) > > container_of(ops, struct i2c_hid_of_goodix, ops); > > int ret; > > > > - ret = regulator_enable(ihid_goodix->vdd); > > - if (ret) > > - return ret; > > - > > - ret = regulator_enable(ihid_goodix->vddio); > > - if (ret) > > - return ret; > > + /* > > + * This is to ensure that the reset GPIO will be asserted and the > > + * regulators will be enabled for all cases. > > + */ > > + if (ihid_goodix->powered_in_suspend) { > > + /* > > + * This is not mandatory, but we assert reset here (instead of > > + * in power-down) to ensure that the device will have a clean > > + * state later on just like the normal scenarios would have. > > + * > > + * Also, since the regulators were not disabled in power-down, > > + * we don't need to enable them here. > > + */ > > + gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1); > > + } else { > > + /* > > + * In this case, the reset is already asserted (either in > > + * probe or power-down). > > + * All we need is to enable the regulators. > > + */ > > + ret = regulator_enable(ihid_goodix->vdd); > > + if (ret) > > + return ret; > > + > > + ret = regulator_enable(ihid_goodix->vddio); > > + if (ret) > > + return ret; > > + } > > Please let me know in case I have misunderstood, but I don't see a need > to change the regulator_enable/disable() logic if this property is set. > If the regulators are truly always-on, the regulator core already knows > what to do and we should not duplicate that logic here. > > Based on the alleged silicon erratum discussed in patch [1/2], it seems > we only want to control the behavior of the reset GPIO. Therefore, only > the calls to gpiod_set_value_cansleep() should be affected and the name > of the property updated to reflect what it's actually doing. This would be OK w/ me.
Hi, On Tue, Apr 25, 2023 at 2:16 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Sun, Apr 23, 2023 at 8:38 PM Jeff LaBundy <jeff@labundy.com> wrote: > > > > > @@ -37,13 +38,34 @@ static int goodix_i2c_hid_power_up(struct i2chid_ops *ops) > > > container_of(ops, struct i2c_hid_of_goodix, ops); > > > int ret; > > > > > > - ret = regulator_enable(ihid_goodix->vdd); > > > - if (ret) > > > - return ret; > > > - > > > - ret = regulator_enable(ihid_goodix->vddio); > > > - if (ret) > > > - return ret; > > > + /* > > > + * This is to ensure that the reset GPIO will be asserted and the > > > + * regulators will be enabled for all cases. > > > + */ > > > + if (ihid_goodix->powered_in_suspend) { > > > + /* > > > + * This is not mandatory, but we assert reset here (instead of > > > + * in power-down) to ensure that the device will have a clean > > > + * state later on just like the normal scenarios would have. > > > + * > > > + * Also, since the regulators were not disabled in power-down, > > > + * we don't need to enable them here. > > > + */ > > > + gpiod_set_value_cansleep(ihid_goodix->reset_gpio, 1); > > > + } else { > > > + /* > > > + * In this case, the reset is already asserted (either in > > > + * probe or power-down). > > > + * All we need is to enable the regulators. > > > + */ > > > + ret = regulator_enable(ihid_goodix->vdd); > > > + if (ret) > > > + return ret; > > > + > > > + ret = regulator_enable(ihid_goodix->vddio); > > > + if (ret) > > > + return ret; > > > + } > > > > Please let me know in case I have misunderstood, but I don't see a need > > to change the regulator_enable/disable() logic if this property is set. > > If the regulators are truly always-on, the regulator core already knows > > what to do and we should not duplicate that logic here. Your understanding is totally right, let me restore that in the next revision. Thanks! Regards, Fei > > > > Based on the alleged silicon erratum discussed in patch [1/2], it seems > > we only want to control the behavior of the reset GPIO. Therefore, only > > the calls to gpiod_set_value_cansleep() should be affected and the name > > of the property updated to reflect what it's actually doing. > > This would be OK w/ me.
Hi, On Tue, Apr 18, 2023 at 5:51 AM Fei Shao <fshao@chromium.org> wrote: > > In the beginning, commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the > reset line to true state of the regulator") introduced a change to tie > the reset line of the Goodix touchscreen to the state of the regulator > to fix a power leakage issue in suspend. > > After some time, the change was deemed unnecessary and was reverted in > commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to > the regulator") due to difficulties in managing regulator notifiers for > designs like Evoker, which provides a second power rail to touchscreen. > > However, the revert caused a power regression on another Chromebook > device Steelix in the field, which has a dedicated always-on regulator > for touchscreen and was covered by the workaround in the first commit. > > To address both cases, this patch adds the support for the > `powered-in-suspend` property in the driver that allows the driver to > determine whether the touchscreen is still powered in suspend, and > handle the reset GPIO accordingly as below: > - When set to true, the driver does not assert the reset GPIO in power > down. To ensure a clean start and the consistent behavior, it does the > assertion in power up instead. > This is for designs with a dedicated always-on regulator. > - When set to false, the driver uses the original control flow and > asserts GPIO and disable regulators normally. > This is for the two-regulator and shared-regulator designs. > > Signed-off-by: Fei Shao <fshao@chromium.org> > > --- > > drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 46 +++++++++++++++++++++---- > 1 file changed, 39 insertions(+), 7 deletions(-) I privately reviewed earlier versions of this patch, so it's unsurprising that I have no comments. Assuming that the DT folks don't have any objections to the bindings change, this LGTM. Reviewed-by: Douglas Anderson <dianders@chromium.org>
© 2016 - 2024 Red Hat, Inc.