From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
linux-pwm@vger.kernel.org, linux-acpi@vger.kernel.org,
"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH 2/2] pwm: lpss: Check PWM powerstate after resume on Cherry Trail devices
Date: Mon, 24 Sep 2018 12:18:41 +0300 [thread overview]
Message-ID: <20180924091841.GG15943@smile.fi.intel.com> (raw)
In-Reply-To: <c5eb93ac-c072-2343-5dd6-8642f45db8fb@redhat.com>
On Mon, Sep 24, 2018 at 11:10:28AM +0200, Hans de Goede wrote:
> > > + /* The PWM may be turned on by AML code, update our state to match */
> > > + if (pm_runtime_suspended(dev) && lpwm->info->check_power_on_resume) {
> >
> > > + status = acpi_evaluate_integer(ACPI_HANDLE(dev), "_PSC",
> > > + NULL, &psc);
> >
> > AFAIU this is a standard power source method for ACPI, shouldn't ACPI core take
> > care of being in sync?
>
> This is not about ACPI power-resources, this is about the power state (D0 or D3)
> of the device itself. The ACPI core does not expect the state of devices to
> magically change underneath it when using s2idle, since then everything is
> under the kernel's control. But the _PS0 method of the GPU messing with the PWM
> controller (hurray for firmware) messes things up.
What I mean is shouldn't we care about this on a ACPI core level to be sure
that states are kept in sync on OS level?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2018-09-24 9:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 17:30 [PATCH 1/2] pwm: lpss: Move struct pwm_lpss_chip definition to the header file Hans de Goede
2018-09-11 17:30 ` [PATCH 2/2] pwm: lpss: Check PWM powerstate after resume on Cherry Trail devices Hans de Goede
2018-09-24 9:02 ` Andy Shevchenko
2018-09-24 9:10 ` Hans de Goede
2018-09-24 9:18 ` Andy Shevchenko [this message]
2018-09-24 9:40 ` Hans de Goede
2018-10-03 9:22 ` Rafael J. Wysocki
2018-10-06 8:55 ` Hans de Goede
2018-10-06 14:16 ` Andy Shevchenko
2018-10-10 11:14 ` Hans de Goede
2018-10-11 12:07 ` Andy Shevchenko
2018-10-11 14:00 ` Rafael J. Wysocki
2018-10-11 14:11 ` Hans de Goede
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=20180924091841.GG15943@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=thierry.reding@gmail.com \
/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.