From: Mika Westerberg <mika.westerberg@linux.intel.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <benjamin.tissoires@redhat.com>,
Andrew Duggan <aduggan@synaptics.com>,
Benson Leung <bleung@chromium.org>,
Dan Carpenter <dan.carpenter@oracle.com>,
Gabriele Mazzotta <gabriele.mzt@gmail.com>,
Doug Anderson <dianders@chromium.org>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH v3] HID: i2c-hid: Fix suspend/resume when already runtime suspended
Date: Wed, 9 Mar 2016 14:04:11 +0200 [thread overview]
Message-ID: <20160309120411.GF1796@lahna.fi.intel.com> (raw)
In-Reply-To: <20160308230323.GA4382@dtor-ws>
On Tue, Mar 08, 2016 at 03:03:23PM -0800, Dmitry Torokhov wrote:
> On ACPI-based systems ACPI power domain code runtime resumes device before
> calling suspend method, which ensures that i2c-hid suspend code starts with
> device not in low-power state and with interrupts enabled.
>
> On other systems, especially if device is not a part of any power domain,
> we may end up calling driver's system-level suspend routine while the
> device is runtime-suspended (with controller in presumably low power state
> and interrupts disabled). This will result in interrupts being essentially
> disabled twice, and we will only re-enable them after both system resume
> and runtime resume methods complete. Unfortunately i2c_hid_resume() calls
> i2c_hid_hwreset() and that only works properly if interrupts are enabled.
>
> Also if device is runtime-suspended driver's suspend code may fail if it
> tries to issue I/O requests.
>
> Let's fix it by runtime-resuming the device if we need to run HID driver's
> suspend code and also disabling interrupts only if device is not already
> runtime-suspended. Also on resume we mark the device as running at full
> power (since that is what resetting will do to it).
>
> Signed-off-by: Doug Anderson <dianders@chromium.org>
> Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Tested on a couple of Intel Skylake and Baytrail based systems and power
management of I2C connected HID devices still seems to work just fine.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
next prev parent reply other threads:[~2016-03-09 12:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 23:03 [PATCH v3] HID: i2c-hid: Fix suspend/resume when already runtime suspended Dmitry Torokhov
2016-03-08 23:13 ` Benson Leung
2016-03-09 12:04 ` Mika Westerberg [this message]
2016-03-09 19:56 ` Benjamin Tissoires
2016-03-09 20:53 ` Jiri Kosina
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=20160309120411.GF1796@lahna.fi.intel.com \
--to=mika.westerberg@linux.intel.com \
--cc=aduggan@synaptics.com \
--cc=benjamin.tissoires@redhat.com \
--cc=bleung@chromium.org \
--cc=dan.carpenter@oracle.com \
--cc=dianders@chromium.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gabriele.mzt@gmail.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.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.