1. 29 5月, 2011 1 次提交
  2. 19 3月, 2011 1 次提交
  3. 13 1月, 2011 1 次提交
  4. 12 1月, 2011 4 次提交
  5. 07 1月, 2011 1 次提交
  6. 15 8月, 2010 3 次提交
    • Z
      ACPI: remove deprecated ACPI procfs I/F · 47f5c892
      Zhang Rui 提交于
      Rmove deprecated ACPI procfs I/F, including
      /proc/acpi/debug_layer
      /proc/acpi/debug_level
      /proc/acpi/info
      /proc/acpi/dsdt
      /proc/acpi/fadt
      /proc/acpi/sleep
      
      because the sysfs I/F is already available
      and has been working well for years.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      47f5c892
    • Z
      ACPI: introduce drivers/acpi/sysfs.c · 1c8fce27
      Zhang Rui 提交于
      Introduce drivers/acpi/sysfs.c.
      
      code for ACPI sysfs I/F, including
      #ifdef ACPI_DEBUG
      /sys/module/acpi/parameters/debug_layer
      /sys/module/acpi/parameters/debug_level
      /sys/module/acpi/parameters/trace_method_name
      /sys/module/acpi/parameters/trace_debug_layer
      /sys/module/acpi/parameters/trace_debug_level
      /sys/module/acpi/parameters/trace_state
      #endif
      /sys/module/acpi/parameters/acpica_version
      /sys/firmware/acpi/tables/
      /sys/firmware/acpi/interrupts/
      is moved to this file.
      
      No function change in this patch.
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1c8fce27
    • Z
      ACPI: introduce drivers/acpi/debugfs.c · a25ee920
      Zhang Rui 提交于
      Introduce drivers/acpi/debugfs.c.
      
      Code for ACPI debugfs I/F,
      i.e. /sys/kernel/debug/acpi/custom_method,
      is moved to this file.
      
      And make ACPI debugfs always built in,
      even if CONFIG_ACPI_DEBUG is cleared.
      
      BTW:this adds about 400bytes code to ACPI, when
      CONFIG_ACPI_DEBUG is cleared.
      
      [uaccess.h build fix from Andrew Morton <akpm@linux-foundation.org>]
      Signed-off-by: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a25ee920
  7. 03 8月, 2010 1 次提交
    • T
      ACPI: Provide /sys/kernel/debug/ec/... · 1195a098
      Thomas Renninger 提交于
      This patch provides the same information through debugfs, which previously was
      provided through /proc/acpi/embedded_controller/*/info
      
      This is the gpe the EC is connected to and whether the global lock
      gets used.
      The io ports used are added to /proc/ioports in another patch.
      Beside the fact that /proc/acpi is deprecated for quite some time,
      this info is not needed for applications and thus can be moved
      to debugfs instead of a public interface like /sys.
      Signed-off-by: NThomas Renninger <trenn@suse.de>
      
      CC: Alexey Starikovskiy <astarikovskiy@suse.de>
      CC: Len Brown <lenb@kernel.org>
      CC: linux-kernel@vger.kernel.org
      CC: linux-acpi@vger.kernel.org
      CC: Bjorn Helgaas <bjorn.helgaas@hp.com>
      CC: platform-driver-x86@vger.kernel.org
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      1195a098
  8. 29 5月, 2010 2 次提交
    • R
      ACPI / EC / PM: Fix names of functions that block/unblock EC transactions · fe955682
      Rafael J. Wysocki 提交于
      The names of the functions used for blocking/unblocking EC
      transactions during suspend/hibernation suggest that the transactions
      are suspended and resumed by them, while in fact they are disabled
      and enabled.  Rename the functions (and the flag used by them) to
      better reflect what they really do.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      fe955682
    • R
      ACPI / EC / PM: Fix race between EC transactions and system suspend · d5a64513
      Rafael J. Wysocki 提交于
      There still is a race that may result in suspending the system in
      the middle of an EC transaction in progress, which leads to problems
      (like the kernel thinking that the ACPI global lock is held during
      resume while in fact it's not).
      
      To remove the race condition, modify the ACPI platform suspend and
      hibernate callbacks so that EC transactions are blocked right after
      executing the _PTS global control method and are allowed to happen
      again right after the low-level wakeup.
      
      Introduce acpi_pm_freeze() that will disable GPEs, wait until the
      event queues are empty and block EC transactions.  Use it wherever
      GPEs are disabled in preparation for switching local interrupts off.
      Introduce acpi_pm_thaw() that will allow EC transactions to happen
      again and enable runtime GPEs.  Use it to balance acpi_pm_freeze()
      wherever necessary.
      
      In addition to that use acpi_ec_resume_transactions_early() to
      unblock EC transactions as early as reasonably possible during
      resume.  Also unblock EC transactions in acpi_hibernation_finish()
      and in the analogous suspend routine to make sure that the EC
      transactions are enabled in all error paths.
      
      Fixes https://bugzilla.kernel.org/show_bug.cgi?id=14668Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reported-and-tested-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      d5a64513
  9. 09 3月, 2010 1 次提交
  10. 23 2月, 2010 1 次提交
    • R
      PCI / ACPI / PM: Platform support for PCI PME wake-up · b67ea761
      Rafael J. Wysocki 提交于
      Although the majority of PCI devices can generate PMEs that in
      principle may be used to wake up devices suspended at run time,
      platform support is generally necessary to convert PMEs into wake-up
      events that can be delivered to the kernel.  If ACPI is used for this
      purpose, PME signals generated by a PCI device will trigger the ACPI
      GPE associated with the device to generate an ACPI wake-up event that
      we can set up a handler for, provided that everything is configured
      correctly.
      
      Unfortunately, the subset of PCI devices that have GPEs associated
      with them is quite limited.  The devices without dedicated GPEs have
      to rely on the GPEs associated with other devices (in the majority of
      cases their upstream bridges and, possibly, the root bridge) to
      generate ACPI wake-up events in response to PME signals from them.
      
      Add ACPI platform support for PCI PME wake-up:
      o Add a framework making is possible to use ACPI system notify
        handlers for run-time PM.
      o Add new PCI platform callback ->run_wake() to struct
        pci_platform_pm_ops allowing us to enable/disable the platform to
        generate wake-up events for given device.  Implemet this callback
        for the ACPI platform.
      o Define ACPI wake-up handlers for PCI devices and PCI root buses and
        make the PCI-ACPI binding code register wake-up notifiers for all
        PCI devices present in the ACPI tables.
      o Add function pci_dev_run_wake() which can be used by PCI drivers to
        check if given device is capable of generating wake-up events at
        run time.
      
      Developed in cooperation with Matthew Garrett <mjg@redhat.com>.
      Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      b67ea761
  11. 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
  12. 29 8月, 2009 1 次提交
  13. 28 3月, 2009 8 次提交
  14. 17 3月, 2009 1 次提交