This just caused build errors:
warning: (QCOM_SPMI_TEMP_ALARM) selects REGMAP_SPMI which has unmet direct dependencies (SPMI)
drivers/built-in.o: In function `regmap_spmi_ext_gather_write':
:(.text+0x609b0): undefined reference to `spmi_ext_register_write'
:(.text+0x609f0): undefined reference to `spmi_ext_register_writel'
While it's generally a good idea to allow compile testing, in this
case, it just doesn't work, so reverting the patch that
introduced the compile-test variant seems the most appropriate
solution.
Note that SPMI also has a 'depends on ARCH_QCOM || COMPILE_TEST'
statement, so we should be able to enable SPMI on all architectures
for compile testing already.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: cb7fb4d342 ("thermal: qcom_spmi: allow compile test")
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add a generic thermal cooling device for devfreq, that is similar to
cpu_cooling.
The device must use devfreq. In order to use the power extension of the
cooling device, it must have registered its OPPs using the OPP library.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Ørjan Eide <orjan.eide@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
After the commit "thermal: core: Add Kconfig option to enable writable
trips", by default the trips are read only. This cause user space thermal
controllers to poll for temperature as they can't set temperature
thresholds for getting a notification via uevents. These programs use RW
trip in a zone to register thresholds. Since we need to enable the new
config introduced by above commit to allow writable trips, selecting
CONFIG_THERMAL_WRITABLE_TRIP for x86 thermal drivers.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
This change adds a thermal driver for Wildcat Point platform controller
hub. This driver register PCH thermal sensor as a thermal zone and
associate critical and hot trips if present.
Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
Reviewed-by: Pandruvada, Srinivas <srinivas.pandruvada@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This patch adds the support for hisilicon thermal sensor, within
hisilicon SoC. there will register sensors for thermal framework
and use device tree to bind cooling device.
Signed-off-by: Leo Yan <leo.yan@linaro.org>
Signed-off-by: kongxinwei <kong.kongxinwei@hisilicon.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
A previous version of this patch had a config for THERMAL_POWER_ACTOR
but it was dropped. Remove the select as it is not doing anything.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Reported-by: Valentin Rothberg <valentinrothberg@gmail.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add a Kconfig option to allow system integrators to control whether
userspace tools can change trip temperatures. This option overrides
the thermal zone setup in the driver code and must be enabled for
platform specified writable trips to come into effect.
The original behaviour of requiring root privileges to change trip
temperatures remains unchanged.
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
The power allocator governor is a thermal governor that controls system
and device power allocation to control temperature. Conceptually, the
implementation divides the sustainable power of a thermal zone among
all the heat sources in that zone.
This governor relies on "power actors", entities that represent heat
sources. They can report current and maximum power consumption and
can set a given maximum power consumption, usually via a cooling
device.
The governor uses a Proportional Integral Derivative (PID) controller
driven by the temperature of the thermal zone. The output of the
controller is a power budget that is then allocated to each power
actor that can have bearing on the temperature we are trying to
control. It decides how much power to give each cooling device based
on the performance they are requesting. The PID controller ensures
that the total power budget does not exceed the control temperature.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Add support for the temperature alarm peripheral found inside
Qualcomm plug-and-play (QPNP) PMIC chips. The temperature alarm
peripheral outputs a pulse on an interrupt line whenever the
thermal over temperature stage value changes.
Register a thermal sensor. The temperature reported by this thermal
sensor device should reflect the actual PMIC die temperature if an
ADC is present on the given PMIC. If no ADC is present, then the
reported temperature should be estimated from the over temperature
stage value.
Cc: David Collins <collinsd@codeaurora.org>
Signed-off-by: Ivan T. Ivanov <iivanov@mm-sol.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
In Intel Quark SoC X1000, there is one on-die digital temperature sensor(DTS).
The DTS offers both hot & critical trip points.
However, in current distribution of UEFI BIOS for Quark platform, only
critical trip point is configured to be 105 degree Celsius (based on Quark
SW ver1.0.1 and hot trip point is not used due to lack of IRQ.
There is no active cooling device for Quark SoC, so Quark SoC thermal
management logic expects Linux distro to orderly power-off when temperature
of the DTS exceeds the configured critical trip point.
Kernel param "polling_delay" in milliseconds is used to control the frequency
the DTS temperature is read by thermal framework. It defaults to 2-second.
To change it, use kernel boot param "intel_quark_dts_thermal.polling_delay=X".
User interacts with Quark SoC DTS thermal driver through sysfs via:
/sys/class/thermal/thermal_zone0/
For example:
- to read DTS temperature
$ cat temp
- to read critical trip point
$ cat trip_point_0_temp
- to read trip point type
$ cat trip_point_0_type
- to emulate temperature raise to test orderly shutdown by Linux distro
$ echo 105 > emul_temp
Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Signed-off-by: Ong Boon Leong <boon.leong.ong@intel.com>
Reviewed-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Reviewed-by: Kweh, Hock Leong <hock.leong.kweh@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Support two auxiliary DTS present on Braswell platform using side band
IOSF interface. This supports two read write trips, which can be used
to get notification on trip violation.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
There is no change in functionality but using the common IOSF core APIs.
This driver is now just responsible for enumeration and call relevant
API to create thermal zone and register critical trip.
Also cpuid 0x4c is now handled in the int340x processor thermal driver
with the same functionality.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
This is becoming a common feature for Intel SoCs to expose the additional
digital temperature sensors (DTSs) using side band interface (IOSF). This
change remove common IOSF DTS handler function from the existing driver
intel_soc_dts_thermal.c and creates a stand alone module, which can
be selected from the SoC specific drivers. In this way there is less
code duplication.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Thermal is TS-ADC Controller module supports
user-defined mode and automatic mode.
User-defined mode refers,TSADC all the control signals entirely by
software writing to register for direct control.
Automaic mode refers to the module automatically poll TSADC output,
and the results were checked.If you find that the temperature High
in a period of time,an interrupt is generated to the processor
down-measures taken;If the temperature over a period of time High,
the resulting TSHUT gave CRU module,let it reset the entire chip,
or via GPIO give PMIC.
Signed-off-by: zhaoyifeng <zyf@rock-chips.com>
Signed-off-by: Caesar Wang <caesar.wang@rock-chips.com>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This adds support for the Tegra SOCTHERM thermal sensing and management
system found in the Tegra124 system-on-chip. This initial driver supports
temperature polling for four thermal zones.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
This patch introduces a new thermal cooling device based on common clock
framework. The original motivation to write this cooling device is to be
able to cool down thermal zones using clocks that feed co-processors, such
as GPUs, DSPs, Image Processing Co-processors, etc. But it is written
in a way that it can be used on top of any clock.
The implementation is pretty straight forward. The code creates
a thermal cooling device based on a pair of a struct device and a clock name.
The struct device is assumed to be usable by the OPP layer. The OPP layer
is used as source of the list of possible frequencies. The (cpufreq) frequency
table is then used as a map from frequencies to cooling states. Cooling
states are indexes to the frequency table.
The logic sits on top of common clock framework, specifically on clock
pre notifications. Any PRE_RATE_CHANGE is hijacked, and the transition is
only allowed when the new rate is within the thermal limit (cooling state -> freq).
When a thermal cooling device state transition is requested, the clock
is also checked to verify if the current clock rate is within the new
thermal limit.
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Mike Turquette <mturquette@linaro.org>
Cc: Nishanth Menon <nm@ti.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Len Brown <len.brown@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
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
...
we share the same driver for both ACPI predefined Fan device
and INT3404 Fan device, thus we should select the ACPI Fan
driver when int340x thermal drivers are enabeld.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ACPI 4.0 introduced two thermal relationship tables via _ART
(active cooling) and _TRT (passive cooling) objects. These
tables contain many to many relationships among thermal sensors
and cooling devices.
This patch parses _ART and _TRT and makes the result available to
the userspace via an misc device interface. At the same time,
kernel drivers can also request parsing results from internal
kernel APIs.
The results include source and target devices, influence, and
sampling rate in case of _TRT. For _ART, the result shows source
device, target device, and weight percentage.
Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
ACPI INT3403 device object can be used to retrieve temperature date
from temperature sensors present in the system, and to expose
device' performance control.
The previous INT3403 thermal driver supports temperature reporting only,
thus remove it and introduce this new & enhanced one.
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Introduce int3400 thermal driver. And make INT3400 driver
enumerate the other int340x thermal components shown in _ART/_TRT.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Newer laptops and tablets that use ACPI may have thermal sensors and
other devices with thermal control capabilities outside the core CPU/SOC,
for thermal safety reasons.
They are exposed for the OS to use via
1) INT3400 ACPI device object as the master.
2) INT3401 ~ INT340B ACPI device objects as the slaves.
This patch introduces a scan handler to enumerate the INT3400
ACPI device object to platform bus, and prevent its slaves
from being enumerated before the controller driver being probed.
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
mach-kirkwood has been removed, now that kirkwood lives in mach-mvebu.
Depend on MACH_KIRKWOOD, which will be set when kirkwood is built as
part of ARCH_MVEBU.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: linux-pm@vger.kernel.org
Acked-by: Eduardo Valentin <edubezval@gmail.com>
Link: https://lkml.kernel.org/r/1409417172-6846-4-git-send-email-andrew@lunn.ch
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
The bang-bang thermal governor uses a hysteresis to switch abruptly on
or off a cooling device. It is intended to control fans, which can
not be throttled but just switched on or off.
Bang-bang cannot be set as default governor as it is intended for
special devices only. For those special devices the driver needs to
explicitely request it.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Andreas Mohr <andi@lisas.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Javi Merino <javi.merino@arm.com>
Cc: linux-pm@vger.kernel.org
Signed-off-by: Peter Feuerer <peter@piie.net>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
DT-enabled Dove has moved from ARCH_DOVE in mach-dove to MACH_DOVE
in mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new
DT-only MACH_DOVE to thermal Kconfig.
This was originally supposed to go in via "ARM: dove: prepare new Dove DT Kconfig"
patch from Sebastian Hesselbarth for 3.15, but slipped through the cracks.
I've tested on CuBox that without this patch you can't compile
dove_thermal into a mach-mvebu based kernel, and with this patch I can
build the driver and it works as expected run-time.
v2: non-ascii char creeped in somehow
Signed-off-by: Riku Voipio <riku.voipio@linaro.org>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
This core is shared by both ST's 'memory mapped' and
'system configuration register' based Thermal controllers.
Signed-off-by: Ajit Pal Singh <ajitpal.singh@st.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
In the Intel SoCs like Bay Trail, there are 2 additional digital temperature
sensors(DTS), in addition to the standard DTSs in the core. Also they support
4 programmable thresholds, out of which two can be used by OSPM. These
thresholds can be used by OSPM thermal control. Out of these two thresholds,
one is used by driver and one user mode can change via thermal sysfs to get
notifications on threshold violations.
The driver defines one critical trip points, which is set to TJ MAX - offset.
The offset can be changed via module parameter (default 5C). Also it uses
one of the thresholds to get notification for this temperature violation.
This is very important for orderly shutdown as the many of these devices don't
have ACPI thermal zone, and expects that there is some other thermal control
mechanism present in OSPM. When a Linux distro is used without additional
specialized thermal control program, BIOS can do force shutdown when thermals
are not under control. When temperature reaches critical, the Linux thermal
core will initiate an orderly shutdown.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Menu for Samsung thermal support is visible on all Samsung
platforms while thermal drivers are currently available only
for EXYNOS SoCs. Fix it by replacing PLAT_SAMSUNG dependency
with ARCH_EXYNOS one.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
These changes are mostly for ARM specific device drivers that either
don't have an upstream maintainer, or that had the maintainer ask
us to pick up the changes to avoid conflicts. A large chunk of this
are clock drivers (bcm281xx, exynos, versatile, shmobile), aside from
that, reset controllers for STi as well as a large rework of the
Marvell Orion/EBU watchdog driver are notable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUz/1+GCrR//JCVInAQJmfg/9GyqHatDjjUPUBjUQRIEtKgGdmQwdbDqF
x+OrS/q5B5zYbpIWkbkt1IUYJfU+89Z5ev9jxI4rV824Nu9Y92mHPDnv+N/ptkIh
q2OVP3bQDpWs3aEVV2B1HBNcWrNUuwco9BJu05eegEePii/cto0/wKwWIgUmrmjy
xOLthsnp2YmeplGs7ctC6Dz8XbmELebpawejTGylARXei/SwmzB/YYDgJbYjRL2I
WSCVa8Vo+MZaGC/yxdKVTtvsKVQenxGoMO3ojikJeRdvuVRJds48Cw+UBdzWYNeJ
3Ssvbdx6Xltf9jy/7H0btOUgxPetZuUV+2XpbWfGu0Zr9FcGDv3q9hrxA+UYKnkY
GIGU0otSsmpHnX5Ms3E2xnHiV/fihxA3qohqts5kYRBDr5uc+IpW6SbDymQliCGG
OO4XmIVM3pmsqAqP3Zuseemt9CeSW2yC0XlfXkzjO74yY39c+WLBbtGI40Z5W6i0
mM1C8RD3QSNijYCEC8eqz06BQfRImsPs+jllsnJTZaHfbOsib718uvandjfG26lN
616YMcqq0Sp51HIQ4qW7f2dQr7vOyNqbukdkrwF5JgkY/nVki5kdciRg/yeipRy6
Ey80a+OTq0GQljM0F2dcH/A1eHH9KsuI1L6NdSMJsl0h6guIBORPTwTw3qJ13OkR
wpJyM+Gm+Fk=
=u/FI
-----END PGP SIGNATURE-----
Merge tag 'drivers-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver changes from Arnd Bergmann:
"These changes are mostly for ARM specific device drivers that either
don't have an upstream maintainer, or that had the maintainer ask us
to pick up the changes to avoid conflicts.
A large chunk of this are clock drivers (bcm281xx, exynos, versatile,
shmobile), aside from that, reset controllers for STi as well as a
large rework of the Marvell Orion/EBU watchdog driver are notable"
* tag 'drivers-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (99 commits)
Revert "dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac."
Revert "net: stmmac: Add SOCFPGA glue driver"
ARM: shmobile: r8a7791: Fix SCIFA3-5 clocks
ARM: STi: Add reset controller support to mach-sti Kconfig
drivers: reset: stih416: add softreset controller
drivers: reset: stih415: add softreset controller
drivers: reset: Reset controller driver for STiH416
drivers: reset: Reset controller driver for STiH415
drivers: reset: STi SoC system configuration reset controller support
dts: socfpga: Add sysmgr node so the gmac can use to reference
dts: socfpga: Add support for SD/MMC on the SOCFPGA platform
reset: Add optional resets and stubs
ARM: shmobile: r7s72100: fix bus clock calculation
Power: Reset: Generalize qnap-poweroff to work on Synology devices.
dts: socfpga: Update clock entry to support multiple parents
ARM: socfpga: Update socfpga_defconfig
dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac.
net: stmmac: Add SOCFPGA glue driver
watchdog: orion_wdt: Use %pa to print 'phys_addr_t'
drivers: cci: Export CCI PMU revision
...
Commit beeb5a1e (thermal: rcar-thermal: Enable driver compilation with COMPILE_TEST)
broke build on archs wihout io memory.
On archs like S390 or um this driver cannot build nor work.
Make it depend on HAS_IOMEM to bypass build failures.
drivers/thermal/rcar_thermal.c:404: undefined reference to `devm_ioremap_resource'
drivers/thermal/rcar_thermal.c:426: undefined reference to `devm_ioremap_resource'
Signed-off-by: Richard Weinberger <richard@nod.at>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
With the move of kirkwood into mach-mvebu, drivers Kconfig need
tweeking to allow the kirkwood specific drivers to be built.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Brown <broonie@linaro.org>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Bryan Wu <cooloney@gmail.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Arnd Bergmann