lkml.org 
[lkml]   [2012]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] ACPI / PCI: Make _SxD/_SxW check follow ACPI 4.0a spec
    On Mon, Apr 30, 2012 at 3:41 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
    > On Monday, April 30, 2012, Bjorn Helgaas wrote:
    >> On Sun, Apr 29, 2012 at 2:44 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
    >> > From: Oleksij Rempel <bug-track@fisher-privat.net>
    >> >
    >> > This patch makes _SxD/_SxW check follow the ACPI 4.0a specification
    >> > more closely and fixes suspend bug found on ASUS Zenbook UX31E.
    >> >
    >> > Some OEM use _SxD fileds do blacklist brocken Dx states.
    >> > If _SxD/_SxW return values are check before suspend as appropriate,
    >> > some nasty suspend/resume issues may be avoided.
    >> >
    >> > References: https://bugzilla.kernel.org/show_bug.cgi?id=42728
    >> > Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
    >> > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    >> > ---
    >> >
    >> > Bjorn, Len,
    >> >
    >> > This is -stable material and therefore v3.4 as well, IMO.  Please let me
    >> > know if one of you can take it or whether you want me to handle it all the
    >> > way to Linus.
    >>
    >> I'm OK with this from a PCI perspective.  Most of the change is in
    >> ACPI, so I propose that either you or Len take care of it.
    >>
    >> The second paragraph of the changelog has several typos
    >> (fileds/fields, do/to, brocken/broken, etc).
    >
    > Thanks for spotting that, the version below should be better.
    >
    > I'll wait for Len to respond till Friday and will take care of the patch myself
    > if he doesn't say anything.
    >
    > May I assume an ACK from you?

    Yep, sorry :)

    Acked-by: Bjorn Helgaas <bhelgaas@google.com>

    > ---
    > From: Oleksij Rempel <bug-track@fisher-privat.net>
    > Subject: ACPI / PCI: Make _SxD/_SxW check follow ACPI 4.0a spec
    >
    > This patch makes _SxD/_SxW check follow the ACPI 4.0a specification
    > more closely and fixes suspend bug found on ASUS Zenbook UX31E.
    >
    > Some OEM use _SxD fields to blacklist broken device Dx states, so
    > if _SxD/_SxW return values are checked before suspend as appropriate,
    > some nasty suspend/resume issues may be avoided.
    >
    > References: https://bugzilla.kernel.org/show_bug.cgi?id=42728
    > Signed-off-by: Oleksij Rempel <bug-track@fisher-privat.net>
    > Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
    > ---
    >  drivers/acpi/sleep.c |   22 +++++++++++++++++++++-
    >  drivers/pci/pci.c    |   12 +++++++++++-
    >  2 files changed, 32 insertions(+), 2 deletions(-)
    >
    > Index: linux/drivers/acpi/sleep.c
    > ===================================================================
    > --- linux.orig/drivers/acpi/sleep.c
    > +++ linux/drivers/acpi/sleep.c
    > @@ -720,10 +720,30 @@ int acpi_pm_device_sleep_state(struct de
    >         *
    >         * NOTE: We rely on acpi_evaluate_integer() not clobbering the integer
    >         * provided -- that's our fault recovery, we ignore retval.
    > +        *
    > +        * According to ACPI 4.0a (April 5, 2010), page 294,
    > +        * Table 7-7 S3 Action / Result Table, we need to evaluate _SxW in
    > +        * addition to _SxD if the device is configured for wakeup:
    > +        * Desired Action    | _S3D | _PRW | _S3W | Resultant D-state
    > +        * Enter S3          |  N/A |  D/C |  N/A | OSPM decides
    > +        * Enter S3, No Wake |   2  |  D/C |  D/C | Enter D2 or D3
    > +        * Enter S3, Wake    |   2  |   3  |  N/A | Enter D2
    > +        * Enter S3, Wake    |   2  |   3  |   3  | Enter D2 or D3
    > +        * Enter S3, Wake    |  N/A |   3  |   2  | Enter D0, D1 or D2
    >         */
    > -       if (acpi_target_sleep_state > ACPI_STATE_S0)
    > +       if (acpi_target_sleep_state > ACPI_STATE_S0) {
    > +               acpi_status status;
    > +
    >                acpi_evaluate_integer(handle, acpi_method, NULL, &d_min);
    >
    > +               if (device_may_wakeup(dev)) {
    > +                       acpi_method[3] = 'W';
    > +                       status = acpi_evaluate_integer(handle, acpi_method,
    > +                                                      NULL, &d_max);
    > +                       if (ACPI_FAILURE(status))
    > +                               d_max = d_min;
    > +               }
    > +       }
    >        /*
    >         * If _PRW says we can wake up the system from the target sleep state,
    >         * the D-state returned by _SxD is sufficient for that (we assume a
    > Index: linux/drivers/pci/pci.c
    > ===================================================================
    > --- linux.orig/drivers/pci/pci.c
    > +++ linux/drivers/pci/pci.c
    > @@ -1691,10 +1691,20 @@ pci_power_t pci_target_state(struct pci_
    >  {
    >        pci_power_t target_state = PCI_D3hot;
    >
    > -       if (platform_pci_power_manageable(dev)) {
    > +       /*
    > +        * According to ACPI 4.0a,7.2 Device Power Management Objects, device
    > +        * with wake capability should have _PRW or _PSW object and can have
    > +        * _SxD or _SxW object.
    > +        * It looks like some OEMs use this fields to avoid buggy Dx states
    > +        * of devices, so we need to check for _PRW or _PSW and see if _SxD or
    > +        * _SxW indicate to overwrite Dx.
    > +        */
    > +       if (platform_pci_power_manageable(dev)
    > +           || platform_pci_can_wakeup(dev)) {
    >                /*
    >                 * Call the platform to choose the target state of the device
    >                 * and enable wake-up from this state if supported.
    > +                * (Check _SxD and _SxW)
    >                 */
    >                pci_power_t state = platform_pci_choose_state(dev);
    >
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2012-05-01 00:01    [W:3.280 / U:0.996 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site