All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Dyer <nick@shmanahar.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org, Benson Leung <bleung@chromium.org>,
	Olof Johansson <olof@lixom.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in platform data
Date: Sat, 17 Mar 2018 20:42:22 +0000	[thread overview]
Message-ID: <20180317204222.th54qyuajgam7iek@hairyalien> (raw)
In-Reply-To: <20180317174240.GC183240@dtor-ws>

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

  reply	other threads:[~2018-03-17 20:42 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-12 19:08 [PATCH 00/14] chrome_laptop: stop being a platform driver Dmitry Torokhov
2018-03-12 19:08 ` [PATCH 01/14] Input: atmel_mxt_ts - do not pass suspend mode in platform data Dmitry Torokhov
2018-03-14 20:51   ` Nick Dyer
2018-03-15 23:56     ` Dmitry Torokhov
2018-03-16 20:40       ` Nick Dyer
2018-03-17 17:42         ` Dmitry Torokhov
2018-03-17 20:42           ` Nick Dyer [this message]
2018-03-12 19:08 ` [PATCH 02/14] Input: atmel_mxt_ts - switch from OF to generic device properties Dmitry Torokhov
2018-03-14 20:51   ` Nick Dyer
2018-03-12 19:08 ` [PATCH 03/14] Input: atmel_mxt_ts - switch ChromeOS ACPI devices to generic props Dmitry Torokhov
2018-03-14 20:52   ` Nick Dyer
2018-03-12 19:08 ` [PATCH 04/14] platform/chrome: chromeos_laptop - add SPDX identifier Dmitry Torokhov
2018-03-20  1:53   ` Benson Leung
2018-03-12 19:08 ` [PATCH 05/14] platform/chrome: chromeos_laptop - stop setting suspend mode for Atmel devices Dmitry Torokhov
2018-03-12 19:08 ` [PATCH 06/14] platform/chrome: chromeos_laptop - introduce pr_fmt() Dmitry Torokhov
2018-03-20  2:03   ` Benson Leung
2018-03-12 19:09 ` [PATCH 07/14] platform/chrome: chromeos_laptop - factor out getting IRQ from DMI Dmitry Torokhov
2018-03-20  2:14   ` Benson Leung
2018-03-12 19:09 ` [PATCH 08/14] platform/chrome: chromeos_laptop - rework i2c peripherals initialization Dmitry Torokhov
2018-03-12 19:09 ` [PATCH 09/14] platform/chrome: chromeos_laptop - parse DMI IRQ data once Dmitry Torokhov
2018-03-12 19:09 ` [PATCH 10/14] platform/chrome: chromeos_laptop - use I2C notifier to create devices Dmitry Torokhov
2018-03-12 19:09 ` [PATCH 11/14] platform/chrome: chromeos_laptop - rely on I2C to set up interrupt trigger Dmitry Torokhov
2018-03-12 19:09 ` [PATCH 12/14] platform/chrome: chromeos_laptop - use device properties for Pixel Dmitry Torokhov
2018-03-12 19:09 ` [PATCH 13/14] platform/chrome: chromeos_laptop - discard data for unneeded boards Dmitry Torokhov
2018-03-12 19:09 ` [PATCH 14/14] Input: atmel_mxt_ts - remove platform data support Dmitry Torokhov
2018-03-14 20:59   ` Nick Dyer
2018-03-16  0:06     ` Dmitry Torokhov
2018-03-16 20:41       ` Nick Dyer
2018-03-12 19:17 ` [PATCH 00/14] chrome_laptop: stop being a platform driver Benson Leung

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180317204222.th54qyuajgam7iek@hairyalien \
    --to=nick@shmanahar.org \
    --cc=bleung@chromium.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.