| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* acpi-video:
ACPI / video: Add Acer TravelMate B113 to native backlight blacklist
ACPI / video: Add Dell Inspiron 5737 to the blacklist
ACPI / i915: ignore firmware requests for backlight change
|
|
* acpi-ec:
ACPI / EC: Free saved_ec on error exit path
ACPI / EC: Add detailed fields debugging support of EC_SC(R).
ACPI / EC: Update revision due to recent changes
ACPI / EC: Fix race condition in ec_transaction_completed()
ACPI / EC: Remove duplicated ec_wait_ibf0() waiter
ACPI / EC: Add asynchronous command byte write support
ACPI / EC: Avoid race condition related to advance_transaction()
|
|
* acpi-resources:
ACPI / resources: only reject zero length resources based at address zero
* acpi-ac:
Revert "ACPI / AC: Remove AC's proc directory."
* acpi-scan:
ACPI / PNP: add soc_button_array device ID to PNP IDs list
* acpi-battery:
ACPI / battery: fix wrong value of capacity_now reported when fully charged
ACPI / battery: Retry to get battery information if failed during probing
|
|
The soc_button_array PNP driver was introduced in 3.15.
But in commit eec15edbb0e1 (ACPI / PNP: use device ID list for
PNPACPI device enumeration), when reworking the PNPACPI device
enumeration, we missed the soc_button_array device ID.
This results in a regression in 3.16-rc1 that soc_button_array
pnp device fails to be enumerated.
Fix the problem by adding soc_button_array device ID into the
acpi_pnp scan handler's ID list.
Fixes: eec15edbb0e1 (ACPI / PNP: use device ID list for PNPACPI device enumeration)
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Fix backlight control for Acer TravelMate B113 Laptop by adding
it to the video_dmi_table.
A workaround before that was to use acpi_osi=Linux or
acpi_backlight=vendor on boot but even then, only the function-
keys worked.
With this change there is no need for boot parameters and DE's
controls work as well.
Signed-off-by: Martin Kepplinger <martink@posteo.de>
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
With win8 capabiltiy, the ACPI backlight control is broken.
The system also loses backlight setting when resuming from S3.
Add this model to the the ACPI video detect blacklist to make backlight
functionality work.
Although backlight functionality works via video.use_native_backlight=1,
this approach may be safer.
Signed-off-by: Edward Lin <yidi.lin@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Some Thinkpad laptops' firmware will initiate a backlight level change
request through operation region on the events of AC plug/unplug, but
since we are not using firmware's interface to do the backlight setting
on these affected laptops, we do not want the firmware to use some
arbitrary value from its ASL variable to set the backlight level on
AC plug/unplug either.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=76491
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77091
Reported-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com>
Reported-and-tested-by: Anton Gubarkov <anton.gubarkov@gmail.com>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
It seems that some batteries (noticed on DELL JYPJ136) assume
capacity_now = design_capacity when fully charged. This causes
reported capacity to suddenly jump to >full_charge_capacity (and that
means capacity reported to userspace is >100% and incorrect)
values after 99%. This patch detects capacity_now > full_charge_capacity,
notifies userspace (unless it is the known bug where capacity_now ==
design_capacity) and trims the value to full_charge_capacity.
Signed-off-by: Josef Gajdusek <atx@atx.name>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The recently merged change (in v3.14-rc6) to ACPI resource detection
(below) causes all zero length ACPI resources to be elided from the
table:
commit b355cee88e3b1a193f0e9a81db810f6f83ad728b
Author: Zhang Rui <rui.zhang@intel.com>
Date: Thu Feb 27 11:37:15 2014 +0800
ACPI / resources: ignore invalid ACPI device resources
This change has caused a regression in (at least) serial port detection
for a number of machines (see LP#1313981 [1]). These seem to represent
their IO regions (presumably incorrectly) as a zero length region.
Reverting the above commit restores these serial devices.
Only elide zero length resources which lie at address 0.
Fixes: b355cee88e3b (ACPI / resources: ignore invalid ACPI device resources)
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Cc: 3.14+ <stable@vger.kernel.org> # 3.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Some machines (eg. Lenovo Z480) ECs are not stable during boot up
and causes battery driver fails to be loaded due to failure of getting
battery information from EC sometimes. After several retries, the
operation will work. This patch is to retry to get battery information 5
times if the first try fails.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581
Reported-and-tested-by: naszar <naszar@ya.ru>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Smatch detected two memory leaks on saved_ec:
drivers/acpi/ec.c:1070 acpi_ec_ecdt_probe() warn: possible
memory leak of 'saved_ec'
drivers/acpi/ec.c:1109 acpi_ec_ecdt_probe() warn: possible
memory leak of 'saved_ec'
Free saved_ec on these two error exit paths to stop the memory
leak. Note that saved_ec maybe null, but kfree on null is allowed.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Developers really don't need to translate EC_SC(R) in mind as long as the
field details are decoded in the debugging message.
Tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The bug fixes and asynchronous improvements have been done to the EC driver
by the previous commits. This patch increases the revision to 2.2 to
indicate the behavior differences between the old and the new drivers. The
copyright/authorship notices are also updated.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
There is a race condition in ec_transaction_completed().
When ec_transaction_completed() is called in the GPE handler, it could
return true because of (ec->curr == NULL). Then the wake_up() invocation
could complete the next command unexpectedly since there is no lock between
the 2 invocations. With the previous cleanup, the IBF=0 waiter race need
not be handled any more. It's now safe to return a flag from
advance_condition() to indicate the requirement of wakeup, the flag is
returned from a locked context.
The ec_transaction_completed() is now only invoked by the ec_poll() where
the ec->curr is ensured to be different from NULL.
After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup
condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a
QR_SC command.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
After we've added the first command byte write into advance_transaction(),
the IBF=0 waiter is duplicated with the command completion waiter
implemented in the ec_poll() because:
If IBF=1 blocked the first command byte write invoked in the task
context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed
out and retried again in the task context.
Remove this seperate and duplicate IBF=0 waiter. By doing so we can
reduce the overall number of times to access the EC_SC(R) status
register.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Move the first command byte write into advance_transaction() so that all
EC register accesses that can affect the command processing state machine
can happen in this asynchronous state machine advancement function.
The advance_transaction() function then can be a complete implementation
of an asyncrhonous transaction for a single command so that:
1. The first command byte can be written in the interrupt context;
2. The command completion waiter can also be used to wait the first command
byte's timeout;
3. In BURST mode, the follow-up command bytes can be written in the
interrupt context directly, so that it doesn't need to return to the
task context. Returning to the task context reduces the throughput of
the BURST mode and in the worst cases where the system workload is very
high, this leads to the hardware driven automatic BURST mode exit.
In order not to increase memory consumption, convert 'done' into 'flags'
to contain multiple indications:
1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition,
indicating the completion of the command transaction.
2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first
command byte. A new command can utilize this flag to compete for the
right of accessing the underlying hardware. There is a follow-up bug
fix that has utilized this new flag.
The 2 flags are important because it also reflects a key concept of IO
programs' design used in the system softwares. Normally an IO program
running in the kernel should first be implemented in the asynchronous way.
And the 2 flags are the most common way to implement its synchronous
operations on top of the asynchronous operations:
1. POLL: This flag can be used to block until the asynchronous operations
can happen.
2. COMPLETE: This flag can be used to block until the asynchronous
operations have completed.
By constructing code cleanly in this way, many difficult problems can be
solved smoothly.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The advance_transaction() will be invoked from the IRQ context GPE handler
and the task context ec_poll(). The handling of this function is locked so
that the EC state machine are ensured to be advanced sequentially.
But there is a problem. Before invoking advance_transaction(), EC_SC(R) is
read. Then for advance_transaction(), there could be race condition around
the lock from both contexts. The first one reading the register could fail
this race and when it passes the stale register value to the state machine
advancement code, the hardware condition is totally different from when
the register is read. And the hardware accesses determined from the wrong
hardware status can break the EC state machine. And there could be cases
that the functionalities of the platform firmware are seriously affected.
For example:
1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may
be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the
hardware will either refuse to respond a next EC_SC(W) write of the next
command or discard the current WR_EC command when it receives a EC_SC(W)
write of the next command.
2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the
EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write.
The next EC_DATA(R) could never be responded by the hardware. This is
the root cause of the reported issue.
Fix this issue by moving the EC_SC(R) access into the lock so that we can
ensure that the state machine is advanced consistently.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891
Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931
Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911
Reported-and-tested-by: Gareth Williams <gareth@garethwilliams.me.uk>
Reported-and-tested-by: Hans de Goede <jwrdegoede@fedoraproject.org>
Reported-by: Barton Xu <tank.xuhan@gmail.com>
Tested-by: Steffen Weber <steffen.weber@gmail.com>
Tested-by: Arthur Chen <axchen@nvidia.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Revert commit ab0fd674d6ce (ACPI / AC: Remove AC's proc directory.),
because some old tools (e.g. kpowersave from kde 3.5.10) are still
using /proc/acpi/ac_adapter.
Fixes: ab0fd674d6ce (ACPI / AC: Remove AC's proc directory.)
Reported-and-tested-by: Sorin Manolache <sorinm@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* acpi-general:
ACPI: use kstrto*() instead of simple_strto*()
* acpi-processor:
ACPI / processor replace __attribute__((packed)) by __packed
* acpi-lpss:
ACPI / LPSS: Take I2C host controllers out of reset
* acpi-battery:
ACPI / battery: add quirk for Acer Aspire V5-573G
ACPI / battery: use callback for setting up quirks
|
|
simple_strto*() are obsolete; use kstrto*() instead. Add proper error
checking.
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
On Acer Aspire V5-573G battery notifications are sometimes
triggered too early. For example, when AC is unplugged and
notification is triggered, battery state is still reported as
"Full", and changes to "Discharging" only after short delay,
without any notification.
This patch solves the problem by adding 1 second sleep.
Similar quirk is already implemented in AC driver for other laptop.
Signed-off-by: Alexander Mezin <mezin.alexander@gmail.com>
Acked-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Use callback for setting up quirk instead of checking return code
of dmi_check_system(). This change will allow using bat_dmi_table
for other quirks.
Signed-off-by: Alexander Mezin <mezin.alexander@gmail.com>
Acked-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
On Intel Baytrail, some I2C host controllers are held in reset when the OS
gets control. This causes the driver to fail to detect the hardware
properly.
Fix this so that we make sure that the I2C host controller is not in reset
when the driver gets probe'd.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* pm-sleep:
PM / sleep: trace events for device PM callbacks
PM / sleep: trace events for suspend/resume
|
|
* acpi-general:
ACPI: Fix bug when ACPI reset register is implemented in system memory
* acpi-video:
ACPI / video: Change the default for video.use_native_backlight to 1
|
|
Adds trace events that give finer resolution into suspend/resume. These
events are graphed in the timelines generated by the analyze_suspend.py
script. They represent large areas of time consumed that are typical to
suspend and resume.
The event is triggered by calling the function "trace_suspend_resume"
with three arguments: a string (the name of the event to be displayed
in the timeline), an integer (case specific number, such as the power
state or cpu number), and a boolean (where true is used to denote the start
of the timeline event, and false to denote the end).
The suspend_resume trace event reproduces the data that the machine_suspend
trace event did, so the latter has been removed.
Signed-off-by: Todd Brandt <todd.e.brandt@intel.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Now that we're hoping to have resolved all of the problems with
video.use_native_backlight=1, make that the default at last.
Link: http://marc.info/?l=linux-acpi&m=139716088401106&w=2
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Use acpi_os_map_generic_address to pre-map the reset register if it is
memory mapped, thereby preventing the BUG_ON() in line 1319 of
mm/vmalloc.c from triggering during panic-triggered reboots.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=77131
Signed-off-by: Randy Wright <rwright@hp.com>
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
[rjw: Changelog, simplified code]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm into next
Pull ACPI and power management updates from Rafael Wysocki:
"ACPICA is the leader this time (63 commits), followed by cpufreq (28
commits), devfreq (15 commits), system suspend/hibernation (12
commits), ACPI video and ACPI device enumeration (10 commits each).
We have no major new features this time, but there are a few
significant changes of how things work. The most visible one will
probably be that we are now going to create platform devices rather
than PNP devices by default for ACPI device objects with _HID. That
was long overdue and will be really necessary to be able to use the
same drivers for the same hardware blocks on ACPI and DT-based systems
going forward. We're not expecting fallout from this one (as usual),
but it's something to watch nevertheless.
The second change having a chance to be visible is that ACPI video
will now default to using native backlight rather than the ACPI
backlight interface which should generally help systems with broken
Win8 BIOSes. We're hoping that all problems with the native backlight
handling that we had previously have been addressed and we are in a
good enough shape to flip the default, but this change should be easy
enough to revert if need be.
In addition to that, the system suspend core has a new mechanism to
allow runtime-suspended devices to stay suspended throughout system
suspend/resume transitions if some extra conditions are met
(generally, they are related to coordination within device hierarchy).
However, enabling this feature requires cooperation from the bus type
layer and for now it has only been implemented for the ACPI PM domain
(used by ACPI-enumerated platform devices mostly today).
Also, the acpidump utility that was previously shipped as a separate
tool will now be provided by the upstream ACPICA along with the rest
of ACPICA code, which will allow it to be more up to date and better
supported, and we have one new cpuidle driver (ARM clps711x).
The rest is improvements related to certain specific use cases,
cleanups and fixes all over the place.
Specifics:
- ACPICA update to upstream version 20140424. That includes a number
of fixes and improvements related to things like GPE handling,
table loading, headers, memory mapping and unmapping, DSDT/SSDT
overriding, and the Unload() operator. The acpidump utility from
upstream ACPICA is included too. From Bob Moore, Lv Zheng, David
Box, David Binderman, and Colin Ian King.
- Fixes and cleanups related to ACPI video and backlight interfaces
from Hans de Goede. That includes blacklist entries for some new
machines and using native backlight by default.
- ACPI device enumeration changes to create platform devices rather
than PNP devices for ACPI device objects with _HID by default. PNP
devices will still be created for the ACPI device object with
device IDs corresponding to real PNP devices, so that change should
not break things left and right, and we're expecting to see more
and more ACPI-enumerated platform devices in the future. From
Zhang Rui and Rafael J Wysocki.
- Updates for the ACPI LPSS (Low-Power Subsystem) driver allowing it
to handle system suspend/resume on Asus T100 correctly. From
Heikki Krogerus and Rafael J Wysocki.
- PM core update introducing a mechanism to allow runtime-suspended
devices to stay suspended over system suspend/resume transitions if
certain additional conditions related to coordination within device
hierarchy are met. Related PM documentation update and ACPI PM
domain support for the new feature. From Rafael J Wysocki.
- Fixes and improvements related to the "freeze" sleep state. They
affect several places including cpuidle, PM core, ACPI core, and
the ACPI battery driver. From Rafael J Wysocki and Zhang Rui.
- Miscellaneous fixes and updates of the ACPI core from Aaron Lu,
Bjørn Mork, Hanjun Guo, Lan Tianyu, and Rafael J Wysocki.
- Fixes and cleanups for the ACPI processor and ACPI PAD (Processor
Aggregator Device) drivers from Baoquan He, Manuel Schölling, Tony
Camuso, and Toshi Kani.
- System suspend/resume optimization in the ACPI battery driver from
Lan Tianyu.
- OPP (Operating Performance Points) subsystem updates from Chander
Kashyap, Mark Brown, and Nishanth Menon.
- cpufreq core fixes, updates and cleanups from Srivatsa S Bhat,
Stratos Karafotis, and Viresh Kumar.
- Updates, fixes and cleanups for the Tegra, powernow-k8, imx6q,
s5pv210, nforce2, and powernv cpufreq drivers from Brian Norris,
Jingoo Han, Paul Bolle, Philipp Zabel, Stratos Karafotis, and
Viresh Kumar.
- intel_pstate driver fixes and cleanups from Dirk Brandewie, Doug
Smythies, and Stratos Karafotis.
- Enabling the big.LITTLE cpufreq driver on arm64 from Mark Brown.
- Fix for the cpuidle menu governor from Chander Kashyap.
- New ARM clps711x cpuidle driver from Alexander Shiyan.
- Hibernate core fixes and cleanups from Chen Gang, Dan Carpenter,
Fabian Frederick, Pali Rohár, and Sebastian Capella.
- Intel RAPL (Running Average Power Limit) driver updates from Jacob
Pan.
- PNP subsystem updates from Bjorn Helgaas and Fabian Frederick.
- devfreq core updates from Chanwoo Choi and Paul Bolle.
- devfreq updates for exynos4 and exynos5 from Chanwoo Choi and
Bartlomiej Zolnierkiewicz.
- turbostat tool fix from Jean Delvare.
- cpupower tool updates from Prarit Bhargava, Ramkumar Ramachandra
and Thomas Renninger.
- New ACPI ec_access.c tool for poking at the EC in a safe way from
Thomas Renninger"
* tag 'pm+acpi-3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (187 commits)
ACPICA: Namespace: Remove _PRP method support.
intel_pstate: Improve initial busy calculation
intel_pstate: add sample time scaling
intel_pstate: Correct rounding in busy calculation
intel_pstate: Remove C0 tracking
PM / hibernate: fixed typo in comment
ACPI: Fix x86 regression related to early mapping size limitation
ACPICA: Tables: Add mechanism to control early table checksum verification.
ACPI / scan: use platform bus type by default for _HID enumeration
ACPI / scan: always register ACPI LPSS scan handler
ACPI / scan: always register memory hotplug scan handler
ACPI / scan: always register container scan handler
ACPI / scan: Change the meaning of missing .attach() in scan handlers
ACPI / scan: introduce platform_id device PNP type flag
ACPI / scan: drop unsupported serial IDs from PNP ACPI scan handler ID list
ACPI / scan: drop IDs that do not comply with the ACPI PNP ID rule
ACPI / PNP: use device ID list for PNPACPI device enumeration
ACPI / scan: .match() callback for ACPI scan handlers
ACPI / battery: wakeup the system only when necessary
power_supply: allow power supply devices registered w/o wakeup source
...
|
|
* acpi-thermal:
ACPI / thermal: Use acpi_bus_attach_private_data() to attach private data
|
|
* acpi-video:
ACPI / video: Add 4 new models to the use_native_backlight DMI list
ACPI / video: Add use native backlight quirk for the ThinkPad W530
ACPI / video: Unregister the backlight device if a raw one shows up later
backlight: Add backlight device (un)registration notification
nouveau: Don't check acpi_video_backlight_support() before registering backlight
acer-wmi: Add Aspire 5741 to video_vendor_dmi_table
acer-wmi: Switch to acpi_video_unregister_backlight
ACPI / video: Add an acpi_video_unregister_backlight function
ACPI / video: Don't register acpi_video_resume notifier without backlight devices
ACPI / video: change acpi-video brightness_switch_enabled default to 0
|
|
* acpica: (63 commits)
ACPICA: Namespace: Remove _PRP method support.
ACPI: Fix x86 regression related to early mapping size limitation
ACPICA: Tables: Add mechanism to control early table checksum verification.
ACPICA: acpidump: Fix repetitive table dump in -n mode.
ACPI: Clean up acpi_os_map/unmap_memory() to eliminate __iomem.
ACPICA: Clean up redudant definitions already defined elsewhere
ACPICA: Linux headers: Add <asm/acenv.h> to remove mis-ordered inclusion of <asm/acpi.h>
ACPICA: Linux headers: Add <acpi/platform/aclinuxex.h>
ACPICA: Linux headers: Remove ACPI_PREEMPTION_POINT() due to no usages.
ACPICA: Update version to 20140424.
ACPICA: Comment/format update, no functional change.
ACPICA: Events: Update GPE handling and initialization code.
ACPICA: Remove extraneous error message for large number of GPEs.
ACPICA: Tables: Remove old mechanism to validate if XSDT contains NULL entries.
ACPICA: Tables: Add new mechanism to skip NULL entries in RSDT and XSDT.
ACPICA: acpidump: Add support to force using RSDT.
ACPICA: Back port of improvements on exception code.
ACPICA: Back port of _PRP update.
ACPICA: acpidump: Fix truncated RSDP signature validation.
ACPICA: Linux header: Add support for stubbed externals.
...
|
|
* acpi-enumeration:
ACPI / scan: use platform bus type by default for _HID enumeration
ACPI / scan: always register ACPI LPSS scan handler
ACPI / scan: always register memory hotplug scan handler
ACPI / scan: always register container scan handler
ACPI / scan: Change the meaning of missing .attach() in scan handlers
ACPI / scan: introduce platform_id device PNP type flag
ACPI / scan: drop unsupported serial IDs from PNP ACPI scan handler ID list
ACPI / scan: drop IDs that do not comply with the ACPI PNP ID rule
ACPI / PNP: use device ID list for PNPACPI device enumeration
ACPI / scan: .match() callback for ACPI scan handlers
|
|
* acpi-lpss:
ACPI / LPSS: support for fractional divider clock
ACPI / LPSS: custom power domain for LPSS
|
|
* acpi-platform:
ACPI / platform / LPSS: Enable async suspend/resume of LPSS devices
ACPI / platform: add IDs for Broadcom Bluetooth and GPS chips
|
|
* acpi-pm:
ACPI / PM: Export rest of the subsys PM callbacks
ACPI / PM: Avoid resuming devices in ACPI PM domain during system suspend
ACPI / PM: Hold ACPI scan lock over the "freeze" sleep state
ACPI / PM: Export acpi_target_system_state() to modules
|
|
* acpi-battery:
ACPI / battery: wakeup the system only when necessary
power_supply: allow power supply devices registered w/o wakeup source
ACPI / battery: introduce support for POWER_SUPPLY_PROP_CAPACITY_LEVEL
ACPI / battery: Accelerate battery resume callback
|
|
* acpi-tables:
ACPI: Fix conflict between customized DSDT and DSDT local copy
* acpi-general:
ACPI: Add acpi_bus_attach_private_data() to attach data to ACPI handle
|
|
* acpi-processor:
ACPI / processor: Fix STARTING/DYING action in acpi_cpu_soft_notify()
ACPI / processor: Check if LAPIC is present during initialization
ACPI / ia64: introduce variable acpi_lapic into ia64
* acpi-pad:
ACPI / PAD: Use time_before() for time comparison
ACPI / PAD: call schedule() when need_resched() is true
|
|
* acpi-scan:
ACPI / scan: do not scan fixed hardware on HW-reduced platform
* acpi-hotplug:
ACPI: add dynamic_debug support
ACPI / notify: Clean up handling of hotplug events
* acpi-pci:
ACPI / PCI: Stub out pci_acpi_crs_quirks() and make it x86 specific
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl into next
Pull pin control changes from Linus Walleij:
"This is the bulk of pin control changes for the v3.16 development
cycle:
- Antoine Tenart made the get_group_pins() vtable entry optional.
- Antoine also provides an entirely new driver for the Marvell Berlin
SoC. This is unrelated to the existing MVEBU hardware driver and
warrants its own separate driver.
- reflected from the GPIO subsystem there is a number of refactorings
to make pin control drivers with gpiochips use the new gpiolib
irqchip helpers. The following drivers were converted to use the
new infrastructure:
* ST Microelectronics STiH416 and friends
* The Atmel AT91
* The CSR SiRF (Prima2)
* The Qualcomm MSM series
- massive improvements in the Qualcomm MSM driver from Bjorn
Andersson, Andy Gross and Kumar Gala. Among those new support for
the IPQ8064 and MSM8x74 SoC variants.
- support for the Freescale i.MX6 SoloX SoC variant.
- massive improvements in the Allwinner sunxi driver from Boris
Brezillon, Maxime Ripard and Chen-Yu Tsai.
- Renesas PFC updates from Laurent Pinchart, Kuninori Morimoto,
Wolfram Sang and Magnus Damm.
- Cleanups and refactorings of the nVidia Tegra driver from Stepgen
Warren.
- the Exynos driver now supports the Exynos3250 SoC.
- Intel BayTrail updates from Jin Yao, Mika Westerberg.
- the MVEBU driver now supports the Orion5x SoC variants, which is
part of the effort of getting rid of the old Marvell kludges in
arch/arm/mach-orion5x
- Rockchip driver updates from Heiko Stuebner.
- a ton of cleanups and janitorial patches from Axel Lin.
- some minor fixes and improvements here and there"
* tag 'pinctrl-v3.16-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (93 commits)
pinctrl: sirf: fix a bad conflict resolution
pinctrl: msm: Add more MSM8X74 pin definitions
pinctrl: qcom: ipq8064: Fix naming convention
pinctrl: msm: Add missing sdc1 and sdc3 groups
pinctrl: sirf: switch to using allocated state container
pinctrl: Enable "power-source" to be extracted from DT files
pinctrl: sunxi: create irq/pin mapping during init
pinctrl: pinconf-generic: Use kmemdup instead of kmalloc + memcpy
pinctrl: berlin: Use devm_ioremap_resource()
pinctrl: sirf: fix typo for GPIO bank number
pinctrl: sunxi: depend on RESET_CONTROLLER
pinctrl: sunxi: fix pin numbers passed to register offset helpers
pinctrl: add pinctrl driver for imx6sx
pinctrl/at91: Fix lockup when IRQ on PIOC and PIOD occurs
pinctrl: msm: switch to using generic GPIO irqchip helpers
pinctrl: sunxi: Fix multiple registration issue
pinctrl: sunxi: Fix recursive dependency
pinctrl: berlin: add the BG2CD pinctrl driver
pinctrl: berlin: add the BG2 pinctrl driver
pinctrl: berlin: add the BG2Q pinctrl driver
...
|
|
The _PRP method is not going to be a part of the ACPI standard. This patch
removes its support code introduced by the following commits:
1. ACPICA: Predefined names: Add support for the _PRP method.
2. ACPICA: Update for _PRP predefined name.
3. ACPICA: Add support for _LPD and _PRP methods.
4. ACPICA: Back port of _PRP update.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
The following warning message is triggered:
WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:136 __early_ioremap+0x11f/0x1f2()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1-00017-g86dfc6f3-dirty #298
Hardware name: Intel Corporation S2600CP/S2600CP, BIOS SE5C600.86B.99.99.x036.091920111209 09/19/2011
0000000000000009 ffffffff81b75c40 ffffffff817c627b 0000000000000000
ffffffff81b75c78 ffffffff81067b5d 000000000000007b 8000000000000563
00000000b96b20dc 0000000000000001 ffffffffff300e0c ffffffff81b75c88
Call Trace:
[<ffffffff817c627b>] dump_stack+0x45/0x56
[<ffffffff81067b5d>] warn_slowpath_common+0x7d/0xa0
[<ffffffff81067c3a>] warn_slowpath_null+0x1a/0x20
[<ffffffff81d4b9d5>] __early_ioremap+0x11f/0x1f2
[<ffffffff81d4bc5b>] early_ioremap+0x13/0x15
[<ffffffff81d2b8f3>] __acpi_map_table+0x13/0x18
[<ffffffff817b8d1a>] acpi_os_map_memory+0x26/0x14e
[<ffffffff813ff018>] acpi_tb_acquire_table+0x42/0x70
[<ffffffff813ff086>] acpi_tb_validate_table+0x27/0x37
[<ffffffff813ff0e5>] acpi_tb_verify_table+0x22/0xd8
[<ffffffff813ff6a8>] acpi_tb_install_non_fixed_table+0x60/0x1c9
[<ffffffff81d61024>] acpi_tb_parse_root_table+0x218/0x26a
[<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
[<ffffffff81d610cd>] acpi_initialize_tables+0x57/0x59
[<ffffffff81d5f25d>] acpi_table_init+0x1b/0x99
[<ffffffff81d2bca0>] acpi_boot_table_init+0x1e/0x85
[<ffffffff81d23043>] setup_arch+0x99d/0xcc6
[<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
[<ffffffff81d1bbbe>] start_kernel+0x8b/0x415
[<ffffffff81d1b120>] ? early_idt_handlers+0x120/0x120
[<ffffffff81d1b5ee>] x86_64_start_reservations+0x2a/0x2c
[<ffffffff81d1b72e>] x86_64_start_kernel+0x13e/0x14d
---[ end trace 11ae599a1898f4e7 ]---
when installing the following table during early stage:
ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL S2600CP 00004000 INTL 20100331)
The regression is caused by the size limitation of the x86 early IO mapping.
The root cause is:
1. ACPICA doesn't split IO memory mapping and table mapping;
2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
mechanism during early boot stage, which is more suitable for only IO
mappings.
This patch fixes this issue by utilizing acpi_gbl_verify_table_checksum to
disable the table mapping during early stage and enabling it again for the
late stage. In this way, the normal code path is not affected. Then after
the code related to the root cause is cleaned up, the early checksum
verification can be easily re-enabled.
A new boot parameter - acpi_force_table_verification is introduced for
the platforms that require the checksum verification to stop loading bad
tables.
This fix also covers the checksum verification for the table overrides. Now
large tables can also be overridden using the initrd override mechanism.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reported-and-tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
It is reported that Linux x86 kernel cannot map large tables. The following
large SSDT table on such platform fails to pass checksum verification and
cannot be installed:
ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL S2600CP 00004000 INTL 20100331)
It sounds strange that in the 64-bit virtual memory address space, we
cannot map a single ACPI table to do checksum verification. The root cause
is:
1. ACPICA doesn't split IO memory mapping and table mapping;
2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map
mechanism during early boot stage, which is more suitable for only IO
mappings.
ACPICA originally only mapped table header for signature validation, and
this header mapping is required by OSL override mechanism. There was no
checksum verification because we could not map the whole table using this
OSL. While the following ACPICA commit enforces checksum verification by
mapping the whole table during Linux boot stage and it finally triggers
this issue on some platforms:
Commit: 86dfc6f339886559d80ee0d4bd20fe5ee90450f0
Subject: ACPICA: Tables: Fix table checksums verification before installation.
Before doing further cleanups for the OSL table mapping and override
implementation, this patch introduces an option for such OSPMs to
temporarily discard the checksum verification feature. It then can be
re-enabled easily when the ACPICA and the underlying OSL is ready.
This patch also deletes a comment around the limitation of mappings because
it is not correct. The limitation is not how many times we can map in the
early stage, but the OSL mapping facility may not be suitable for mapping
the ACPI tables and thus may complain us the size limitation.
The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the
work around added, it now only applies to the table descriptor that hasn't
been installed and cannot be used in other cases. Lv Zheng.
Tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Because of the growing demand for enumerating ACPI devices to
platform bus, change the code to enumerate ACPI device objects to
platform bus by default. Namely, create platform devices for the
ACPI device objects that
1. Have pnp.type.platform_id set (device objects with _HID currently).
2. Do not have a scan handler attached.
3. Are not SPI/I2C slave devices (that should be enumerated to the
appropriate buses bus by their parent).
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
[rjw: Subject and changelog, rebase and code cleanup]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Prevent platform devices from being created for ACPI LPSS devices
if CONFIG_X86_INTEL_LPSS is unset by compiling out the LPSS scan
handler's callbacks only in that case and still compiling its device
ID list in and registering the scan handler in either case.
This change is based on a prototype from Zhang Rui.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Prevent platform devices from being created for ACPI memory device
objects if CONFIG_ACPI_HOTPLUG_MEMORY is unset by compiling out the
memory hotplug scan handler's callbacks only in that case and still
compiling its device ID list in and registering the scan handler in
either case.
Also unset the memory hotplug scan handler's .attach() callback
if acpi_no_memhotplug is set, but still register the scan handler to
avoid creating platform devices for ACPI memory devices in that case
too.
This change is based on a prototype from Zhang Rui.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Prevent platform devices from being created for ACPI containers
if CONFIG_ACPI_CONTAINER is unset by compiling out the container
scan handler's callbacks only in that case and still compiling
its device ID list in and registering the scan handler in either
case.
This change is based on a prototype from Zhang Rui.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Currently, some scan handlers can be compiled out entirely, which
leaves the device objects they normally attach to without a scan
handler. This isn't a problem as long as we don't have any default
enumeration mechanism that applies to all devices without a scan
handler. However, if such a default enumeration is added, it still
should not be applied to devices that are normally attached to by
scan handlers, because that may result in creating "physical" device
objects of a wrong type for them.
Since we are going to create platform device objects for all ACPI
device objects with pnp.type.platform_id set by default, clear
pnp.type.platform_id where there is a matching scan handler without
an .attach() callback and otherwise simply treat that scan handler
as though the .attach() callback was present but always returned 0.
This will allow us to compile out scan handler callbacks and leave
the device ID lists used by them so as to prevent creating platform
device objects for the matching ACPI devices.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
|
Only certain types of ACPI device objects can be enumerated as
platform devices, so in order to distinguish them from the others
introduce a new ACPI device PNP type flag, platform_id, and set it
for devices with a valid _HID to start with.
This change is based on a Zhang Rui's prototype.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
|
