25 Aug, 2010

1 commit

  • It is possible that the BIOS will not grant control of all _OSC
    features requested via acpi_pci_osc_control_set(), so it is
    recommended to negotiate the final set of _OSC features with the
    query flag set before calling _OSC to request control of these
    features.

    To implement it, rework acpi_pci_osc_control_set() so that the caller
    can specify the mask of _OSC control bits to negotiate and the mask
    of _OSC control bits that are absolutely necessary to it. Then,
    acpi_pci_osc_control_set() will run _OSC queries in a loop until
    the mask of _OSC control bits returned by the BIOS is equal to the
    mask passed to it. Also, before running the _OSC request
    acpi_pci_osc_control_set() will check if the caller's required
    control bits are present in the final mask.

    Using this mechanism we will be able to avoid situations in which the
    BIOS doesn't grant control of certain _OSC features, because they
    depend on some other _OSC features that have not been requested.

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

    Rafael J. Wysocki
     

25 Jul, 2010

1 commit

  • Commit 2a6b69765ad794389f2fc3e14a0afa1a995221c2
    (ACPI: Store NVS state even when entering suspend to RAM) caused the
    ACPI suspend code save the NVS area during suspend and restore it
    during resume unconditionally, although it is known that some systems
    need to use acpi_sleep=s4_nonvs for hibernation to work. To allow
    the affected systems to avoid saving and restoring the NVS area
    during suspend to RAM and resume, introduce kernel command line
    option acpi_sleep=nonvs and make acpi_sleep=s4_nonvs work as its
    alias temporarily (add acpi_sleep=s4_nonvs to the feature removal
    file).

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

    Signed-off-by: Rafael J. Wysocki
    Reported-and-tested-by: tomas m
    Signed-off-by: Len Brown

    Rafael J. Wysocki
     

29 May, 2010

1 commit

  • * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (27 commits)
    ACPI: Don't let acpi_pad needlessly mark TSC unstable
    drivers/acpi/sleep.h: Checkpatch cleanup
    ACPI: Minor cleanup eliminating redundant PMTIMER_TICKS to NS conversion
    ACPI: delete unused c-state promotion/demotion data strucutures
    ACPI: video: fix acpi_backlight=video
    ACPI: EC: Use kmemdup
    drivers/acpi: use kasprintf
    ACPI, APEI, EINJ injection parameters support
    Add x64 support to debugfs
    ACPI, APEI, Use ERST for persistent storage of MCE
    ACPI, APEI, Error Record Serialization Table (ERST) support
    ACPI, APEI, Generic Hardware Error Source memory error support
    ACPI, APEI, UEFI Common Platform Error Record (CPER) header
    Unified UUID/GUID definition
    ACPI Hardware Error Device (PNP0C33) support
    ACPI, APEI, PCIE AER, use general HEST table parsing in AER firmware_first setup
    ACPI, APEI, Document for APEI
    ACPI, APEI, EINJ support
    ACPI, APEI, HEST table parsing
    ACPI, APEI, APEI supporting infrastructure
    ...

    Linus Torvalds
     

28 May, 2010

1 commit

  • When the user passes the kernel parameter acpi_enforce_resources=lax,
    the ACPI resources are no longer protected, so a native driver can
    make use of them. In that case, we do not want the asus_atk0110 to be
    loaded. Unfortunately, this driver loads automatically due to its
    MODULE_DEVICE_TABLE, so the user ends up with two drivers loaded for
    the same device - this is bad.

    So I suggest that we prevent the asus_atk0110 driver from loading if
    acpi_enforce_resources=lax.

    Signed-off-by: Jean Delvare
    Acked-by: Luca Tettamanti
    Cc: Len Brown

    Jean Delvare
     

12 May, 2010

1 commit

  • The ACPI spec tells us that the firmware will reenable SCI_EN on resume.
    Reality disagrees in some cases. The ACPI spec tells us that the only way
    to set SCI_EN is via an SMM call.
    https://bugzilla.kernel.org/show_bug.cgi?id=13745 shows us that doing so
    may break machines. Tracing the ACPI calls made by Windows shows that it
    unconditionally sets SCI_EN on resume with a direct register write, and
    therefore the overwhelming probability is that everything is fine with
    this behaviour.

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

    Matthew Garrett
     

05 May, 2010

2 commits

  • In perverse acpi implementations the isa irqs are not identity mapped
    to the first 16 gsi. Furthermore at least the extended interrupt
    resource capability may return gsi's and not isa irqs. So since
    what we get from acpi is a gsi teach acpi_get_overrride_irq to
    operate on a gsi instead of an isa_irq.

    Signed-off-by: Eric W. Biederman
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Eric W. Biederman
     
  • There are a number of cases where the current code makes the assumption
    that isa irqs identity map to the first 16 acpi global system intereupts.
    In most instances that assumption is correct as that is the required
    behaviour in dual i8259 mode and the default behavior in ioapic mode.

    However there are some systems out there that take advantage of acpis
    interrupt remapping for the isa irqs to have a completely different
    mapping of isa_irq to gsi.

    Introduce acpi_isa_irq_to_gsi to perform this mapping explicitly in the
    code that needs it. Initially this will be just the current assumed
    identity mapping to ensure it's introduction does not cause regressions.

    Signed-off-by: Eric W. Biederman
    LKML-Reference:
    Signed-off-by: H. Peter Anvin

    Eric W. Biederman
     

07 Jan, 2010

1 commit


31 Dec, 2009

1 commit

  • Introduce kernel parameter acpi_sleep=sci_force_enable

    some laptop requires SCI_EN being set directly on resume,
    or else they hung somewhere in the resume code path.

    We already have a blacklist for these laptops but we still need
    this option, especially when debugging some suspend/resume problems,
    in case there are systems that need this workaround and are not yet
    in the blacklist.

    Signed-off-by: Zhang Rui
    Acked-by: Rafael J. Wysocki
    Signed-off-by: Len Brown

    Zhang Rui
     

17 Dec, 2009

4 commits


10 Dec, 2009

1 commit


19 Sep, 2009

3 commits


29 Aug, 2009

1 commit

  • linux/acpi.h is the top level header for interfacing
    with the ACPI sub-system, so acpi_disabled should be
    up there instead of down in asm/acpi.h -- particularly
    since asm/acpi.h doesn't exist for all architectures.

    Same story for acpi_table_parse(), which is a top-level
    API to Linux/ACPI.

    This is necessary for building some code that
    used to always depend on CONFIG_ACPI=y, but will soon
    also need to build with CONFIG_ACPI=n.

    Signed-off-by: Feng Tang
    Signed-off-by: Len Brown

    Feng Tang
     

24 Jun, 2009

1 commit


13 Jun, 2009

2 commits


28 Apr, 2009

1 commit

  • We want to use dev_to_node() later on, to be aware of the 'home node'
    of the GSI in question.

    [ Impact: cleanup, prepare the IRQ code to be more NUMA aware ]

    Signed-off-by: Yinghai Lu
    Acked-by: Len Brown
    Cc: Andrew Morton
    Cc: Suresh Siddha
    Cc: "Eric W. Biederman"
    Cc: Rusty Russell
    Cc: Len Brown
    Cc: Bjorn Helgaas
    Cc: Tony Luck
    Cc: linux-acpi@vger.kernel.org
    Cc: linux-ia64@vger.kernel.org
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

21 Apr, 2009

1 commit


05 Apr, 2009

1 commit


04 Apr, 2009

1 commit

  • All logical processors with APIC ID values of 255 and greater will have their
    APIC reported through Processor X2APIC structure (type-9 entry type) and all
    logical processors with APIC ID less than 255 will have their APIC reported
    through legacy Processor Local APIC (type-0 entry type) only. This is the
    same case even for NMI structure reporting.

    The Processor X2APIC Affinity structure provides the association between the
    X2APIC ID of a logical processor and the proximity domain to which the logical
    processor belongs.

    For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device()
    objects in the ACPI namespace.

    Signed-off-by: Suresh Siddha
    Signed-off-by: Len Brown

    Suresh Siddha
     

02 Apr, 2009

1 commit

  • * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (88 commits)
    PCI: fix HT MSI mapping fix
    PCI: don't enable too much HT MSI mapping
    x86/PCI: make pci=lastbus=255 work when acpi is on
    PCI: save and restore PCIe 2.0 registers
    PCI: update fakephp for bus_id removal
    PCI: fix kernel oops on bridge removal
    PCI: fix conflict between SR-IOV and config space sizing
    powerpc/PCI: include pci.h in powerpc MSI implementation
    PCI Hotplug: schedule fakephp for feature removal
    PCI Hotplug: rename legacy_fakephp to fakephp
    PCI Hotplug: restore fakephp interface with complete reimplementation
    PCI: Introduce /sys/bus/pci/devices/.../rescan
    PCI: Introduce /sys/bus/pci/devices/.../remove
    PCI: Introduce /sys/bus/pci/rescan
    PCI: Introduce pci_rescan_bus()
    PCI: do not enable bridges more than once
    PCI: do not initialize bridges more than once
    PCI: always scan child buses
    PCI: pci_scan_slot() returns newly found devices
    PCI: don't scan existing devices
    ...

    Fix trivial append-only conflict in Documentation/feature-removal-schedule.txt

    Linus Torvalds
     

20 Mar, 2009

1 commit

  • - Rename pci_osc_control_set() to acpi_pci_osc_control_set() according
    to the other API names in drivers/acpi/pci_root.c.

    - Move _OSC related definitions to include/linux/acpi.h because _OSC
    related API is implemented in drivers/acpi/pci_root.c now.

    Signed-off-by: Kenji Kaneshige
    Reviewed-by: Andrew Patterson
    Tested-by: Andrew Patterson
    Signed-off-by: Jesse Barnes

    Kenji Kaneshige
     

16 Feb, 2009

1 commit

  • Impact: fix build error

    to fix:

    tip/arch/ia64/kernel/acpi.c:203: error: conflicting types for '__acpi_unmap_table'
    tip/include/linux/acpi.h:82: error: previous declaration of '__acpi_unmap_table' was here
    tip/arch/ia64/kernel/acpi.c:203: error: conflicting types for '__acpi_unmap_table'
    tip/include/linux/acpi.h:82: error: previous declaration of '__acpi_unmap_table' was here

    Signed-off-by: Yinghai Lu
    Cc: Jeremy Fitzhardinge
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

09 Feb, 2009

1 commit

  • to prevent wrongly overwriting fixmap that still want to use.

    ACPI used to rely on low mappings being all linearly mapped and
    grew a habit: it never really unmapped certain kinds of tables
    after use.

    This can cause problems - for example the hypothetical case
    when some spurious access still references it.

    v2: remove prev_map and prev_size in __apci_map_table
    v3: let acpi_os_unmap_memory() call early_iounmap too, so remove extral calling to
    early_acpi_os_unmap_memory
    v4: fix typo in one acpi_get_table_with_size calling

    Signed-off-by: Yinghai Lu
    Acked-by: Len Brown
    Signed-off-by: Ingo Molnar

    Yinghai Lu
     

09 Jan, 2009

1 commit


31 Dec, 2008

1 commit


19 Dec, 2008

1 commit


12 Nov, 2008

1 commit


08 Nov, 2008

1 commit

  • If an ACPI graphics device supports backlight brightness functions (cmp. with
    latest ACPI spec Appendix B), let the ACPI video driver control backlight and
    switch backlight control off in vendor specific ACPI drivers (asus_acpi,
    thinkpad_acpi, eeepc, fujitsu_laptop, msi_laptop, sony_laptop, acer-wmi).

    Currently it is possible to load above drivers and let both poke on the
    brightness HW registers, the video and vendor specific ACPI drivers -> bad.

    This patch provides the basic support to check for BIOS capabilities before
    driver loading time. Driver specific modifications are in separate follow up
    patches.

    "acpi_backlight=vendor"
    Prever vendor driver over ACPI driver for backlight.
    "acpi_backlight=video" (default)
    Prever ACPI driver over vendor driver for backlight.

    Signed-off-by: Thomas Renninger
    Acked-by: Zhang Rui
    Signed-off-by: Andi Kleen
    Signed-off-by: Len Brown

    Thomas Renninger
     

07 Nov, 2008

1 commit

  • Remove CONFIG_ACPI_EC. It was always set the same as CONFIG_ACPI,
    and it had no menu label, so there was no way to set it to anything
    other than "y".

    Per section 6.5.4 of the ACPI 3.0b specification,

    OSPM must make Embedded Controller operation regions, accessed
    via the Embedded Controllers described in ECDT, available before
    executing any control method.

    The ECDT table is optional, but if it is present, the above text
    means that the EC it describes is a required part of the ACPI
    subsystem, so CONFIG_ACPI_EC=n wouldn't make sense.

    Signed-off-by: Bjorn Helgaas
    Acked-by: Alexey Starikovskiy
    Signed-off-by: Len Brown

    Bjorn Helgaas
     

11 Oct, 2008

1 commit

  • This was a workaround for 32bit numa SRAT processing, and we removed those
    workarounds, making 32 bit more like 64 bit. HAVE_ARCH_PARSE_SRAT is no
    longer defined anywhere.

    Signed-off-by: Yinghai Lu
    Signed-off-by: Andrew Morton
    Signed-off-by: Len Brown

    Yinghai Lu
     

25 Jul, 2008

1 commit

  • ACPI defines a hardware signature. BIOS calculates the signature according to
    hardware configure and if hardware changes while hibernated, the signature
    will change. In that case, S4 resume should fail.

    Still, there may be systems on which this mechanism does not work correctly,
    so it is better to provide a workaround for them. For this reason, add a new
    switch to the acpi_sleep= command line argument allowing one to disable
    hardware signature checking.

    [shaohua.li@intel.com: build fix]
    Signed-off-by: Shaohua Li
    Signed-off-by: Rafael J. Wysocki
    Cc: Andi Kleen
    Cc: Len Brown
    Acked-by: Pavel Machek
    Cc:
    Cc: Shaohua Li
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Shaohua Li
     

17 Jul, 2008

1 commit

  • * 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: (72 commits)
    Revert "x86/PCI: ACPI based PCI gap calculation"
    PCI: remove unnecessary volatile in PCIe hotplug struct controller
    x86/PCI: ACPI based PCI gap calculation
    PCI: include linux/pm_wakeup.h for device_set_wakeup_capable
    PCI PM: Fix pci_prepare_to_sleep
    x86/PCI: Fix PCI config space for domains > 0
    Fix acpi_pm_device_sleep_wake() by providing a stub for CONFIG_PM_SLEEP=n
    PCI: Simplify PCI device PM code
    PCI PM: Introduce pci_prepare_to_sleep and pci_back_from_sleep
    PCI ACPI: Rework PCI handling of wake-up
    ACPI: Introduce new device wakeup flag 'prepared'
    ACPI: Introduce acpi_device_sleep_wake function
    PCI: rework pci_set_power_state function to call platform first
    PCI: Introduce platform_pci_power_manageable function
    ACPI: Introduce acpi_bus_power_manageable function
    PCI: make pci_name use dev_name
    PCI: handle pci_name() being const
    PCI: add stub for pci_set_consistent_dma_mask()
    PCI: remove unused arch pcibios_update_resource() functions
    PCI: fix pci_setup_device()'s sprinting into a const buffer
    ...

    Fixed up conflicts in various files (arch/x86/kernel/setup_64.c,
    arch/x86/pci/irq.c, arch/x86/pci/pci.h, drivers/acpi/sleep/main.c,
    drivers/pci/pci.c, drivers/pci/pci.h, include/acpi/acpi_bus.h) from x86
    and ACPI updates manually.

    Linus Torvalds
     

08 Jul, 2008

1 commit


13 Jun, 2008

1 commit

  • ACPI PM: Add possibility to change suspend sequence

    There are some systems out there that don't work correctly with
    our current suspend/hibernation code ordering. Provide a workaround
    for these systems allowing them to pass 'acpi_sleep=old_ordering' in
    the kernel command line so that it will use the pre-ACPI 2.0 ("old")
    suspend code ordering.

    Unfortunately, this requires us to add a platform hook to the
    resuming of devices for recovering the platform in case one of the
    device drivers' .suspend() routines returns error code. Namely,
    ACPI 1.0 specifies that _PTS should be called before suspending
    devices, but _WAK still should be called before resuming them in
    order to undo the changes made by _PTS. However, if there is an
    error during suspending devices, they are automatically resumed
    without returning control to the PM core, so the _WAK has to be
    called from within device_resume() in that cases.

    The patch also reorders and refactors the ACPI suspend/hibernation
    code to avoid duplication as far as reasonably possible.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Signed-off-by: Jesse Barnes

    Rafael J. Wysocki