- 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>
-
- 26 6月, 2009 1 次提交
-
-
由 Troy Moure 提交于
ref: http://thread.gmane.org/gmane.linux.kernel/857228/focus=857468 When the ACPI video driver initializes, it does a namespace walk looking for for supported devices. When we find an appropriate handle, we walk up the ACPI tree looking for a PCI root bus, and then walk back down the PCI bus, assuming that every device inbetween is a P2P bridge. This assumption is not correct, and is reported broken on at least: Dell Latitude E6400 ThinkPad X61 Dell XPS M1330 Add a NULL deref check to prevent boot panics. Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com> Signed-off-by: NTroy Moure <twmoure@szypr.net> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 24 6月, 2009 7 次提交
-
-
由 Zhao Yakui 提交于
Some BIOS re-use the same processor bus id in different scope: \_SB.SCK0.CPU0 \_SB.SCK1.CPU0 But the (deprecated) /proc/acpi/ interface assumes the bus-id's are unique, resulting in an OOPS when the processor driver is loaded: WARNING: at fs/proc/generic.c:590 proc_register+0x148/0x180() Hardware name: Sunrise Ridge proc_dir_entry 'processor/CPU0' already registered Call Trace: [<ffffffff8023f7ef>] warn_slowpath+0xb1/0xe5 [<ffffffff8036243b>] ? ida_get_new_above+0x190/0x1b1 [<ffffffff803625a8>] ? idr_pre_get+0x5f/0x75 [<ffffffff8030b2f6>] proc_register+0x148/0x180 [<ffffffff8030b4ff>] proc_mkdir_mode+0x3d/0x52 [<ffffffff8030b525>] proc_mkdir+0x11/0x13 [<ffffffffa0014b89>] acpi_processor_start+0x755/0x9bc [processor] Rename the processor device bus id. And the new bus id will be generated as the following format: CPU+ CPU ID For example: If the cpu ID is 5, then the bus ID will be "CPU5". If the CPU ID is 10, then the bus ID will be "CPUA". Yes, this will change the directory names seen in /proc/acpi/processor/* on some systems. Before this patch, those directory names where totally arbitrary strings based on the interal AML device strings. http://bugzilla.kernel.org/show_bug.cgi?id=13612Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
http://bugzilla.kernel.org/show_bug.cgi?id=13121Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Now that new interface is available, convert to using it rather than creating a new kernel thread. Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhao Yakui 提交于
Sometimes both acpi video and i915 driver are compiled as modules. And there exists the strict dependency between the two drivers. The acpi video bus will be unloaded in course of unloading the i915 driver. If we unload the acpi video driver, then the kernel oops will be triggered. Add the reference count to avoid unloading the ACPI video bus twice. The reference count should be checked before unregistering the acpi video bus. If the reference count is already zero, it won't unregister it again. And after the acpi video bus is already unregistered, the reference count will be set to zero. http://bugzilla.kernel.org/show_bug.cgi?id=13396Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Acked-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Linux claims Vista compatibility to the BIOS for a number of reasons, but this brings hard lockup on some Sony laptops. Disable Vista compatibility via DMI for these laptops unless we can figure out what Vista is doing for this platform. http://bugzilla.kernel.org/show_bug.cgi?id=12904Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
we used to run the hotplug code in keventd_wq. But when hot removing the ACPI battery device, power_supply_unregister invokes flush_scheduled_work. This causes a deadlock. i.e 1. When dock is unplugged, all the hotplug code is run on kevent_wq. 2. the hotplug code removes all the child devices of dock device. 3. removing the child device may invoke flush_scheduled_work 4. flush_scheduled_work waits until all the work on kevent_wq to be finished, while this will never be true because the hotplug code is running on keventd_wq... Introduce a new workqueue for hotplug in this patch. http://bugzilla.kernel.org/show_bug.cgi?id=13533Tested-by: NPaul Martin <pm@debian.org> Tested-by: NVojtech Gondzala <vojtech.gondzala@gmail.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Reviewed-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Zhang Rui 提交于
Create symbol link from backlight class device to ACPI video device. More and more laptops are shipped with multiple ACPI video devices, while we export only one of them to userspace. With this patch applied, we can know which ACPI video device is used by "cat /sys/class/backlight/acpi_video0/device/path". Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 20 6月, 2009 6 次提交
-
-
由 Pallipadi, Venkatesh 提交于
arch_acpi_processor_cleanup_pdc() in x86 and ia64 results in memory allocated for _PDC objects that is never freed and will cause memory leak in case of physical CPU remove and add. Patch fixes the memory leak by freeing the objects soon after _PDC is evaluated. Reported-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
We never use the PCI device & function number, so remove it to make it clear that it's not needed. Many PCI host bridges don't even appear in config space, so it's meaningless to look at stuff from _ADR, which doesn't exist in that case. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Using list_for_each_entry() makes traversing the root list easier. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
There's no need to search the list to find the acpi_pci_root structure. We saved it as device->driver_data when we added the device. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
By looking up the segment & bus number earlier, we don't have to worry about cleaning up if it fails. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
To find a host bridge's downstream bus number, we currently look at _BBN first. If _BBN returns a bus number we've already seen, we conclude that _BBN was wrong and look for a bus number in _CRS. However, the spec[1] (figure 5-5 and the example in sec 9.12.1) and an ACPI FAQ[2] suggest that the OS should use _CRS to discover the bus number range, and that _BBN is really intended to bootstrap _CRS methods that reference PCI opregions. This patch makes us always look at _CRS first. If _CRS doesn't supply a bus number, we look at _BBN. If _BBN doesn't exist, we default to zero. This makes the behavior consistent regardless of device discovery order. Previously, if A and B had duplicate _BBNs and we found A first, we'd only look at B's _CRS, whereas if we found B first, we'd only look at A's _CRS. I'm told that Windows discovers host bridge bus numbers using _CRS, so it should be fairly safe to rely on this BIOS functionality. This patch also removes two misleading messages: we printed the "Wrong _BBN value, reboot and use option 'pci=noacpi'" message before looking at _CRS, so we would likely find the bus number in _CRS, the system would work fine, and the user would be confused. The "PCI _CRS %d overrides _BBN 0" message incorrectly assumes _BBN was zero, and it's useless anyway because we print the segment/bus number a few lines later. References: [1] http://www.acpi.info/DOWNLOADS/ACPIspec30b.pdf [2] http://www.acpi.info/acpi_faq.htm _BBN/_CRS discussion http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05005_WinHEC05.ppt (slide 17) http://bugzilla.kernel.org/show_bug.cgi?id=1662 ASUS PR-DLS http://bugzilla.kernel.org/show_bug.cgi?id=1127 ASUS PR-DLSW http://bugzilla.kernel.org/show_bug.cgi?id=1741 ASUS PR-DLS533 Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Reviewed-by: NAlex Chiang <achiang@hp.com> CC: Shaohua Li <shaohua.li@intel.com> CC: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 19 6月, 2009 1 次提交
-
-
由 Alex Chiang 提交于
There is no way to interact with a physical PCI slot without sysfs, so encode the dependency and prevent this build error: drivers/pci/slot.c: In function 'pci_hp_create_module_link': drivers/pci/slot.c:327: error: 'module_kset' undeclared This patch _should_ make pci-sysfs.o depend on CONFIG_SYSFS too, but we cannot (yet) because the PCI core merrily assumes the existence of sysfs: drivers/built-in.o: In function `pci_bus_add_device': drivers/pci/bus.c:89: undefined reference to `pci_create_sysfs_dev_files' drivers/built-in.o: In function `pci_stop_dev': drivers/pci/remove.c:24: undefined reference to `pci_remove_sysfs_dev_files' So do the minimal bit for now and figure out how to untangle it later. Reported-by: NRandy Dunlap <randy.dunlap@oracle.com> Acked-by: NRandy Dunlap <randy.dunlap@oracle.com> Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Fix-suggested-by: NMatthew Wilcox <matthew@wil.cx> Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
- 18 6月, 2009 22 次提交
-
-
由 Len Brown 提交于
cosmetic only. The lapic_timer workaround routines are specific to the lapic_timer, and are not acpi-generic. old: acpi_timer_check_state() acpi_propagate_timer_broadcast() acpi_state_timer_broadcast() new: lapic_timer_check_state() lapic_timer_propagate_broadcast() lapic_timer_state_broadcast() also, simplify the code in acpi_processor_power_verify() so that lapic_timer_check_state() is simply called from one place for all valid C-states, including C1. Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Len Brown 提交于
drivers/acpi/battery.c:841: warning: label ‘end’ defined but not used Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
This patch changes the global system notification path so it uses the acpi_handle, not the acpi_device. System notifications often deal with device presence and status change. In these cases, we may not have an acpi_device. For example, we may get a Device Check notification on an object that previously was not present. Since the object was not present, we would not have had an acpi_device for it. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Remove return values from acpi_bus_check_device() and acpi_bus_check_scope() since nobody looks at them. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
Remove "status_changed" return from acpi_bus_check_device(). Nobody does anything useful based on its value. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
This replaces several messages that depend on the acpi_device struct with a single message that uses just the acpi_handle. We should be able to deal with notifications to objects that do not yet have an acpi_device struct. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. This driver apparently relies on seeing ALL notify events, not just device-specific ones (because it used ACPI_ALL_NOTIFY). We use the ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
This patch adds a .notify() method. The presence of .notify() causes Linux/ACPI to manage event handlers and notify handlers on our behalf, so we don't have to install and remove them ourselves. This driver apparently relies on seeing ALL notify events, not just device-specific ones (because it used ACPI_ALL_NOTIFY). We use the ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag to request all events. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> CC: Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Bjorn Helgaas 提交于
System notify events (0x00-0x7f) are common across all device types and should be handled in Linux/ACPI, not in drivers. However, some BIOSes use system notify events in device-specific ways that require the driver to be involved. This patch adds a ACPI_DRIVER_ALL_NOTIFY_EVENTS driver flag. When a driver sets this flag and supplies a .notify method, Linux/ACPI calls the .notify method for ALL notify events on the device, not just the device-specific (0x80-0xff) events. Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
acpi_get_pci_dev() is (hopefully) better, and all callers have been converted, so let's get rid of this duplicated functionality. Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
Now that acpi_get_pci_dev is available, let's use it instead of acpi_get_physical_pci_device() Cc: Thomas Renninger <trenn@suse.de> Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
acpi_get_pci_dev() is better, and all callers have been converted, so eliminate acpi_get_pci_id(). Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
In acpi_pci_bind, we set device->ops.bind and device->ops.unbind, but never clear them out. Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
There is no need to pass a segment/bus tuple to this API, as the callsite always has a struct pci_bus. We can derive segment/bus from the struct pci_bus, so let's take this opportunit to simplify the API and make life easier for the callers. Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
A PCI domain cannot change as you descend down subordinate buses, which makes the 'segment' argument to acpi_pci_irq_add_prt() useless. Change the interface to take a struct pci_bus *, from whence we can derive the bus number and segment. Reducing the number of arguments makes life simpler for callers. Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
Now that we can dynamically convert an ACPI CA handle to a struct pci_dev at runtime, there's no need to statically bind them during boot. acpi_pci_bind/unbind are vastly simplified, and are only used to evaluate _PRT methods on P2P bridges and non-bridge children. This patch also changes the time-space tradeoff ever so slightly. Looking up the ACPI-PCI binding is never in the performance path, and by eliminating this caching, we save 24 bytes for each _ADR device in the ACPI namespace. This patch lays further groundwork to eventually eliminate the acpi_driver_ops.bind callback. Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
This is a pure code movement patch that does $subject in order to make the following patch easier to read and review. No functional change. Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
Convert an ACPI CA handle to a struct pci_dev. Performing this lookup dynamically allows us to get rid of the ACPI-PCI binding code, which: - eliminates struct acpi_device vs struct pci_dev lifetime issues - lays more groundwork for eliminating .start from acpi_device_ops and thus simplifying ACPI drivers - whacks out a lot of code This change lays the groundwork for eliminating much of pci_bind.c. Although pci_root.c may not be the most logical place for this change, putting it here saves us from having to export acpi_pci_find_root. Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
Returns whether an ACPI CA node is a PCI root bridge or not. This API is generically useful, and shouldn't just be a hotplug function. The implementation becomes much simpler as well. Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alexander Chiang 提交于
acpi_pci_root_add() explicitly assigns device->ops.bind, and later calls acpi_pci_bind_root(), which also does the same thing. We don't need to repeat ourselves; removing the explicit assignment allows us to make acpi_pci_bind() static. Signed-off-by: NAlex Chiang <achiang@hp.com> Acked-by: NBjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex Chiang 提交于
Align labels in column 0, adjust spacing in 'if' statements, eliminate trailing and superfluous whitespaces. Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Alex Chiang 提交于
There is no apparent reason for acpi_device_register() to manually register a new device in two steps (initialize then add). Just call device_register() directly. Signed-off-by: NAlex Chiang <achiang@hp.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 09 6月, 2009 1 次提交
-
-
由 Yinghai Lu 提交于
These are defined as static cpumask_var_t so if MAXSMP is not used, they are cleared already. Avoid surprises when MAXSMP is enabled. Signed-off-by: NYinghai Lu <yinghai.lu@kernel.org> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
-
- 30 5月, 2009 1 次提交
-
-
由 Frans Pop 提交于
Commit 4973b22a ("ACPI processor: reset the throttling state once it's invalid") introduced a new warning which prints a spurious newline. The ACPI_WARNING macro that is used already takes care of adding a newline, after adding ACPI_CA_VERSION to the message. Remove the newline to avoid the message getting split into two lines. Signed-off-by: NFrans Pop <elendil@planet.nl> Signed-off-by: NLen Brown <len.brown@intel.com>
-