linux-toradex.git/drivers/acpi/fan.c, branch v4.9.66 Linux kernel for Apalis and Colibri modules ACPI / fan: Fix error reading cur_state 2016-10-10T00:20:43+00:00 Srinivas Pandruvada srinivas.pandruvada@linux.intel.com 2016-10-04T20:51:40+00:00 84baf1725dc532d9746df2d216c1921154767109 On some platforms with ACPI4 variable speed fan, reading cur_state from cooling device returns "invalid value" error. This confuses user space applications. This issue occurs as the current driver doesn't take account of "FineGrainControl" from _FIF(Fan Information). When the "FineGrainControl" is set, _FSL(FSL Set Level) takes argument as a percent, which doesn't have to match from any control value from _FPS(Fan Performance States). It is also possible that the Fan is not actually running at the requested speed returning a lower speed. On some platforms the BIOS is setting fan speed to a level during boot, which will not have an exact match to _FPS control values. The current implementation will treat this level as invalid value. The simple change is to atleast return state corresponding to a maximum control value in the _FPS compared to the current level. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
On some platforms with ACPI4 variable speed fan, reading cur_state from
cooling device returns "invalid value" error. This confuses user space
applications.

This issue occurs as the current driver doesn't take account of
"FineGrainControl" from _FIF(Fan Information). When the "FineGrainControl"
is set, _FSL(FSL Set Level) takes argument as a percent, which doesn't
have to match from any control value from _FPS(Fan Performance States).
It is also possible that the Fan is not actually running at the requested
speed returning a lower speed.
On some platforms the BIOS is setting fan speed to a level during boot,
which will not have an exact match to _FPS control values. The current
implementation will treat this level as invalid value.

The simple change is to atleast return state corresponding to a maximum
control value in the _FPS compared to the current level.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / fan: Make struct dev_pm_ops const 2016-03-09T22:23:21+00:00 Kaiyen Chang kaiyen.chang@intel.com 2016-02-10T23:23:27+00:00 1d751584e00b2538fe15a615fdad2a60a5a90a4e Silence the following checkpatch warning: WARNING: struct dev_pm_ops should normally be const. Signed-off-by: Kaiyen Chang <kaiyen.chang@intel.com> Signed-off-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
Silence the following checkpatch warning:
WARNING: struct dev_pm_ops should normally be const.

Signed-off-by: Kaiyen Chang <kaiyen.chang@intel.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / fan: Improve acpi_device_update_power error message 2016-01-15T21:00:08+00:00 Andy Lutomirski luto@kernel.org 2016-01-13T22:25:19+00:00 f9727999694f76d329738614f2fd61d800509319 On my laptop, I see "Setting initial power state" on boot. It's a firmware bug on my laptop, but the message made me think that the initial power state was bogus and the driver fixed it. The error actually means that the driver failed to set the initial power state. Fix the message. Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
On my laptop, I see "Setting initial power state" on boot.  It's a
firmware bug on my laptop, but the message made me think that the
initial power state was bogus and the driver fixed it.  The error
actually means that the driver failed to set the initial power
state.  Fix the message.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI: Remove FSF mailing addresses 2015-07-08T00:27:32+00:00 Jarkko Nikula jarkko.nikula@linux.intel.com 2015-06-26T08:27:41+00:00 4c62dbbce902cf2afa88cac89ec67c828160f431 There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
There is no need to carry potentially outdated Free Software Foundation
mailing address in file headers since the COPYING file includes it.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / PM: Rework device power management to follow ACPI 6 2015-05-15T23:55:35+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2015-05-15T23:55:35+00:00 20dacb71ad283b9506ee7e01286a424999fb8309 The ACPI 6 specification has made some changes in the device power management area. In particular: * The D3hot power state is now supposed to be always available (instead of D3cold) and D3cold is only regarded as valid if the _PR3 object is present for the given device. * The required ordering of transitions into power states deeper than D0 is now such that for a transition into state Dx the _PSx method is supposed to be executed first, if present, and the states of the power resources the device depends on are supposed to be changed after that. * It is now explicitly forbidden to transition devices from lower-power (deeper) into higher-power (shallower) power states other than D0. Those changes have been made so the specification reflects the Windows' device power management code that the vast majority of systems using ACPI is validated against. To avoid artificial differences in ACPI device power management between Windows and Linux, modify the ACPI device power management code to follow the new specification. Add comments explaining the code flow in some unclear places. This only may affect some real corner cases in which the OS behavior expected by the firmware is different from the Windows one, but that's quite unlikely. The transition ordering change affects transitions to D1 and D2 which are rarely used (if at all) and into D3hot and D3cold for devices actually having _PR3, but those are likely to be validated against Windows anyway. The other changes may affect code calling acpi_device_get_power() or acpi_device_update_power() where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD (that's why the ACPI fan driver needs to be updated too) and since transitions into ACPI_STATE_D3_HOT may remove power now, it is better to avoid this one in acpi_pm_device_sleep_state() if the "no power off" PM QoS flag is set. The only existing user of acpi_device_can_poweroff() really cares about the case when _PR3 is present, so the change in that function should not cause any problems to happen too. A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT now and the compatibility with older systems should be covered automatically. In any case, if any real problems result from this, it still will be better to follow the Windows' behavior (which now is reflected by the specification too) in general and handle the cases when it doesn't work via quirks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
The ACPI 6 specification has made some changes in the device power
management area.  In particular:

 * The D3hot power state is now supposed to be always available
   (instead of D3cold) and D3cold is only regarded as valid if the
   _PR3 object is present for the given device.

 * The required ordering of transitions into power states deeper than
   D0 is now such that for a transition into state Dx the _PSx method
   is supposed to be executed first, if present, and the states of
   the power resources the device depends on are supposed to be
   changed after that.

 * It is now explicitly forbidden to transition devices from
   lower-power (deeper) into higher-power (shallower) power states
   other than D0.

Those changes have been made so the specification reflects the
Windows' device power management code that the vast majority of
systems using ACPI is validated against.

To avoid artificial differences in ACPI device power management
between Windows and Linux, modify the ACPI device power management
code to follow the new specification.  Add comments explaining the
code flow in some unclear places.

This only may affect some real corner cases in which the OS behavior
expected by the firmware is different from the Windows one, but that's
quite unlikely.  The transition ordering change affects transitions
to D1 and D2 which are rarely used (if at all) and into D3hot and
D3cold for devices actually having _PR3, but those are likely to
be validated against Windows anyway.  The other changes may affect
code calling acpi_device_get_power() or acpi_device_update_power()
where ACPI_STATE_D3_HOT may be returned instead of ACPI_STATE_D3_COLD
(that's why the ACPI fan driver needs to be updated too) and since
transitions into ACPI_STATE_D3_HOT may remove power now, it is better
to avoid this one in acpi_pm_device_sleep_state() if the "no power
off" PM QoS flag is set.

The only existing user of acpi_device_can_poweroff() really cares
about the case when _PR3 is present, so the change in that function
should not cause any problems to happen too.

A plus is that PCI_D3hot can be mapped to ACPI_STATE_D3_HOT
now and the compatibility with older systems should be covered
automatically.

In any case, if any real problems result from this, it still will
be better to follow the Windows' behavior (which now is reflected
by the specification too) in general and handle the cases when it
doesn't work via quirks.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPI / Fan: Use bus id as the name for non PNP0C0B (Fan) devices 2014-12-10T23:29:02+00:00 Srinivas Pandruvada srinivas.pandruvada@linux.intel.com 2014-12-10T00:15:40+00:00 bbb16fef19122ec9f20fb865c45375e12f85d2a1 The _ART (Active Cooling Relationship Table), specifies relationship among heat generating sources to a target active cooling device like fan. The _ART table refers to actual bus id name for specifying relationship. Naming "Fan" is not enough as name in the _ART table can change on every platform, to establish relationship for user space thermal controllers. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 
The _ART (Active Cooling Relationship Table), specifies relationship
among heat generating sources to a target active cooling device like
fan. The _ART table refers to actual bus id name for specifying relationship.
Naming "Fan" is not enough as name in the _ART table can change on every
platform, to establish relationship for user space thermal controllers.

Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux 2014-10-24T18:21:43+00:00 Linus Torvalds torvalds@linux-foundation.org 2014-10-24T18:21:43+00:00 8264fce6de03f3915e2301f52f181a982718a8cb Pull thermal management updates from Zhang Rui: "Sorry that I missed the merge window as there is a bug found in the last minute, and I have to fix it and wait for the code to be tested in linux-next tree for a few days. Now the buggy patch has been dropped entirely from my next branch. Thus I hope those changes can still be merged in 3.18-rc2 as most of them are platform thermal driver changes. Specifics: - introduce ACPI INT340X thermal drivers. Newer laptops and tablets may have thermal sensors and other devices with thermal control capabilities that are exposed for the OS to use via the ACPI INT340x device objects. Several drivers are introduced to expose the temperature information and cooling ability from these objects to user-space via the normal thermal framework. From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui. - introduce a new thermal governor, which just uses a hysteresis to switch abruptly on/off a cooling device. This governor can be used to control certain fan devices that can not be throttled but just switched on or off. From: Peter Feuerer. - introduce support for some new thermal interrupt functions on i.MX6SX, in IMX thermal driver. From: Anson, Huang. - introduce tracing support on thermal framework. From: Punit Agrawal. - small fixes in OF thermal and thermal step_wise governor" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits) Thermal: int340x thermal: select ACPI fan driver Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs Thermal: int340x_thermal: expose acpi thermal relationship tables Thermal: introduce int3403 thermal driver Thermal: introduce INT3402 thermal driver Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h ACPI / Fan: support INT3404 thermal device ACPI / Fan: add ACPI 4.0 style fan support ACPI / fan: convert to platform driver ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant ACPI / fan: remove no need check for device pointer ACPI / fan: remove unused macro Thermal: int3400 thermal: register to thermal framework Thermal: int3400 thermal: add capability to detect supporting UUIDs Thermal: introduce int3400 thermal driver ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package() ACPI: make acpi_create_platform_device() an external API thermal: step_wise: fix: Prevent from binary overflow when trend is dropping ACPI: introduce ACPI int340x thermal scan handler thermal: Added Bang-bang thermal governor ... 
Pull thermal management updates from Zhang Rui:
 "Sorry that I missed the merge window as there is a bug found in the
  last minute, and I have to fix it and wait for the code to be tested
  in linux-next tree for a few days.  Now the buggy patch has been
  dropped entirely from my next branch.  Thus I hope those changes can
  still be merged in 3.18-rc2 as most of them are platform thermal
  driver changes.

  Specifics:

   - introduce ACPI INT340X thermal drivers.

     Newer laptops and tablets may have thermal sensors and other
     devices with thermal control capabilities that are exposed for the
     OS to use via the ACPI INT340x device objects.  Several drivers are
     introduced to expose the temperature information and cooling
     ability from these objects to user-space via the normal thermal
     framework.

     From: Lu Aaron, Lan Tianyu, Jacob Pan and Zhang Rui.

   - introduce a new thermal governor, which just uses a hysteresis to
     switch abruptly on/off a cooling device.  This governor can be used
     to control certain fan devices that can not be throttled but just
     switched on or off.  From: Peter Feuerer.

   - introduce support for some new thermal interrupt functions on
     i.MX6SX, in IMX thermal driver.  From: Anson, Huang.

   - introduce tracing support on thermal framework.  From: Punit
     Agrawal.

   - small fixes in OF thermal and thermal step_wise governor"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: (25 commits)
  Thermal: int340x thermal: select ACPI fan driver
  Thermal: int3400_thermal: use acpi_thermal_rel parsing APIs
  Thermal: int340x_thermal: expose acpi thermal relationship tables
  Thermal: introduce int3403 thermal driver
  Thermal: introduce INT3402 thermal driver
  Thermal: move the KELVIN_TO_MILLICELSIUS macro to thermal.h
  ACPI / Fan: support INT3404 thermal device
  ACPI / Fan: add ACPI 4.0 style fan support
  ACPI / fan: convert to platform driver
  ACPI / fan: use acpi_device_xxx_power instead of acpi_bus equivelant
  ACPI / fan: remove no need check for device pointer
  ACPI / fan: remove unused macro
  Thermal: int3400 thermal: register to thermal framework
  Thermal: int3400 thermal: add capability to detect supporting UUIDs
  Thermal: introduce int3400 thermal driver
  ACPI: add ACPI_TYPE_LOCAL_REFERENCE support to acpi_extract_package()
  ACPI: make acpi_create_platform_device() an external API
  thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
  ACPI: introduce ACPI int340x thermal scan handler
  thermal: Added Bang-bang thermal governor
  ...
ACPI / Fan: support INT3404 thermal device 2014-10-10T05:57:14+00:00 Aaron Lu aaron.lu@intel.com 2014-04-01T07:54:05+00:00 d806c6e9cdfd6c5663687ec7109e151c0ff66639 INT3404 ACPI object follows the ACPI 5.0 fan object definition as described in section 11.3 of the ACPI 5.0 Specification. Thus we can reuse the ACPI fan driver for INT3404 ACPI object. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> 
INT3404 ACPI object follows the ACPI 5.0 fan object definition as
described in section 11.3 of the ACPI 5.0 Specification.
Thus we can reuse the ACPI fan driver for INT3404 ACPI object.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ACPI / Fan: add ACPI 4.0 style fan support 2014-10-10T05:57:13+00:00 Aaron Lu aaron.lu@intel.com 2014-04-01T07:50:27+00:00 9519a6356cbf63b1f22a7a208385dc56092c8b7d This patch adds support for ACPI 4.0 style fan, lacking part is: no support for 'Low Speed Notification Support', 'Fine Grain Control' is not used yet. It's not clear what to do on suspend/resume callback for 4.0 style ACPI fan, so it does nothing for now. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> 
This patch adds support for ACPI 4.0 style fan, lacking part is: no
support for 'Low Speed Notification Support', 'Fine Grain Control' is
not used yet.

It's not clear what to do on suspend/resume callback for 4.0 style ACPI
fan, so it does nothing for now.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ACPI / fan: convert to platform driver 2014-10-10T05:57:13+00:00 Aaron Lu aaron.lu@intel.com 2013-11-19T08:59:20+00:00 19593a1fb1f6718406afca5b867dab184289d406 Convert ACPI fan driver to a platform driver for the purpose of phasing out ACPI bus. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> 
Convert ACPI fan driver to a platform driver for the purpose of phasing
out ACPI bus.

Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>