linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Duggan <aduggan@synaptics.com>
To: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: linux-input@vger.kernel.org, benjamin.tissoires@redhat.com,
	jkosina@suse.cz
Subject: Re: hid-rmi: configuration automatically changed after suspend/resume
Date: Mon, 6 Jul 2015 16:47:57 -0700	[thread overview]
Message-ID: <559B13AD.50103@synaptics.com> (raw)
In-Reply-To: <1463383.73UKVcFjqX@xps13>

Hi Gabriele,

On 07/06/2015 03:20 AM, Gabriele Mazzotta wrote:
> Hi,
>
> I recently noticed that there's a minor issue with hid-rmi.c. After a
> suspend/resume cycle the f11 control register is set to the default
> configuration, thus undoing the changes performed on init.

This is because i2c_hid does a reset of the touchpad during resume. 
Power cycles or resets will clear the changes to the control registers. 
There isn't a way to make these changes persistent without changing the 
firmware.

> I made some changes to the driver to prevent this from happening: the
> configuration is saved on suspend and restored upon resume. This seemed
> the simplest thing to do, but I encountered a small problem.

I haven't been able to successfully complete reads which I perform in 
the suspend callback. They end up timing out waiting for the response. 
Maybe this is only an issue on certain platforms if this is working for you.

>
> I'm saving and writing the whole register since the kernel can't know
> what userspace tools might have done. According to a comment in the
> sources, some firmwares split the control register, so blindly copying
> and writing 20 sequential bytes as I'm doing could be a problem.

Since reading from the suspend callback doesn't seem to be reliable on 
all platforms, I think it would  be better to store the values of the 
control registers on init. The driver can update the stored values and 
write that back to the device on init and after coming out of resume. 
This will overwrite any changes done by userspace tools. But, if it is 
important enough to have a F11 control register change persist over 
suspend / resume then it should probably be implemented in the hid-rmi 
anyway.

> Is there a way to recognize those firmwares? Or even better, is there a
> way to prevent the firmware from restoring the default configuration?

This bug can be worked around by only reading a max of 16 bytes at a 
time. So to read all 20 you can just read 16, then add 16 to the address 
and read the remaining 4. Also, the size of the control registers 
depends on the configuration so it could be more or less then 20. Did 
you have a particular register that you want to change which isn't 
currently in hid-rmi?

> PS: I didn't check if the same happens with other registers, but I
> suspenct it does.
>
> Thanks,
> Gabriele

In the meantime I have another patch to post related to suspend / 
resume. I'm going to go ahead and post that now to avoid conflicts.

Andrew

  reply	other threads:[~2015-07-06 23:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 10:20 hid-rmi: configuration automatically changed after suspend/resume Gabriele Mazzotta
2015-07-06 23:47 ` Andrew Duggan [this message]
2015-07-07 10:01   ` Gabriele Mazzotta
2015-07-07 14:45     ` Benjamin Tissoires

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=559B13AD.50103@synaptics.com \
    --to=aduggan@synaptics.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=gabriele.mzt@gmail.com \
    --cc=jkosina@suse.cz \
    --cc=linux-input@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).