| Message ID | 20230418124953.3170028-3-fshao@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Fix Goodix touchscreen power leakage for MT8186 boards | expand |
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>
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.
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);
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(-)