| Message ID | 20180312190907.174301-2-dmitry.torokhov@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Dmitry- Thanks for sending these patches! On Mon, Mar 12, 2018 at 12:08:54PM -0700, Dmitry Torokhov wrote: > The way we are supposed to put controller to sleep and wake it up does not > depend on the platform, but rather on controller itself. Controllers using > T9 require manipulating T9 control register, while others, using newer > T100, should be put to sleep by adjusting T7 power config. I'm afraid this is actually a misconception. If you look at object table for the older T9 device, you'll find it has the T7 object and it in fact works exactly the same way as the T100-based device. The MXT_SUSPEND_T9_CTRL is in there because on your older Pixel devices the config saved into NVRAM on the touch controller has a zero byte in the T9 CTRL setting, meaning the touch controller will never wake up unless the driver knows to write 0x83 into it. > We'll keep pdata->suspend_mode for now and remove it when we rework > chromeos-laptop driver. > > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> > --- > drivers/input/touchscreen/atmel_mxt_ts.c | 15 ++++++--------- > 1 file changed, 6 insertions(+), 9 deletions(-) > > diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c > index 7659bc48f1db8..1aabfae1297ba 100644 > --- a/drivers/input/touchscreen/atmel_mxt_ts.c > +++ b/drivers/input/touchscreen/atmel_mxt_ts.c > @@ -2868,8 +2868,8 @@ static const struct attribute_group mxt_attr_group = { > > static void mxt_start(struct mxt_data *data) > { > - switch (data->pdata->suspend_mode) { > - case MXT_SUSPEND_T9_CTRL: > + switch (data->multitouch) { > + case MXT_TOUCH_MULTI_T9: > mxt_soft_reset(data); > > /* Touch enable */ > @@ -2878,7 +2878,7 @@ static void mxt_start(struct mxt_data *data) > MXT_TOUCH_MULTI_T9, MXT_T9_CTRL, 0x83); > break; > > - case MXT_SUSPEND_DEEP_SLEEP: > + case MXT_TOUCH_MULTITOUCHSCREEN_T100: > default: > mxt_set_t7_power_cfg(data, MXT_POWER_CFG_RUN); > > @@ -2886,19 +2886,18 @@ static void mxt_start(struct mxt_data *data) > mxt_t6_command(data, MXT_COMMAND_CALIBRATE, 1, false); > break; > } > - > } > > static void mxt_stop(struct mxt_data *data) > { > - switch (data->pdata->suspend_mode) { > - case MXT_SUSPEND_T9_CTRL: > + switch (data->multitouch) { > + case MXT_TOUCH_MULTI_T9: > /* Touch disable */ > mxt_write_object(data, > MXT_TOUCH_MULTI_T9, MXT_T9_CTRL, 0); > break; > > - case MXT_SUSPEND_DEEP_SLEEP: > + case MXT_TOUCH_MULTITOUCHSCREEN_T100: > default: > mxt_set_t7_power_cfg(data, MXT_POWER_CFG_DEEPSLEEP); > break; > @@ -2954,8 +2953,6 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client) > pdata->t19_keymap = keymap; > } > > - pdata->suspend_mode = MXT_SUSPEND_DEEP_SLEEP; > - > return pdata; > } > #else > -- > 2.16.2.660.g709887971b-goog > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 14, 2018 at 08:51:24PM +0000, Nick Dyer wrote: > Hi Dmitry- > > Thanks for sending these patches! > > On Mon, Mar 12, 2018 at 12:08:54PM -0700, Dmitry Torokhov wrote: > > The way we are supposed to put controller to sleep and wake it up does not > > depend on the platform, but rather on controller itself. Controllers using > > T9 require manipulating T9 control register, while others, using newer > > T100, should be put to sleep by adjusting T7 power config. > > I'm afraid this is actually a misconception. If you look at object table > for the older T9 device, you'll find it has the T7 object and it in fact > works exactly the same way as the T100-based device. > > The MXT_SUSPEND_T9_CTRL is in there because on your older Pixel devices > the config saved into NVRAM on the touch controller has a zero byte in > the T9 CTRL setting, meaning the touch controller will never wake up > unless the driver knows to write 0x83 into it. Ah, OK, I see. I would really like to drop this pdata->suspend_mode stuff and I do not want to create "pixel-screwed-up" property either... I guess for the time being I'll put a DMI quirk for Link to restore T9 control method, and then look into cleaning it all up. We have quite a bit different code in chromeos kernel trees and I'd like to reconcile it. Thanks.
On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote: > On Wed, Mar 14, 2018 at 08:51:24PM +0000, Nick Dyer wrote: > > On Mon, Mar 12, 2018 at 12:08:54PM -0700, Dmitry Torokhov wrote: > > > The way we are supposed to put controller to sleep and wake it up does not > > > depend on the platform, but rather on controller itself. Controllers using > > > T9 require manipulating T9 control register, while others, using newer > > > T100, should be put to sleep by adjusting T7 power config. > > > > I'm afraid this is actually a misconception. If you look at object table > > for the older T9 device, you'll find it has the T7 object and it in fact > > works exactly the same way as the T100-based device. > > > > The MXT_SUSPEND_T9_CTRL is in there because on your older Pixel devices > > the config saved into NVRAM on the touch controller has a zero byte in > > the T9 CTRL setting, meaning the touch controller will never wake up > > unless the driver knows to write 0x83 into it. > > Ah, OK, I see. I would really like to drop this pdata->suspend_mode > stuff and I do not want to create "pixel-screwed-up" property either... > I guess for the time being I'll put a DMI quirk for Link to restore T9 > control method, and then look into cleaning it all up. We have quite a > bit different code in chromeos kernel trees and I'd like to reconcile > it. Yes, it would be great to get rid of it. The driver does have the ability to download configuration via the firmware loader interface. So you would be able to grab a copy of the config by saving it with mxt-app, tweak it to ensure that the T9 CTRL byte is set correctly, then ship it somehow (presumably it could be added to linux-firmware). This would override what's currently stored in NVRAM on all those units and mean we could remove the T9_CTRL stuff. I'm happy to talk you through sorting that out in more detail if you want to give it a go. I don't have any Pixel 1 hardware available at the moment, unfortunately. N -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Mar 16, 2018 at 08:40:02PM +0000, Nick Dyer wrote: > On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote: > > On Wed, Mar 14, 2018 at 08:51:24PM +0000, Nick Dyer wrote: > > > On Mon, Mar 12, 2018 at 12:08:54PM -0700, Dmitry Torokhov wrote: > > > > The way we are supposed to put controller to sleep and wake it up does not > > > > depend on the platform, but rather on controller itself. Controllers using > > > > T9 require manipulating T9 control register, while others, using newer > > > > T100, should be put to sleep by adjusting T7 power config. > > > > > > I'm afraid this is actually a misconception. If you look at object table > > > for the older T9 device, you'll find it has the T7 object and it in fact > > > works exactly the same way as the T100-based device. > > > > > > The MXT_SUSPEND_T9_CTRL is in there because on your older Pixel devices > > > the config saved into NVRAM on the touch controller has a zero byte in > > > the T9 CTRL setting, meaning the touch controller will never wake up > > > unless the driver knows to write 0x83 into it. > > > > Ah, OK, I see. I would really like to drop this pdata->suspend_mode > > stuff and I do not want to create "pixel-screwed-up" property either... > > I guess for the time being I'll put a DMI quirk for Link to restore T9 > > control method, and then look into cleaning it all up. We have quite a > > bit different code in chromeos kernel trees and I'd like to reconcile > > it. > > Yes, it would be great to get rid of it. The driver does have the > ability to download configuration via the firmware loader interface. So > you would be able to grab a copy of the config by saving it with > mxt-app, tweak it to ensure that the T9 CTRL byte is set correctly, then > ship it somehow (presumably it could be added to linux-firmware). This > would override what's currently stored in NVRAM on all those units and > mean we could remove the T9_CTRL stuff. We can't really rely on people fetching updated config. Do you think we could see if the device has only T9 and not T100 and if coming out of suspend the T9 CTRL byte is 0 we overwrite it with the 0x83? > > I'm happy to talk you through sorting that out in more detail if you > want to give it a go. I don't have any Pixel 1 hardware available at the > moment, unfortunately. Yes, I have several Chromebooks with Atmel so I can try on a few of them. Thanks.
On Sat, Mar 17, 2018 at 10:42:40AM -0700, Dmitry Torokhov wrote: > On Fri, Mar 16, 2018 at 08:40:02PM +0000, Nick Dyer wrote: > > On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote: > > > Ah, OK, I see. I would really like to drop this > > > pdata->suspend_mode stuff and I do not want to create > > > "pixel-screwed-up" property either... I guess for the time being > > > I'll put a DMI quirk for Link to restore T9 control method, and > > > then look into cleaning it all up. We have quite a bit different > > > code in chromeos kernel trees and I'd like to reconcile > > > it. > > > > Yes, it would be great to get rid of it. The driver does have the > > ability to download configuration via the firmware loader interface. > > So you would be able to grab a copy of the config by saving it with > > mxt-app, tweak it to ensure that the T9 CTRL byte is set correctly, > > then ship it somehow (presumably it could be added to > > linux-firmware). This would override what's currently stored in > > NVRAM on all those units and mean we could remove the T9_CTRL stuff. > > We can't really rely on people fetching updated config. Do you think we > could see if the device has only T9 and not T100 and if coming out of > suspend the T9 CTRL byte is 0 we overwrite it with the 0x83? I think that all we need to do is add something to mxt_read_t9_resolution (and probably rename it to mxt_init_t9_config) that reads the 1st (CTRL) byte, and if it's zero, writes 0x83 (and probably a dev_dbg() wouldn't go amiss) Also call the same logic on reset (look for "Detect reset"), because that wipes out the config. Once we've done that, we can get rid of the MXT_SUSPEND_T9_CTRL and use the normal T7 power up/down logic for suspend/resume on all devices. FWIW there may be two instances of T9, but I've never seen a device that actually had two screens and it's not supported really anyway with this driver. N -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c index 7659bc48f1db8..1aabfae1297ba 100644 --- a/drivers/input/touchscreen/atmel_mxt_ts.c +++ b/drivers/input/touchscreen/atmel_mxt_ts.c @@ -2868,8 +2868,8 @@ static const struct attribute_group mxt_attr_group = { static void mxt_start(struct mxt_data *data) { - switch (data->pdata->suspend_mode) { - case MXT_SUSPEND_T9_CTRL: + switch (data->multitouch) { + case MXT_TOUCH_MULTI_T9: mxt_soft_reset(data); /* Touch enable */ @@ -2878,7 +2878,7 @@ static void mxt_start(struct mxt_data *data) MXT_TOUCH_MULTI_T9, MXT_T9_CTRL, 0x83); break; - case MXT_SUSPEND_DEEP_SLEEP: + case MXT_TOUCH_MULTITOUCHSCREEN_T100: default: mxt_set_t7_power_cfg(data, MXT_POWER_CFG_RUN); @@ -2886,19 +2886,18 @@ static void mxt_start(struct mxt_data *data) mxt_t6_command(data, MXT_COMMAND_CALIBRATE, 1, false); break; } - } static void mxt_stop(struct mxt_data *data) { - switch (data->pdata->suspend_mode) { - case MXT_SUSPEND_T9_CTRL: + switch (data->multitouch) { + case MXT_TOUCH_MULTI_T9: /* Touch disable */ mxt_write_object(data, MXT_TOUCH_MULTI_T9, MXT_T9_CTRL, 0); break; - case MXT_SUSPEND_DEEP_SLEEP: + case MXT_TOUCH_MULTITOUCHSCREEN_T100: default: mxt_set_t7_power_cfg(data, MXT_POWER_CFG_DEEPSLEEP); break; @@ -2954,8 +2953,6 @@ static const struct mxt_platform_data *mxt_parse_dt(struct i2c_client *client) pdata->t19_keymap = keymap; } - pdata->suspend_mode = MXT_SUSPEND_DEEP_SLEEP; - return pdata; } #else
The way we are supposed to put controller to sleep and wake it up does not depend on the platform, but rather on controller itself. Controllers using T9 require manipulating T9 control register, while others, using newer T100, should be put to sleep by adjusting T7 power config. We'll keep pdata->suspend_mode for now and remove it when we rework chromeos-laptop driver. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> --- drivers/input/touchscreen/atmel_mxt_ts.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-)