1. 21 1月, 2012 2 次提交
    • M
      ACPI, APEI: Add RAM mapping support to ACPI · ba242d5b
      Myron Stowe 提交于
      This patch adds support for RAM to ACPI's mapping capabilities in order
      to support APEI error injection (EINJ) actions.
      
      This patch re-factors similar functionality introduced in commit
      76da3fb3, bringing it into osl.c in preparation for removing
      ./drivers/acpi/atomicio.[ch].
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      ba242d5b
    • M
      ACPI, APEI: Add 64-bit read/write support for APEI on i386 · e615bf5b
      Myron Stowe 提交于
      Base ACPI (CA) currently does not support atomic 64-bit reads and writes
      (acpi_read() and acpi_write() split 64-bit loads/stores into two
      32-bit transfers) yet APEI expects 64-bit transfer capability, even
      when running on 32-bit systems.
      
      This patch implements 64-bit read and write routines for APEI usage.
      
      This patch re-factors similar functionality introduced in commit
      04c25997, bringing it into the ACPI subsystem in preparation for
      removing ./drivers/acpi/atomicio.[ch].  In the implementation I have
      replicated acpi_os_read_memory() and acpi_os_write_memory(), creating
      64-bit versions for APEI to utilize, as opposed to something more
      elegant.  My thinking is that we should attempt to see if we can get
      ACPI's CA/OSL changed so that the existing acpi_read() and acpi_write()
      interfaces are natively 64-bit capable and then subsequently remove the
      replication.
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      e615bf5b
  2. 17 1月, 2012 3 次提交
  3. 15 10月, 2011 1 次提交
    • P
      PCI hotplug: acpiphp: Prevent deadlock on PCI-to-PCI bridge remove · 6af8bef1
      Prarit Bhargava 提交于
      I originally submitted a patch to workaround this by pushing all Ejection
      Requests and Device Checks onto the kacpi_hotplug queue.
      
      http://marc.info/?l=linux-acpi&m=131678270930105&w=2
      
      The patch is still insufficient in that Bus Checks also need to be added.
      
      Rather than add all events, including non-PCI-hotplug events, to the
      hotplug queue, mjg suggested that a better approach would be to modify
      the acpiphp driver so only acpiphp events would be added to the
      kacpi_hotplug queue.
      
      It's a longer patch, but at least we maintain the benefit of having separate
      queues in ACPI.  This, of course, is still only a workaround the problem.
      As Bjorn and mjg pointed out, we have to refactor a lot of this code to do
      the right thing but at this point it is a better to have this code working.
      
      The acpi core places all events on the kacpi_notify queue.  When the acpiphp
      driver is loaded and a PCI card with a PCI-to-PCI bridge is removed the
      following call sequence occurs:
      
      cleanup_p2p_bridge()
      	    -> cleanup_bridge()
      		    -> acpi_remove_notify_handler()
      			    -> acpi_os_wait_events_complete()
      				    -> flush_workqueue(kacpi_notify_wq)
      
      which is the queue we are currently executing on and the process will hang.
      
      Move all hotplug acpiphp events onto the kacpi_hotplug workqueue.  In
      handle_hotplug_event_bridge() and handle_hotplug_event_func() we can simply
      push the rest of the work onto the kacpi_hotplug queue and then avoid the
      deadlock.
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: mjg@redhat.com
      Cc: bhelgaas@google.com
      Cc: linux-acpi@vger.kernel.org
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      6af8bef1
  4. 03 8月, 2011 1 次提交
  5. 02 8月, 2011 1 次提交
  6. 17 7月, 2011 1 次提交
  7. 14 7月, 2011 1 次提交
  8. 25 3月, 2011 1 次提交
  9. 25 2月, 2011 7 次提交
  10. 09 2月, 2011 1 次提交
    • R
      ACPI: Fix acpi_os_read_memory() and acpi_os_write_memory() (v2) · 884b821f
      Rafael J. Wysocki 提交于
      The functions acpi_os_read_memory() and acpi_os_write_memory() do
      two wrong things.  First, they shouldn't call rcu_read_unlock()
      before the looked up address is actually used for I/O, because in
      that case the iomap it belongs to may be removed before the I/O
      is done.  Second, if they have to create a new mapping, they should
      check the returned virtual address and tell the caller that the
      operation failed if it is NULL (in fact, I think they even should not
      attempt to map an address that's not present in one of the existing
      ACPI iomaps, because that may cause problems to happen when they are
      called from nonpreemptible context and their callers ought to know
      what they are doing and map the requisite memory regions beforehand).
      
      Make these functions call rcu_read_unlock() when the I/O is complete
      (or if it's necessary to map the given address "on the fly") and
      return an error code if the requested physical address is not present
      in the existing ACPI iomaps and cannot be mapped.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      884b821f
  11. 01 2月, 2011 1 次提交
    • T
      acpi: kacpi*_wq don't need WQ_MEM_RECLAIM · 44d2588e
      Tejun Heo 提交于
      ACPI workqueues aren't used during memory reclaming.  Use
      alloc_workqueue() to create workqueues w/o rescuers.
      
      If the purpose of the separation between kacpid_wq and kacpi_notify_wq
      was to give notifications better response time, kacpi_notify_wq can be
      dropped and kacpi_wq can be created with higher @max_active.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Len Brown <lenb@kernel.org>
      Cc: linux-acpi@vger.kernel.org
      44d2588e
  12. 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
  13. 13 1月, 2011 1 次提交
  14. 07 1月, 2011 1 次提交
    • L
      ACPI: Use ioremap_cache() · 6d5bbf00
      Len Brown 提交于
      Although the temporary boot-time ACPI table mappings
      were set up with CPU caching enabled, the permanent table
      mappings and AML run-time region memory accesses were
      set up with ioremap(), which on x86 is a synonym for
      ioremap_nocache().
      
      Changing this to ioremap_cache() improves performance as
      seen when accessing the tables via acpidump,
      or /sys/firmware/acpi/tables.  It should also improve
      AML run-time performance.
      
      No change on ia64.
      Reported-by: NJack Steiner <steiner@sgi.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      6d5bbf00
  15. 11 12月, 2010 3 次提交
    • Z
      ACPI: fix a section mismatch · 32d47eef
      Zhang Rui 提交于
      WARNING: drivers/acpi/acpi.o(.text+0xeda): Section mismatch in reference from the function acpi_os_initialize1() to the function .init.text:set_osi_linux()
      
      The function acpi_os_initialize1() references
      the function __init set_osi_linux().
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      32d47eef
    • L
      ACPI: fix allowing to add/remove multiple _OSI strings · 12d32064
      Lin Ming 提交于
      commit b0ed7a91(ACPICA/ACPI: Add new host interfaces for _OSI suppor)
      introduced another regression that only one _OSI string can be added or
      removed.
      
      Now multiple _OSI strings can be added or removed, for example
      
      acpi_osi=Linux acpi_osi=FreeBSD acpi_osi="!Windows 2006"
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      12d32064
    • 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
  16. 25 10月, 2010 6 次提交
    • M
      ACPI: Page based coalescing of I/O remappings optimization · 4a3cba5e
      Myron Stowe 提交于
      This patch optimizes ACPI MMIO remappings by keeping track of the
      remappings on a PAGE_SIZE granularity.
      
      When an ioremap() occurs, the underlying infrastructure works on a 'page'
      based granularity.  As such, an ioremap() request for 1 byte for example,
      will end up mapping in an entire (PAGE_SIZE) page.  Huang Ying took
      advantage of this in commit 15651291 by
      checking if subsequent ioremap() requests reside within any of the list's
      existing remappings still in place, and if so, incrementing a reference
      count on the existing mapping as opposed to performing another ioremap().
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      4a3cba5e
    • M
      ACPI: Convert simple locking to RCU based locking · 78cdb3ed
      Myron Stowe 提交于
      Convert the simple locking introduced earlier for the ACPI MMIO
      remappings list to an RCU based locking scheme.
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      78cdb3ed
    • M
      ACPI: Pre-map 'system event' related register blocks · d362edaf
      Myron Stowe 提交于
      During ACPI initialization, pre-map fixed hardware registers that are
      accessed during ACPI's 'system event' related IRQ handing.
      
      ACPI's 'system event' handing accesses specific fixed hardware
      registers; namely PM1a event, PM1b event, GPE0, and GPE1 register
      blocks which are declared within the FADT.  If these registers are
      backed by MMIO, as opposed to I/O port space, accessing them within
      interrupt context will cause a panic as acpi_os_read_memory()
      depends on ioremap() in such cases - BZ 18012.
      
      By utilizing the functionality provided in the previous two patches -
      ACPI: Maintain a list of ACPI memory mapped I/O remappings, and, ACPI:
      Add interfaces for ioremapping/iounmapping ACPI registers - accesses
      to ACPI MMIO areas will now be safe from within interrupt contexts (IRQ
      and/or NMI) provided the area was pre-mapped.  This solves BZ 18012.
      
      ACPI "System Event" reference(s):
        ACPI Specification, Revision 4.0, Section 3 "ACPI Overview",
        3.8 "System Events", 5.6 "ACPI Event Programming Model".
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=18012
      
      Reported-by: <bjorn.helgaas@hp.com>
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d362edaf
    • M
      ACPI: Add interfaces for ioremapping/iounmapping ACPI registers · 29718521
      Myron Stowe 提交于
      Add remapping and unmapping interfaces for ACPI registers that are
      backed by memory mapped I/O (MMIO).  These interfaces, along with
      the MMIO remapping list, enable accesses of such registers from within
      interrupt context.
      
      ACPI Generic Address Structure (GAS) reference (ACPI's fixed/generic
      hardware registers use the GAS format):
        ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
        Structure".
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      29718521
    • M
      ACPI: Maintain a list of ACPI memory mapped I/O remappings · 620242ae
      Myron Stowe 提交于
      For memory mapped I/O (MMIO) remappings, add a list to maintain the
      remappings and augment the corresponding mapping and unmapping interface
      routines (acpi_os_map_memory() and acpi_os_unmap_memory()) to
      dynamically add to, and delete from, the list.
      
      The current ACPI I/O accessing methods - acpi_read() and acpi_write() -
      end up calling ioremap() when accessing MMIO.  This prevents use of these
      methods within interrupt context (IRQ and/or NMI), since ioremap() may
      block to allocate memory.  Maintaining a list of MMIO remappings enables
      accesses to such areas from within interrupt context provided they have
      been pre-mapped.
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      620242ae
    • M
      ACPI: Fix ioremap size for MMIO reads and writes · b3ba1efe
      Myron Stowe 提交于
      The size used for I/O remapping MMIO read and write accesses has not
      accounted for the basis of ACPI's Generic Address Structure (GAS)
      'Register Bit Width' field which is bits, not bytes.  This patch
      adjusts the ioremap() 'size' argument accordingly.
      
      ACPI "Generic Register" reference:
        ACPI Specification, Revision 4.0, Section 5.2.3.1, "Generic Address
        Structure".
      Signed-off-by: NMyron Stowe <myron.stowe@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      b3ba1efe
  17. 20 10月, 2010 1 次提交
  18. 16 10月, 2010 1 次提交
    • L
      ACPI: add FW_BUG to OSI(Linux) message · 3af283e1
      Len Brown 提交于
      Linux-2.6.22 initiated a dmesg complaint when it saw BIOS that invoked
      OSI(Linux).  Linux-2.6.23 continued that complaint and started our
      policy of ignoring the bogus BIOS request.
      
      Past-time for Linux to label that complaint with FW_BUG.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      3af283e1
  19. 01 10月, 2010 3 次提交
  20. 15 8月, 2010 1 次提交
  21. 13 7月, 2010 1 次提交
    • R
      ACPI / ACPICA: Do not execute _PRW methods during initialization · 9874647b
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      9874647b
  22. 29 6月, 2010 1 次提交
    • T
      acpi: use queue_work_on() instead of binding workqueue worker to cpu0 · 8fec62b2
      Tejun Heo 提交于
      ACPI works need to be executed on cpu0 and acpi/osl.c achieves this by
      creating singlethread workqueue and then binding it to cpu0 from a
      work which is quite unorthodox.  Make it create regular workqueues and
      use queue_work_on() instead.  This is in preparation of concurrency
      managed workqueue and the extra workers won't be a problem after it's
      implemented.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      8fec62b2