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
next prev parent 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).