27 Oct, 2010

1 commit


25 Oct, 2010

4 commits


20 Oct, 2010

1 commit


18 Oct, 2010

1 commit


16 Oct, 2010

1 commit

  • There is a number of problems with acpi_pm_device_sleep_state() now.
    First, if _S0W is not defined, it prevents devices from being put
    into D3 by PCI runtime PM, which shouldn't happen. Second, it
    shouldn't use adev->wakeup.state.enabled, because if it's set, it
    only means that either the device is permanently enabled to wake up
    the system, or that it has been enabled to do that through
    /proc/acpi/wakeup. Finally, it should be compiled if CONFIG_PM_SLEEP
    is not set, so that PCI runtime PM works correctly in that case.
    Fix these problems.

    Reported-by: Matthew Garrett
    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     

02 Oct, 2010

1 commit


01 Oct, 2010

9 commits


29 Sep, 2010

1 commit


25 Sep, 2010

1 commit

  • The current ACPI GPEs initialization code has a problem that it
    enables some GPEs pointed to by device _PRW methods, generally
    intended for signaling wakeup events (system or device wakeup).
    These GPEs are then almost immediately disabled by the ACPI namespace
    scanning code with the help of acpi_gpe_can_wake(), but it would be
    better not to enable them at all until really necessary.

    Modify the initialization of GPEs so that the ones that have
    associated _Lxx or _Exx methods and are not pointed to by any _PRW
    methods will be enabled after the namespace scan is complete.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     

08 Sep, 2010

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
    PCI: bus speed strings should be const
    PCI hotplug: Fix build with CONFIG_ACPI unset
    PCI: PCIe: Remove the port driver module exit routine
    PCI: PCIe: Move PCIe PME code to the pcie directory
    PCI: PCIe: Disable PCIe port services during port initialization
    PCI: PCIe: Ask BIOS for control of all native services at once
    ACPI/PCI: Negotiate _OSC control bits before requesting them
    ACPI/PCI: Do not preserve _OSC control bits returned by a query
    ACPI/PCI: Make acpi_pci_query_osc() return control bits
    ACPI/PCI: Reorder checks in acpi_pci_osc_control_set()
    PCI: PCIe: Introduce commad line switch for disabling port services
    PCI: PCIe AER: Introduce pci_aer_available()
    x86/PCI: only define pci_domain_nr if PCI and PCI_DOMAINS are set
    PCI: provide stub pci_domain_nr function for !CONFIG_PCI configs

    Linus Torvalds
     

25 Aug, 2010

1 commit

  • There is the assumption in acpi_pci_osc_control_set() that it is
    always sufficient to compare the mask of _OSC control bits to be
    requested with the result of an _OSC query where all of the known
    control bits have been checked. However, in general, that need not
    be the case. For example, if an _OSC feature A depends on an _OSC
    feature B and control of A, B plus another _OSC feature C is
    requested simultaneously, the BIOS may return A, B, C, while it would
    only return C if A and C were requested without B.

    That may result in passing a wrong mask of _OSC control bits to an
    _OSC control request, in which case the BIOS may only grant control
    of a subset of the requested features. Moreover, acpi_pci_run_osc()
    will return error code if that happens and the caller of
    acpi_pci_osc_control_set() will not know that it's been granted
    control of some _OSC features. Consequently, the system will
    generally not work as expected.

    Apart from this acpi_pci_osc_control_set() always uses the mask
    of _OSC control bits returned by the very first invocation of
    acpi_pci_query_osc(), but that is done with the second argument
    equal to OSC_PCI_SEGMENT_GROUPS_SUPPORT which generally happens
    to affect the returned _OSC control bits.

    For these reasons, make acpi_pci_osc_control_set() always check if
    control of the requested _OSC features will be granted before making
    the final control request. As a result, the osc_control_qry and
    osc_queried members of struct acpi_pci_root are not necessary any
    more, so drop them and remove the remaining code referring to them.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Jesse Barnes

    Rafael J. Wysocki
     

15 Aug, 2010

4 commits


12 Aug, 2010

1 commit

  • The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d
    (ACPICA: add preemption point after each opcode parse). The follow up
    commits abe1dfab6, 138d15692, c084ca70 tried to fix the preemption logic
    back and forth, but nobody noticed that the usage of
    in_atomic_preempt_off() in that context is wrong.

    The check which guards the call of cond_resched() is:

    if (!in_atomic_preempt_off() && !irqs_disabled())

    in_atomic_preempt_off() is not intended for general use as the comment
    above the macro definition clearly says:

    * Check whether we were atomic before we did preempt_disable():
    * (used by the scheduler, *after* releasing the kernel lock)

    On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by
    accident, but with CONFIG_PREEMPT=y it's just broken.

    The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency
    on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on
    CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check.

    Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210

    [akpm@linux-foundation.org: fix build]
    Signed-off-by: Thomas Gleixner
    Cc: Len Brown
    Cc: Francois Valenduc
    Cc: Lin Ming
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

08 Aug, 2010

1 commit

  • * 'acpica' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits)
    ACPI / ACPICA: Simplify acpi_ev_initialize_gpe_block()
    ACPI / ACPICA: Fail acpi_gpe_wakeup() if ACPI_GPE_CAN_WAKE is unset
    ACPI / ACPICA: Do not execute _PRW methods during initialization
    ACPI: Fix bogus GPE test in acpi_bus_set_run_wake_flags()
    ACPICA: Update version to 20100702
    ACPICA: Fix for Alias references within Package objects
    ACPICA: Fix lint warning for 64-bit constant
    ACPICA: Remove obsolete GPE function
    ACPICA: Update debug output components
    ACPICA: Add support for WDDT - Watchdog Descriptor Table
    ACPICA: Drop acpi_set_gpe
    ACPICA: Use low-level GPE enable during GPE block initialization
    ACPI / EC: Do not use acpi_set_gpe
    ACPI / EC: Drop suspend and resume routines
    ACPICA: Remove wakeup GPE reference counting which is not used
    ACPICA: Introduce acpi_gpe_wakeup()
    ACPICA: Rename acpi_hw_gpe_register_bit
    ACPICA: Update version to 20100528
    ACPICA: Add signatures for undefined tables: ATKG, GSCI, IEIT
    ACPICA: Optimization: Reduce the number of namespace walks
    ...

    Linus Torvalds
     

23 Jul, 2010

1 commit

  • It turns out that there is a bit in the _CST for Intel FFH C3
    that tells the OS if we should be checking BM_STS or not.

    Linux has been unconditionally checking BM_STS.
    If the chip-set is configured to enable BM_STS,
    it can retard or completely prevent entry into
    deep C-states -- as illustrated by turbostat:

    http://userweb.kernel.org/~lenb/acpi/utils/pmtools/turbostat/

    ref: Intel Processor Vendor-Specific ACPI Interface Specification
    table 4 "_CST FFH GAS Field Encoding"
    Bit 1: Set to 1 if OSPM should use Bus Master avoidance for this C-state

    https://bugzilla.kernel.org/show_bug.cgi?id=15886

    Signed-off-by: Len Brown

    Len Brown
     

13 Jul, 2010

1 commit

  • Currently, during initialization ACPICA walks the entire ACPI
    namespace in search of any device objects with assciated _PRW
    methods. All of the _PRW methods found are executed in the process
    to extract the GPE information returned by them, so that the GPEs in
    question can be marked as "able to wakeup" (more precisely, the
    ACPI_GPE_CAN_WAKE flag is set for them). The only purpose of this
    exercise is to avoid enabling the CAN_WAKE GPEs automatically, even
    if there are _Lxx/_Exx methods associated with them. However, it is
    both costly and unnecessary, because the host OS has to execute the
    _PRW methods anyway to check which devices can wake up the system
    from sleep states. Moreover, it then uses full information
    returned by _PRW, including the GPE information, so it can take care
    of disabling the GPEs if necessary.

    Remove the code that walks the namespace and executes _PRW from
    ACPICA and modify comments to reflect that change. Make
    acpi_bus_set_run_wake_flags() disable GPEs for wakeup devices
    so that they don't cause spurious wakeup events to be signaled.
    This not only reduces the complexity of the ACPICA initialization
    code, but in some cases it should reduce the kernel boot time as
    well.

    Unfortunately, for this purpose we need a new ACPICA function,
    acpi_gpe_can_wake(), to be called by the host OS in order to disable
    the GPEs that can wake up the system and were previously enabled by
    acpi_ev_initialize_gpe_block() or acpi_ev_update_gpes() (such a GPE
    should be disabled only once, because the initialization code enables
    it only once, but it may be pointed to by _PRW for multiple devices
    and that's why the additional function is necessary).

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     

07 Jul, 2010

8 commits

  • Version 20100702.

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     
  • Add data table compiler output component

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     
  • Header file support.

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     
  • The acpi_set_gpe() function is a little awkward, because it doesn't
    really work as advertised in the "disable" case. Namely, if a GPE
    has been enabled with acpi_enable_gpe() and triggered a notification
    to occur, and if acpi_set_gpe() is used to disable it before
    acpi_ev_asynch_enable_gpe() runs, the GPE will be immediately enabled
    by the latter as though the acpi_set_gpe() had no effect.

    Thus, since it's been possible to make all of its callers use
    alternative operations to disable or enable GPEs, acpi_set_gpe() can
    be dropped.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     
  • After the previous patch that introduced acpi_gpe_wakeup() and
    modified the ACPI suspend and wakeup code to use it, the third
    argument of acpi_{enable|disable}_gpe() and the GPE wakeup
    reference counter are not necessary any more. Remove them and
    modify all of the users of acpi_{enable|disable}_gpe()
    accordingly. Also drop GPE type constants that aren't used
    any more.

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown
    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     
  • ACPICA uses reference counters to avoid disabling GPEs too early in
    case they have been enabled for many times. This is done separately
    for runtime and for wakeup, but the wakeup GPE reference counter is
    not really necessary, because GPEs are only enabled to wake up the
    system at the hardware level by acpi_enter_sleep_state(). Thus it
    only is necessary to set the corresponding bits in the wakeup enable
    masks of these GPEs' registers right before the system enters a sleep
    state. Moreover, the GPE wakeup enable bits can only be set when the
    target sleep state of the system is known and they need to be cleared
    immediately after wakeup regardless of how many wakeup devices are
    associated with a given GPE.

    On the basis of the above observations, introduce function
    acpi_gpe_wakeup() to be used for setting or clearing the enable bit
    corresponding to a given GPE in its enable register's enable_for_wake
    mask. Modify the ACPI suspend and wakeup code the use
    acpi_gpe_wakeup() instead of acpi_{enable|disable}_gpe() to set
    and clear GPE enable bits in their registers' enable_for_wake masks
    during system transitions to a sleep state and back to the working
    state, respectively. [This will allow us to drop the third
    argument of acpi_{enable|disable}_gpe() and simplify the GPE
    handling code.]

    Signed-off-by: Rafael J. Wysocki
    Signed-off-by: Len Brown
    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     
  • Version 20100528.

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     
  • These ACPI tables have been seen in the field, but the actual
    table definitions are unkown at this time.

    Signed-off-by: Bob Moore
    Signed-off-by: Lin Ming
    Signed-off-by: Len Brown

    Bob Moore
     

12 Jun, 2010

2 commits