- 22 5月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Currently, drivers/acpi/device_pm.c depends on CONFIG_PM and all of the functions defined in there are replaced with static inline stubs if that option is unset. However, CONFIG_PM means, roughly, "runtime PM or suspend/hibernation support" and some of those functions are useful regardless of that. For example, they are used by the ACPI fan driver for controlling fans and acpi_device_set_power() is called during device removal. Moreover, device initialization may depend on setting device power states properly. For these reasons, make the routines manipulating ACPI device power states defined in drivers/acpi/device_pm.c available for CONFIG_PM unset too. Reported-by: NZhang Rui <rui.zhang@intel.com> Reported-and-tested-by: NMichel Lespinasse <walken@google.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: 3.9+ <stable@vger.kernel.org>
-
- 14 5月, 2013 1 次提交
-
-
由 Andy Shevchenko 提交于
Since we have CSRT only to get additional DMA controller resources, let's get rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NVinod Koul <vinod.koul@intel.com>
-
- 22 3月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Devices on the Intel Lynxpoint Low Power Subsystem (LPSS) have some common features that aren't shared with any other platform devices, including the clock and LTR (Latency Tolerance Reporting) registers. It is better to handle those features in common code than to bother device drivers with doing that (I/O functionality-wise the LPSS devices are generally compatible with other devices that don't have those special registers and may be handled by the same drivers). The clock registers of the LPSS devices are now taken care of by the special clk-x86-lpss driver, but the MMIO mappings used for accessing those registers can also be used for accessing the LTR registers on those devices (LTR support for the Lynxpoint LPSS is going to be added by a subsequent patch). Thus it is convenient to add a special ACPI scan handler for the Lynxpoint LPSS devices that will create the MMIO mappings for accessing the clock (and LTR in the future) registers and will register the LPSS devices' clocks, so the clk-x86-lpss driver will only need to take care of the main Lynxpoint LPSS clock. Introduce a special ACPI scan handler for Intel Lynxpoint LPSS devices as described above. This also reduces overhead related to browsing the ACPI namespace in search of the LPSS devices before the registration of their clocks, removes some LPSS-specific (and somewhat ugly) code from acpi_platform.c and shrinks the overall code size slightly. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NMike Turquette <mturquette@linaro.org>
-
- 20 1月, 2013 1 次提交
-
-
由 Mika Westerberg 提交于
Core System Resources Table (CSRT) is a proprietary ACPI table that contains resources for certain devices that are not found in the DSDT table. Typically a shared DMA controller might be found here. This patch adds support for this table. We go through all entries in the table and make platform devices of them. The resources from the table are passed with the platform device. There is one special resource in the table and it is the DMA request line base and number of request lines. This information might be needed by the DMA controller driver as it needs to map the ACPI DMA request line number to the actual request line understood by the hardware. This range is passed as IORESOURCE_DMA resource. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 03 1月, 2013 1 次提交
-
-
由 Rafael J. Wysocki 提交于
Move the code related to _PRT setup and removal and to power resources from acpi_pci_bind() and acpi_pci_unbind() to the .setup() and .cleanup() callbacks in acpi_pci_bus and remove acpi_pci_bind() and acpi_pci_unbind() that have no purpose any more. Accordingly, remove the code related to device .bind() and .unbind() operations from the ACPI PCI root bridge driver. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: NYinghai Lu <yinghai@kernel.org> Acked-by: NToshi Kani <toshi.kani@hp.com>
-
- 23 11月, 2012 1 次提交
-
-
由 Mika Westerberg 提交于
ACPI 5 introduced I2cSerialBus resource that makes it possible to enumerate and configure the I2C slave devices behind the I2C controller. This patch adds helper functions to support I2C slave enumeration. An ACPI enabled I2C controller driver only needs to call acpi_i2c_register_devices() in order to get its slave devices enumerated, created and bound to the corresponding ACPI handle. Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 15 11月, 2012 3 次提交
-
-
由 Rafael J. Wysocki 提交于
Move some code used for parsing ACPI device resources from the PNP subsystem to the ACPI core, so that other bus types (platform, SPI, I2C) can use the same routines for parsing resources in a consistent way, without duplicating code. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com> Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
-
由 Mika Westerberg 提交于
With ACPI 5 it is now possible to enumerate traditional SoC peripherals, like serial bus controllers and slave devices behind them. These devices are typically based on IP-blocks used in many existing SoC platforms and platform drivers for them may already be present in the kernel tree. To make driver "porting" more straightforward, add ACPI support to the platform bus type. Instead of writing ACPI "glue" drivers for the existing platform drivers, register the platform bus type with ACPI to create platform device objects for the drivers and bind the corresponding ACPI handles to those platform devices. This should allow us to reuse the existing platform drivers for the devices in question with the minimum amount of modifications. This changeset is based on Mika Westerberg's and Mathias Nyman's work. Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com> Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: NH. Peter Anvin <hpa@zytor.com> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Rafael J. Wysocki 提交于
ACPI routines for adding and removing device wakeup notifiers are currently defined in a PCI-specific file, but they will be necessary for non-PCI devices too, so move them to a separate file under drivers/acpi and rename them to indicate their ACPI origins. Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- 17 10月, 2012 1 次提交
-
-
由 Matthew Garrett 提交于
Drivers may make calls that require the ACPI IPMI driver to have been initialised already, so make sure that it appears earlier in the build order. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 30 3月, 2012 1 次提交
-
-
由 Matthew Garrett 提交于
ACPI 5.0 adds the BGRT, a table that contains a pointer to the firmware boot splash and associated metadata. This simple driver exposes it via /sys/firmware/acpi in order to allow bootsplash applications to draw their splash around the firmware image and reduce the number of jarring graphical transitions during boot. Signed-off-by: NMatthew Garrett <mjg@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 21 1月, 2012 1 次提交
-
-
由 Myron Stowe 提交于
With the conversion of atomicio's routines in place (see commits 6f68c91c and 700130b4), atomicio.[ch] can be removed, replacing the APEI specific pre-mapping capabilities with the more generalized versions that drivers/acpi/osl.c provides. Signed-off-by: NMyron Stowe <myron.stowe@redhat.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 17 1月, 2012 1 次提交
-
-
由 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>
-
- 29 5月, 2011 1 次提交
-
-
由 Thomas Renninger 提交于
With /sys/kernel/debug/acpi/custom_method root can write to arbitrary memory and increase his priveleges, even if these are restricted. -> Make this an own debug .config option and warn about the security issue in the config description. -> Still keep acpi/debugfs.c which now only creates an empty /sys/kernel/debug/acpi directory. There might be other users of it later. Signed-off-by: NThomas Renninger <trenn@suse.de> Acked-by: NRafael J. Wysocki <rjw@sisk.pl> Acked-by: rui.zhang@intel.com Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 26 5月, 2011 1 次提交
-
-
由 Jean Delvare 提交于
As discussed earlier, the ACPI power meter driver would better live in drivers/hwmon, as its only purpose is to create hwmon-style interfaces for ACPI 4.0 power meter devices. Users are more likely to look for it there, and less likely to accidentally hide it by unselecting its dependencies. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: N"Darrick J. Wong" <djwong@us.ibm.com> Acked-by: NGuenter Roeck <guenter.roeck@ericsson.com> Cc: Len Brown <lenb@kernel.org>
-
- 07 1月, 2011 1 次提交
-
-
由 Rafael J. Wysocki 提交于
The saving of the ACPI NVS area during hibernation and suspend and restoring it during the subsequent resume is entirely specific to ACPI, so move it to drivers/acpi and drop the CONFIG_SUSPEND_NVS configuration option which is redundant. Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 14 12月, 2010 1 次提交
-
-
由 Zhao Yakui 提交于
ACPI 4.0 spec adds the ACPI IPMI opregion, which means that the ACPI AML code can also communicate with the BMC controller. This is to install the ACPI IPMI opregion and enable the ACPI to access the BMC controller through the IPMI message. It will create IPMI user interface for every IPMI device detected in ACPI namespace and install the corresponding IPMI opregion space handler. Then it can enable ACPI to access the BMC controller through the IPMI message. The following describes how to process the IPMI request in IPMI space handler: 1. format the IPMI message based on the request in AML code. IPMI system address. Now the address type is SYSTEM_INTERFACE_ADDR_TYPE IPMI net function & command IPMI message payload 2. send the IPMI message by using the function of ipmi_request_settime 3. wait for the completion of IPMI message. It can be done in different routes: One is in handled in IPMI user recv callback function. Another is handled in timeout function. 4. format the IPMI response and return it to ACPI AML code. At the same time it also addes the module dependency. The ACPI IPMI opregion will depend on the IPMI subsystem. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NCorey Minyard <cminyard@mvista.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 15 8月, 2010 3 次提交
-
-
由 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>
-
由 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>
-
由 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>
-
- 03 8月, 2010 1 次提交
-
-
由 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>
-
- 20 5月, 2010 3 次提交
-
-
由 Huang Ying 提交于
Hardware Error Device (PNP0C33) is used to report some hardware errors notified via SCI, mainly the corrected errors. Some APEI Generic Hardware Error Source (GHES) may use SCI on hardware error device to notify hardware error to kernel. After receiving notification from ACPI core, it is forwarded to all listeners via a notifier chain. The listener such as APEI GHES should check corresponding error source for new events when notified. 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>
-
由 Huang Ying 提交于
Now, a dedicated HEST tabling parsing code is used for PCIE AER firmware_first setup. It is rebased on general HEST tabling parsing code of APEI. The firmware_first setup code is moved from PCI core to AER driver too, because it is only AER related. Signed-off-by: NHuang Ying <ying.huang@intel.com> Signed-off-by: NAndi Kleen <ak@linux.intel.com> Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Huang Ying 提交于
APEI stands for ACPI Platform Error Interface, which allows to report errors (for example from the chipset) to the operating system. This improves NMI handling especially. In addition it supports error serialization and error injection. For more information about APEI, please refer to ACPI Specification version 4.0, chapter 17. This patch provides some common functions used by more than one APEI tables, mainly framework of interpreter for EINJ and ERST. A machine readable language is defined for EINJ and ERST for OS to execute, and so to drive the firmware to fulfill the corresponding functions. The machine language for EINJ and ERST is compatible, so a common framework is defined for them. 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>
-
- 19 5月, 2010 1 次提交
-
-
由 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>
-
- 15 3月, 2010 2 次提交
-
-
由 Alex Chiang 提交于
We've renamed the old processor_core.c to processor_driver.c, to convey the idea that it can be built modular and has driver-like bits. Now let's re-create a processor_core.c for the bits needed statically by the rest of the kernel. The contents of processor_pdc.c are a good starting spot, so let's just rename that file and complete our three card monte. Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex Chiang 提交于
The ACPI processor driver can be built as a module. But it has pieces of code that should always be built statically into the kernel. The plan is for processor_core.c to contain the static bits while processor_driver.c contains the module-like bits. Since the bulk of the code in the current processor_core.c is module-like, first step is to rename the file to processor_driver.c Next step will re-create processor_core.c and cherry-pick out the static bits. Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 22 12月, 2009 1 次提交
-
-
由 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>
-
- 05 11月, 2009 1 次提交
-
-
由 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>
-
- 19 9月, 2009 1 次提交
-
-
由 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>
-
- 01 8月, 2009 1 次提交
-
-
由 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>
-
- 05 4月, 2009 1 次提交
-
-
由 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>
-
- 03 4月, 2009 2 次提交
-
-
由 Len Brown 提交于
Suggested-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Rusty Russell 提交于
Impact: cleanup Rather than overriding MODULE_PARAM_PREFIX, build via acpi.o so KBUILD_MODNAME is set to "acpi". This is the logical way to do it, even though acpi cannot be a module due to these config options being bool. Those parts of ACPI which can be modular are not built into the acpi "module". Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 28 3月, 2009 1 次提交
-
-
由 Bjorn Helgaas 提交于
This patch removes the suggestion that ec.o link order is important, because it doesn't matter since acpi_ec_init() is no longer an initcall. And it puts together most of the core modules that are not configurable. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 22 2月, 2009 1 次提交
-
-
由 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>
-
- 17 1月, 2009 1 次提交
-
-
由 Len Brown 提交于
Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 09 1月, 2009 1 次提交
-
-
由 Len Brown 提交于
also, delete sleep/ and delete ACPI_CFLAGS from Makefile Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 19 12月, 2008 1 次提交
-
-
由 Len Brown 提交于
These are platform specific drivers that happen to use ACPI, while drivers/acpi/ is for code that implements ACPI itself. Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 08 11月, 2008 1 次提交
-
-
由 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>
-