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:

quoted

On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote:

quoted

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