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

6 commits

  • Len Brown
     
  • This feature is optional and is enabled if the BIOS requests any
    Windows OSI strings. It can also be enabled by the host OS.

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

    Matthew Garrett
     
  • Was incorrectly AE_WAKE_ONLY_GPE.

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

    Bob Moore
     
  • Len Brown
     
  • ACPICA uses acpi_hw_write_gpe_enable_reg() to re-enable a GPE after
    an event signaled by it has been handled. However, this function
    writes the entire GPE enable mask to the GPE's enable register which
    may not be correct. Namely, if one of the other GPEs in the same
    register was previously enabled by acpi_enable_gpe() and subsequently
    disabled using acpi_set_gpe(), acpi_hw_write_gpe_enable_reg() will
    re-enable it along with the target GPE.

    To fix this issue rework acpi_hw_write_gpe_enable_reg() so that it
    calls acpi_hw_low_set_gpe() with a special action value,
    ACPI_GPE_COND_ENABLE, that will make it only enable the GPE if the
    corresponding bit in its register's enable_for_run mask is set.

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

    Rafael J. Wysocki
     
  • ACPICA uses acpi_ev_enable_gpe() for enabling GPEs at the low level,
    which is incorrect, because this function only enables the GPE if the
    corresponding bit in its enable register's enable_for_run mask is set.
    This causes acpi_set_gpe() to work incorrectly if used for enabling
    GPEs that were not previously enabled with acpi_enable_gpe(). As a
    result, among other things, wakeup-only GPEs are never enabled by
    acpi_enable_wakeup_device(), so the devices that use them are unable
    to wake up the system.

    To fix this issue remove acpi_ev_enable_gpe() and its counterpart
    acpi_ev_disable_gpe() and replace acpi_hw_low_disable_gpe() with
    acpi_hw_low_set_gpe() that will be used instead to manipulate GPE
    enable bits at the low level. Make the users of acpi_ev_enable_gpe()
    and acpi_ev_disable_gpe() call acpi_hw_low_set_gpe() instead and
    make sure that GPE enable masks are only updated by acpi_enable_gpe()
    and acpi_disable_gpe() when GPE reference counters change from 0
    to 1 and from 1 to 0, respectively.

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

    Rafael J. Wysocki
     

29 May, 2010

4 commits


22 May, 2010

1 commit


20 May, 2010

4 commits

  • ERST is a way provided by APEI to save and retrieve hardware error
    record to and from some simple persistent storage (such as flash).

    The Linux kernel support implementation is quite simple and workable
    in NMI context. So it can be used to save hardware error record into
    flash in hardware error exception or NMI handler, where other more
    complex persistent storage such as disk is not usable. After saving
    hardware error records via ERST in hardware error exception or NMI
    handler, the error records can be retrieved and logged into disk or
    network after a clean reboot.

    For more information about ERST, please refer to ACPI Specification
    version 4.0, section 17.4.

    This patch incorporate fixes from Jin Dongming.

    Signed-off-by: Huang Ying
    Signed-off-by: Andi Kleen
    CC: Jin Dongming
    Signed-off-by: Len Brown

    Huang Ying
     
  • Hardware Error Device (PNP0C33) is used to report some hardware errors
    notified via SCI, mainly the corrected errors. Some APEI Generic
    Hardware Error Source (GHES) may use SCI on hardware error device to
    notify hardware error to kernel.

    After receiving notification from ACPI core, it is forwarded to all
    listeners via a notifier chain. The listener such as APEI GHES should
    check corresponding error source for new events when notified.

    Signed-off-by: Huang Ying
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Huang Ying
     
  • Now, a dedicated HEST tabling parsing code is used for PCIE AER
    firmware_first setup. It is rebased on general HEST tabling parsing
    code of APEI. The firmware_first setup code is moved from PCI core to
    AER driver too, because it is only AER related.

    Signed-off-by: Huang Ying
    Signed-off-by: Andi Kleen
    Reviewed-by: Hidetoshi Seto
    Acked-by: Jesse Barnes
    Signed-off-by: Len Brown

    Huang Ying
     
  • HEST describes error sources in detail; communicating operational
    parameters (i.e. severity levels, masking bits, and threshold values)
    to OS as necessary. It also allows the platform to report error
    sources for which OS would typically not implement support (for
    example, chipset-specific error registers).

    HEST information may be needed by other subsystems. For example, HEST
    PCIE AER error source information describes whether a PCIE root port
    works in "firmware first" mode, this is needed by general PCIE AER
    error subsystem. So a public HEST tabling parsing interface is
    provided.

    Signed-off-by: Huang Ying
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Huang Ying
     

19 May, 2010

1 commit

  • Some ACPI IO accessing need to be done in atomic context. For example,
    APEI ERST operations may be used for permanent storage in hardware
    error handler. That is, it may be called in atomic contexts such as
    IRQ or NMI, etc. And, ERST/EINJ implement their operations via IO
    memory/port accessing. But the IO memory accessing method provided by
    ACPI (acpi_read/acpi_write) maps the IO memory during it is accessed,
    so it can not be used in atomic context. To solve the issue, the IO
    memory should be pre-mapped during EINJ/ERST initializing. A linked
    list is used to record which memory area has been mapped, when memory
    is accessed in hardware error handler, search the linked list for the
    mapped virtual address from the given physical address.

    Signed-off-by: Huang Ying
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Huang Ying
     

06 May, 2010

2 commits


20 Apr, 2010

4 commits

  • We have ported Rafael's major GPE changes
    (ACPI: Use GPE reference counting to support shared GPEs) into ACPICA code base.
    But the port and Rafael's original patch have some differences, so we made
    below patch to make linux GPE code consistent with ACPICA code base.

    Most changes are about comments and coding styles.
    Other noticeable changes are based on:

    Rafael: Reduce code duplication related to GPE lookup
    https://patchwork.kernel.org/patch/86237/

    Rafael: Always use the same lock for GPE locking
    https://patchwork.kernel.org/patch/90471/

    A new field gpe_count in struct acpi_gpe_block_info to record the number
    of individual GPEs in block.

    Rename acpi_ev_save_method_info to acpi_ev_match_gpe_method.

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

    Lin Ming
     
  • Version 20100331.

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

    Robert Moore
     
  • Optionally copy the entire DSDT to local memory (instead of
    simply mapping it.) There are some BIOSs that corrupt or replace
    the original DSDT, creating the need for this option. Default is
    FALSE, do not copy the DSDT.

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

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

    Lin Ming
     
  • Version 20100304.

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

    Bob Moore