Hi, On 17-07-2013 11:02, Eduardo Valentin wrote: > Hello all, > Looks like I sent duplicated series. Please consider the series containing 9 patches. I will resend with proper set. > As you noticed, I am working in a way to represent thermal data > using device tree [1]. Essentially, this should be a way to say > what to do with a sensor and how to associate (cooling) actions > with it. > > The motivation to create such infrastructure is: > (i) - to reuse the existing temperature sensor code base; > (ii) - have a way to easily describe thermal data across different > boards for the same sensor. Say you have an i2c temp sensor, > which is placed close to your battery on board A but on > board B, another instance of this same senor is placed > close to your display, for instance. > > This series introduces then a DT parser. The data expected in > DT must contain the needed properties to build a thermal zone > out of the desired sensor. All properties are documented and > they are derived from the existing requirements of current > thermal API. > > In order to perform a binding with cooling devices, > the new thermal zone built using DT nodes will use > the existing thermal API that uses binding parameters. This is > the current proposed way to register thermal zones with platform > information, written by Durga. > > There are some virtual concepts that are pushed to device tree, > I know. But I believe using device tree to do this makes sense > because we are still describing the HW and how they are related > to each other. Things like cooling devices are not represented > in device tree though, as I believe that will cause a lot of > confusion with real devices (as already does). > > So the series is short but I think it makes sense to describe > how it is organized, as it touches several places. First four > patches are a preparation for this parser. There is a change > on cpufreq-cpu0, so that it knows now how to load its > corresponding cooling device. There is a change on thermal_core > to split its hwmon code, because I think we may need to improve > this code base when we start to integrate better with hwmon > temperature sensors. Then, another needed preparation is to > improve the bind_params, so that we are able to bind with > upper and lower limits. The remaining patches are the changes > with the proposed DT parser. A part from the DT thermal zone > builder itself (patch 05), I also changed the ti-soc-thermal > driver to use this new API and the omap4430 bandgap DT node, > as an example (this has been tested on panda omap4430); and also changed > the hwmon drivers lm75 and tmp102 to have the option to build > a thermal zone using DT. I haven't touched any dts file using > lm75 or tmp102 because this should come on a need basis. > > I believe this code is pretty usable the way it is, but might > need to be revisited, in case the enhancement proposed by Durga > get in. This is because representing virtual thermal zones > built out of several sensors may need a different representation > in DT. > > [1] - RFC of this work: > http://comments.gmane.org/gmane.linux.power-management.general/35874 > > Changes from RFC: > - Added a way to load cpufreq cooling device out of DT > - Added a way to bind with upper and lower limits using bind_params > - Added a way to specify upper and lower binding limits on DT > - Added DT thermal builder support to lm75 and tmp102 hwmon drivers > - Changed ERANGE to EDOM > - Added thermal constants for zone type and bind limit, so that > dts file could be more readable > > Tested on panda omap4430 (3.11-rc1 with minor changes for getting cpufreq working) > > BR, > > Eduardo Valentin (9): > cpufreq: cpufreq-cpu0: add dt node parsing for 'needs-cooling' > thermal: hwmon: move hwmon support to single file > thermal: thermal_core: allow binding with limits on bind_params > arm: dts: flag omap4430 with needs-cooling for cpu node > thermal: introduce device tree parser > thermal: ti-soc-thermal: use thermal DT infrastructure > arm: dts: add omap4430 thermal data > hwmon: lm75: expose to thermal fw via DT nodes > hwmon: tmp102: expose to thermal fw via DT nodes > > .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt | 3 + > .../devicetree/bindings/thermal/thermal.txt | 133 ++++++ > Documentation/thermal/sysfs-api.txt | 7 + > arch/arm/boot/dts/omap443x.dtsi | 32 +- > drivers/cpufreq/cpufreq-cpu0.c | 8 + > drivers/hwmon/lm75.c | 29 ++ > drivers/hwmon/tmp102.c | 25 ++ > drivers/thermal/Kconfig | 22 + > drivers/thermal/Makefile | 4 + > drivers/thermal/thermal_core.c | 274 +----------- > drivers/thermal/thermal_dt.c | 458 +++++++++++++++++++++ > drivers/thermal/thermal_hwmon.c | 269 ++++++++++++ > drivers/thermal/thermal_hwmon.h | 49 +++ > drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 46 ++- > include/dt-bindings/thermal/thermal.h | 27 ++ > include/linux/thermal.h | 13 + > 16 files changed, 1129 insertions(+), 270 deletions(-) > create mode 100644 Documentation/devicetree/bindings/thermal/thermal.txt > create mode 100644 drivers/thermal/thermal_dt.c > create mode 100644 drivers/thermal/thermal_hwmon.c > create mode 100644 drivers/thermal/thermal_hwmon.h > create mode 100644 include/dt-bindings/thermal/thermal.h > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
