1. 20 5月, 2010 3 次提交
  2. 19 5月, 2010 1 次提交
    • H
      ACPI, IO memory pre-mapping and atomic accessing · 15651291
      Huang Ying 提交于
      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: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      15651291
  3. 15 3月, 2010 2 次提交
  4. 22 12月, 2009 1 次提交
    • A
      ACPI: processor: call _PDC early · 78f16996
      Alex Chiang 提交于
      We discovered that at least one machine (HP Envy), methods in the DSDT
      attempt to call external methods defined in a dynamically loaded SSDT.
      
      Unfortunately, the DSDT methods we are trying to call are part of the
      EC initialization, which happens very early, and the the dynamic SSDT
      is only loaded when a processor _PDC method runs much later.
      
      This results in namespace lookup errors for the (as of yet) undefined
      methods.
      
      Since Windows doesn't have any issues with this machine, we take it
      as a hint that they must be evaluating _PDC much earlier than we are.
      
      Thus, the proper thing for Linux to do should be to match the Windows
      implementation more closely.
      
      Provide a mechanism to call _PDC before we enable the EC. Doing so loads
      the dynamic tables, and allows the EC to be enabled correctly.
      
      The ACPI processor driver will still evaluate _PDC in its .add() method
      to cover the hotplug case.
      
      Resolves: http://bugzilla.kernel.org/show_bug.cgi?id=14824
      
      Cc: ming.m.lin@intel.com
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      78f16996
  5. 05 11月, 2009 1 次提交
    • M
      PCI: PCIe AER: honor ACPI HEST FIRMWARE FIRST mode · 05843961
      Matt Domsch 提交于
      Feedback from Hidetoshi Seto and Kenji Kaneshige incorporated.  This
      correctly handles PCI-X bridges, PCIe root ports and endpoints, and
      prints debug messages when invalid/reserved types are found in the
      HEST.  PCI devices not in domain/segment 0 are not represented in
      HEST, thus will be ignored.
      
      Today, the PCIe Advanced Error Reporting (AER) driver attaches itself
      to every PCIe root port for which BIOS reports it should, via ACPI
      _OSC.
      
      However, _OSC alone is insufficient for newer BIOSes.  Part of ACPI
      4.0 is the new APEI (ACPI Platform Error Interfaces) which is a way
      for OS and BIOS to handshake over which errors for which components
      each will handle.  One table in ACPI 4.0 is the Hardware Error Source
      Table (HEST), where BIOS can define that errors for certain PCIe
      devices (or all devices), should be handled by BIOS ("Firmware First
      mode"), rather than be handled by the OS.
      
      Dell PowerEdge 11G server BIOS defines Firmware First mode in HEST, so
      that it may manage such errors, log them to the System Event Log, and
      possibly take other actions.  The aer driver should honor this, and
      not attach itself to devices noted as such.
      
      Furthermore, Kenji Kaneshige reminded us to disallow changing the AER
      registers when respecting Firmware First mode.  Platform firmware is
      expected to manage these, and if changes to them are allowed, it could
      break that firmware's behavior.
      
      The HEST parsing code may be replaced in the future by a more
      feature-rich implementation.  This patch provides the minimum needed
      to prevent breakage until that implementation is available.
      Reviewed-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      05843961
  6. 19 9月, 2009 1 次提交
    • D
      hwmon driver for ACPI 4.0 power meters · de584afa
      Darrick J. Wong 提交于
      This driver exposes ACPI 4.0 compliant power meters as hardware monitoring
      devices.  This second revision of the driver also exports the ACPI string
      info as sysfs attributes, a list of the devices that the meter measures,
      and will send ACPI notifications over the ACPI netlink socket.  This
      latest revision only enables the power capping controls if it can be
      confirmed that the power cap can be enforced by the hardware and explains
      how the notification interfaces work.
      
      [akpm@linux-foundation.org: remove default-y]
      [akpm@linux-foundation.org: build fix]
      Signed-off-by: NDarrick J. Wong <djwong@us.ibm.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      de584afa
  7. 01 8月, 2009 1 次提交
    • S
      ACPI: create Processor Aggregator Device driver · 8e0af514
      Shaohua Li 提交于
      ACPI 4.0 created the logical "processor aggregator device" as
      a mechinism for platforms to ask the OS to force otherwise busy
      processors to enter (power saving) idle.
      
      The intent is to lower power consumption to ride-out
      transient electrical and thermal emergencies,
      rather than powering off the server.
      
      On platforms that can save more power/performance via P-states,
      the platform will first exhaust P-states before forcing idle.
      However, the relative benefit of P-states vs. idle states
      is platform dependent, and thus this driver need not know
      or care about it.
      
      This driver does not use the kernel's CPU hot-plug mechanism
      because after the transient emergency is over, the system must
      be returned to its normal state, and hotplug would permanently
      break both cpusets and binding.
      
      So to force idle, the driver creates a power saving thread.
      The scheduler will migrate the thread to the preferred CPU.
      The thread has max priority and has SCHED_RR policy,
      so it can occupy one CPU.  To save power, the thread will
      invoke the deep C-state entry instructions.
      
      To avoid starvation, the thread will sleep 5% of the time
      time for every second (current RT scheduler has threshold
      to avoid starvation, but if other CPUs are idle,
      the CPU can borrow CPU timer from other,
      which makes the mechanism not work here)
      
      Vaidyanathan Srinivasan has proposed scheduler enhancements
      to allow injecting idle time into the system.  This driver doesn't
      depend on those enhancements, but could cut over to them
      when they are available.
      
      Peter Z. does not favor upstreaming this driver until
      the those scheduler enhancements are in place.  However,
      we favor upstreaming this driver now because it is useful
      now, and can be enhanced over time.
      Signed-off-by: NShaohua Li <shaohua.li@intel.com>
      NACKed-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      8e0af514
  8. 05 4月, 2009 1 次提交
    • A
      ACPI: battery: asynchronous init · 0f66af53
      Arjan van de Ven 提交于
      The battery driver tends to take quite some time to initialize
      (100ms-300ms is quite typical).
      This patch initializes the batter driver asynchronously, so that other
      things in the kernel can initialize in parallel to this 300 msec.
      
      As part of this, the battery driver had to move to the back
      of the ACPI init order (hence the Makefile change).
      Without this move, the next ACPI driver would just block
      on the ACPI/devicee layer semaphores until the battery driver was
      done anyway, not gaining any boot time.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      0f66af53
  9. 03 4月, 2009 2 次提交
  10. 28 3月, 2009 1 次提交
  11. 22 2月, 2009 1 次提交
    • B
      ACPI: remove CONFIG_ACPI_SYSTEM · ba193d64
      Bjorn Helgaas 提交于
      Remove CONFIG_ACPI_SYSTEM.  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".
      
      Some things under CONFIG_ACPI_SYSTEM (acpi_irq_handled, acpi_os_gpe_count(),
      event_is_open, register_acpi_notifier(), etc.) are used unconditionally
      by the CA, the OSPM, and drivers, so we depend on them always being
      present.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      ba193d64
  12. 17 1月, 2009 1 次提交
  13. 09 1月, 2009 1 次提交
  14. 19 12月, 2008 1 次提交
  15. 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
  16. 07 11月, 2008 2 次提交
    • 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
    • B
      ACPI: remove CONFIG_ACPI_POWER · fefe5ab3
      Bjorn Helgaas 提交于
      Remove CONFIG_ACPI_POWER.  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".
      
      The interfaces under CONFIG_ACPI_POWER (acpi_device_sleep_wake(),
      acpi_power_transition(), etc) are called unconditionally from the
      ACPI core, so we already depend on it always being present.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      fefe5ab3
  17. 23 10月, 2008 1 次提交
    • Z
      ACPI: hack around sysfs warning with link order · 5eaff722
      Zhao Yakui 提交于
          There exists the following warning message will appear after the
      following commit is merged.
         >commit f2e969acd6d5981e6b1272810002558650d0736e
         >Author: Zhao Yakui <yakui.zhao@intel.com>
         >Date:   Mon Aug 11 14:57:50 2008 +0800
          >ACPI: Add "acpi.power_nocheck=1" to disable power state check in
      power transition:
      
         >WARNING: at linux-2.6/fs/sysfs/dir.c:463  sysfs_add_one+0x33/0x39()
         >sysfs: duplicate filename 'acpi' can not be created
         >kobject_add_internal failed for acpi with -EEXIST, don't try to register
                  things with the same name in the same directory
      
         In the above commit the "acpi.power_nocheck" module parameter is defined
      in drivers/acpi/power.c file. As several module parameters using the same ACPI
      prefix are defined in the different files(for example: power_nocheck is
      defined in drivers/acpi/power.c,debug_layer/debug_level are defined in
      drivers/acpi/debug.c) and there exists another module between them, the
      warning message will be printed when using the current generic param code.
      (In the function of param_sysfs_init).
      
         In fact when ACPI is selected, the drivers/acpi/power will also be compiled
      as built-in kernel.So this issue can be fixed by the following approach.
         workaround it by adjusting the module link order in drivers/acpi/Makefile.
      In such case the module parameter using the same prefix(ACPI) are put together
      in the param data section.
      
         Of course the better solution is to fix it in generic param code related
      with sysfs.
      Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      5eaff722
  18. 24 9月, 2008 1 次提交
  19. 17 7月, 2008 1 次提交
  20. 11 6月, 2008 1 次提交
  21. 09 2月, 2008 1 次提交
  22. 06 2月, 2008 1 次提交
    • C
      ACPI: WMI: Add ACPI-WMI mapping driver · bff431e4
      Carlos Corbacho 提交于
      The following is an implementation of the Windows Management
      Instrumentation (WMI) ACPI interface mapper (PNP0C14).
      
      What it does:
      
      Parses the _WDG method and exports functions to process WMI method calls,
      data block query/ set commands (both based on GUID) and does basic event
      handling.
      
      How: WMI presents an in kernel interface here (essentially, a minimal
      wrapper around ACPI)
      
      (const char *guid assume the 36 character ASCII representation of
      a GUID - e.g. 67C3371D-95A3-4C37-BB61-DD47B491DAAB)
      
      wmi_evaluate_method(const char *guid, u8 instance, u32 method_id,
      const struct acpi_buffer *in, struct acpi_buffer *out)
      
      wmi_query_block(const char *guid, u8 instance,
      struct acpi_buffer *out)
      
      wmi_set_block(const char *guid, u38 instance,
      const struct acpi_buffer *in)
      
      wmi_install_notify_handler(acpi_notify_handler handler);
      
      wmi_remove_notify_handler(void);
      
      wmi_get_event_data(u32 event, struct acpi_buffer *out)
      
      wmi_has_guid(const char guid*)
      
      wmi_has_guid() is a helper function to find if a GUID exists or not on the
      system (a quick and easy way for WMI dependant drivers to see if the
      the method/ block they want exists, since GUIDs are supposed to be unique).
      
      Event handling - allow a WMI based driver to register a notifier handler
      for each GUID with WMI. When a notification is sent to a GUID in WMI, the
      handler registered with WMI is then called (it is left to the caller to
      ask for the WMI event data associated with the GUID, if needed).
      
      What it won't do:
      
      Unicode - The MS article[1] calls for converting between ASCII and Unicode (or
      vice versa) if a GUID is marked as "string". This is left up to the calling
      driver.
      
      Handle a MOF[1] - the WMI mapper just exports methods, data and events to
      userspace. MOF handling is down to userspace.
      
      Userspace interface - this will be added later.
      
      [1] http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx
      
      ===
      ChangeLog
      ==
      
      v1 (2007-10-02):
      
      * Initial release
      
      v2 (2007-10-05):
      
      * Cleaned up code - split up super "wmi_evaluate_block" -> each external
        symbol now handles its own ACPI calls, rather than handing off to
        a "super" method (and in turn, is a lot simpler to read)
      * Added a find_guid() symbol - return true if a given GUID exists on
        the system
      * wmi_* functions now return type acpi_status (since they are just
        fancy wrappers around acpi_evaluate_object())
      * Removed extra debug code
      
      v3 (2007-10-27)
      
      * More code clean up - now passes checkpatch.pl
      * Change data block calls - ref MS spec, method ID is not required for
        them, so drop it from the function parameters.
      * Const'ify guid in the function call parameters.
      * Fix _WDG buffer handling - copy the data to our own private structure.
      * Change WMI from tristate to bool - otherwise the external functions are
        not exported in linux/acpi.h if you try to build WMI as a module.
      * Fix more flag comparisons.
      * Add a maintainers entry - since I wrote this, I should take the blame
        for it.
      
      v4 (2007-10-30)
      
      * Add missing brace from after fixing checkpatch errors.
      * Rewrote event handling - allow external drivers to register with WMI to
        handle WMI events
      * Clean up flags and sanitise flag handling
      
      v5 (2007-11-03)
      
      * Add sysfs interface for userspace. Export events over netlink again.
      * Remove module left overs, fully convert to built-in driver.
      * Tweak in-kernel API to use u8 for instance, since this is what the GUID
        blocks use (so instance cannot be greater than u8).
      * Export wmi_get_event_data() for in kernel WMI drivers.
      
      v6 (2007-11-07)
      
      * Split out userspace into a different patch
      
      v7 (2007-11-20)
      
      * Fix driver to handle multiple PNP0C14 devices - store all GUIDs using
        the kernel's built in list functions, and just keep adding to the list
        every time we handle a PNP0C14 devices - GUIDs will always be unique,
        and WMI callers do not know or care about different devices.
      * Change WMI event handler registration to use its' own event handling
        struct; we should not pass an acpi_handle down to any WMI based drivers
        - they should be able to function with only the calls provided in WMI.
      * Update my e-mail address
      
      v8 (2007-11-28)
      
      * Convert back to a module.
      * Update Kconfig to default to building as a module.
      * Remove an erroneous printk.
      * Simply comments for string flag (since we now leave the handling to the
        caller).
      
      v9 (2007-12-07)
      
      * Add back missing MODULE_DEVICE_TABLE for autoloading
      * Checkpatch fixes
      
      v10 (2007-12-12)
      
      * Workaround broken GUIDs declared expensive without a WCxx method.
      * Minor cleanups
      
      v11 (2007-12-17)
      
      * More fixing for broken GUIDs declared expensive without a WCxx method.
      * Add basic EmbeddedControl region handling.
      
      v12 (2007-12-18)
      
      * Changed EC region handling code, as per Alexey's comments.
      
      v13 (2007-12-27)
      
      * Changed event handling so that we can have one event handler registered
        per GUID, as per Matthew Garrett's suggestion.
      
      v14 (2008-01-12)
      
      * Remove ACPI debug statements
      
      v15 (2008-02-01)
      
      * Replace two remaining 'x == NULL' type tests with '!x'
      
      v16 (2008-02-05)
      
      * Change MAINTAINERS entry, as I am not, and never have been, paid to work
        on WMI
      * Remove 'default' line from Kconfig
      Signed-off-by: NCarlos Corbacho <carlos@strangeworlds.co.uk>
      CC: Matthew Garrett <mjg59@srcf.ucam.org>
      CC: Alexey Starikovskiy <aystarik@gmail.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      bff431e4
  23. 20 11月, 2007 1 次提交
  24. 28 9月, 2007 1 次提交
  25. 26 3月, 2007 1 次提交
  26. 22 3月, 2007 1 次提交
  27. 10 3月, 2007 1 次提交
  28. 17 2月, 2007 1 次提交
  29. 13 2月, 2007 2 次提交
  30. 03 2月, 2007 1 次提交
  31. 26 1月, 2007 1 次提交
  32. 16 12月, 2006 1 次提交
  33. 10 7月, 2006 1 次提交
  34. 09 7月, 2006 1 次提交