1. 17 1月, 2012 1 次提交
    • H
      ACPI, Record ACPI NVS regions · b54ac6d2
      Huang Ying 提交于
      Some firmware will access memory in ACPI NVS region via APEI.  That
      is, instructions in APEI ERST/EINJ table will read/write ACPI NVS
      region.  The original resource conflict checking in APEI code will
      check memory/ioport accessed by APEI via general resource management
      mechanism.  But ACPI NVS region is marked as busy already, so that the
      false resource conflict will prevent APEI ERST/EINJ to work.
      
      To fix this, this patch record ACPI NVS regions, so that we can avoid
      request resources for memory region inside it.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b54ac6d2
  2. 03 8月, 2011 1 次提交
  3. 14 7月, 2011 1 次提交
    • H
      ACPI, APEI, Add APEI bit support in generic _OSC call · eccddd32
      Huang Ying 提交于
      In APEI firmware first mode, hardware error is reported by hardware to
      firmware firstly, then firmware reports the error to Linux in a GHES
      error record via POLL/SCI/IRQ/NMI etc.
      
      This may result in some issues if OS has no full APEI support.  So
      some firmware implementation will work in a back-compatible mode by
      default.  Where firmware will only notify OS in old-fashion, without
      GHES record.  For example, for a fatal hardware error, only NMI is
      signaled, no GHES record.
      
      To gain full APEI power on these machines, APEI bit in generic _OSC
      call can be specified to tell firmware that Linux has full APEI
      support.  This patch adds the APEI bit support in generic _OSC call.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Reviewed-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      eccddd32
  4. 01 4月, 2011 1 次提交
  5. 21 1月, 2011 1 次提交
    • R
      ACPI: Introduce acpi_os_ioremap() · 2d6d9fd3
      Rafael J. Wysocki 提交于
      Commit ca9b600b ("ACPI / PM: Make suspend_nvs_save() use
      acpi_os_map_memory()") attempted to prevent the code in osl.c and nvs.c
      from using different ioremap() variants by making the latter use
      acpi_os_map_memory() for mapping the NVS pages.  However, that also
      requires acpi_os_unmap_memory() to be used for unmapping them, which
      causes synchronize_rcu() to be executed many times in a row
      unnecessarily and introduces substantial delays during resume on some
      systems.
      
      Instead of using acpi_os_map_memory() for mapping the NVS pages in nvs.c
      introduce acpi_os_ioremap() calling ioremap_cache() and make the code in
      both osl.c and nvs.c use it.
      Reported-by: NJeff Chua <jeff.chua.linux@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2d6d9fd3
  6. 13 1月, 2011 1 次提交
  7. 07 1月, 2011 1 次提交
  8. 11 12月, 2010 1 次提交
    • L
      acpi: fix _OSI string setup regression · d90aa92c
      Lin Ming 提交于
      commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
      introduced a regression that _OSI string setup fails.
      
      There are 2 paths to setup _OSI string.
      
      DMI:
      acpi_dmi_osi_linux -> set_osi_linux -> acpi_osi_setup -> copy _OSI
      string to osi_setup_string
      
      Boot command line:
      acpi_osi_setup -> copy _OSI string to osi_setup_string
      
      Later, acpi_osi_setup_late will be called to handle osi_setup_string.
      If _OSI string is "Linux" or "!Linux", then the call path is,
      
      acpi_osi_setup_late -> acpi_cmdline_osi_linux -> set_osi_linux ->
      acpi_osi_setup -> copy _OSI string to osi_setup_string
      
      This actually never installs _OSI string(acpi_install_interface not
      called), but just copy the _OSI string to osi_setup_string.
      
      This patch fixes the regression.
      Reported-and-tested-by: NLukas Hejtmanek <xhejtman@ics.muni.cz>
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d90aa92c
  9. 25 10月, 2010 1 次提交
  10. 20 10月, 2010 1 次提交
  11. 25 8月, 2010 1 次提交
    • R
      ACPI/PCI: Negotiate _OSC control bits before requesting them · 75fb60f2
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      75fb60f2
  12. 25 7月, 2010 1 次提交
  13. 28 5月, 2010 1 次提交
    • J
      hwmon: (asus_atk0110) Don't load if ACPI resources aren't enforced · 70dd6bea
      Jean Delvare 提交于
      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: NJean Delvare <khali@linux-fr.org>
      Acked-by: NLuca Tettamanti <kronos.it@gmail.com>
      Cc: Len Brown <lenb@kernel.org>
      70dd6bea
  14. 12 5月, 2010 1 次提交
  15. 05 5月, 2010 2 次提交
    • E
      x86, acpi/irq: Teach acpi_get_override_irq to take a gsi not an isa_irq · 9a0a91bb
      Eric W. Biederman 提交于
      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: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <1269936436-7039-2-git-send-email-ebiederm@xmission.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      9a0a91bb
    • E
      x86, acpi/irq: Introduce apci_isa_irq_to_gsi · 2c2df841
      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: NEric W. Biederman <ebiederm@xmission.com>
      LKML-Reference: <1269936436-7039-1-git-send-email-ebiederm@xmission.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      2c2df841
  16. 07 1月, 2010 1 次提交
  17. 31 12月, 2009 1 次提交
  18. 17 12月, 2009 3 次提交
  19. 10 12月, 2009 1 次提交
  20. 19 9月, 2009 2 次提交
  21. 29 8月, 2009 1 次提交
    • F
      ACPI: Handle CONFIG_ACPI=n better from linux/acpi.h · e55a5999
      Feng Tang 提交于
      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: NFeng Tang <feng.tang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e55a5999
  22. 13 6月, 2009 2 次提交
  23. 28 4月, 2009 1 次提交
    • Y
      irq: change ACPI GSI APIs to also take a device argument · a2f809b0
      Yinghai Lu 提交于
      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: NYinghai Lu <yinghai@kernel.org>
      Acked-by: NLen Brown <lenb@kernel.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Suresh Siddha <suresh.b.siddha@intel.com>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: linux-acpi@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      LKML-Reference: <49F65560.20904@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a2f809b0
  24. 21 4月, 2009 1 次提交
  25. 04 4月, 2009 1 次提交
    • S
      x86, ACPI: add support for x2apic ACPI extensions · 7237d3de
      Suresh Siddha 提交于
      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: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      7237d3de
  26. 20 3月, 2009 1 次提交
  27. 16 2月, 2009 1 次提交
    • Y
      [IA64] fix __apci_unmap_table · 970ec1a8
      Yinghai Lu 提交于
      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: NYinghai Lu <yinghai@kernel.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      970ec1a8
  28. 09 2月, 2009 1 次提交
    • Y
      acpi/x86: introduce __apci_map_table, v4 · 7d97277b
      Yinghai Lu 提交于
      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: NYinghai Lu <yhlu.kernel@gmail.com>
      Acked-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7d97277b
  29. 31 12月, 2008 1 次提交
  30. 19 12月, 2008 1 次提交
  31. 08 11月, 2008 1 次提交
    • T
      ACPI video: if no ACPI backlight support, use vendor drivers · c3d6de69
      Thomas Renninger 提交于
      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: NThomas Renninger <trenn@suse.de>
      Acked-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      c3d6de69
  32. 07 11月, 2008 1 次提交
    • B
      ACPI: remove CONFIG_ACPI_EC · 8950d89a
      Bjorn Helgaas 提交于
      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: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Acked-by: NAlexey Starikovskiy <astarikovskiy@suse.de>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      8950d89a
  33. 11 10月, 2008 1 次提交
  34. 25 7月, 2008 1 次提交
  35. 08 7月, 2008 1 次提交