Re: [RFC PATCH 3/4] thermal: ti-soc-thermal: use thermal DT infrastructure

[Eduardo Valentin <eduardo.valentin@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

On 15-07-2013 08:12, Lucas Stach wrote:
> Hi Eduardo and others,
> 
> Eduardo Valentin <eduardo.valentin <at> ti.com> writes:
> 
>>
>> This patch improves the ti-soc-thermal driver by adding the
>> support to build the thermal zones based on DT nodes.
>>
>> The driver will have two options now to build the thermal
>> zones. The first option is the zones originally coded
>> in this driver. So, the driver behavior will be same
>> if there is no DT node describing the zones. The second
>> option, when it is found a DT node with thermal data,
>> will used the common infrastructure to build the thermal
>> zone and bind its cooling devices.
>>
>> In either case, this driver still adds to the system
>> a cpufreq cooling device.
>>
> 
> I really like the idea to configure thermal zones using devicetree, it's a
> step in the right direction. We might follow suit with the i.MX6 tempmon
> driver to use this infrastructure.
> 
> What I strongly dislike is the notion of the sensor drivers instantiating
> the cooling devices and the resulting devicetree binding. This seems really
> backward to me.
> I would rather see the drivers associated with the cooling devices (like
> cpufreq and the respective gpu drivers) to instantiate the cooling devices
> and the thermal zone referring to them through phandles. I think it
> shouldn't be too much work to go in that direction.
> The current method might be enough to work with the current thermal platform
> drivers, but if you want to go down the route to eventually use plain i2c
> devices (likely with an existing hwmon driver) you have to get away from the
> sensor devices instantiating the cooling devices.

I agree with you. While implementing the RFC, it looks awkward that the
ti-soc-thermal driver had to do the job to load the cpufreq-cooling
device. Problem is that a cooling device is not really a real device,
and might get flamed while represented as a device tree node.

I could try to push something following the same idea as the one I am
trying to sell with this series for sensor devices. For instance, in a
sensor node I am attaching a phandle to describe how thermal fw must
behave. Then the sensor driver it is supposed to load the thermal data
into the thermal fw. Same could apply for instance for cpufreq cooling
device. at the cpu node we could have a 'cooling_device' node at the cpu
node, while loading cpufreq-cpu0.

> 
> Regards,
> Lucas
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]