From: punit.agrawal@arm.com (Punit Agrawal)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH] hwmon: (scpi) Add slope and offset to SCP sensor readings
Date: Wed, 01 Mar 2017 16:57:00 +0000 [thread overview]
Message-ID: <87inntorz7.fsf@e105922-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAL9uMOG5qEgyGTue=n7abbFROKGBpUrWDOPi5_bEDUWuiHEUKg@mail.gmail.com> (Carlo Caione's message of "Wed, 1 Mar 2017 17:16:36 +0100")
Carlo Caione <carlo@endlessm.com> writes:
> On Wed, Mar 1, 2017 at 4:01 PM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On 03/01/2017 05:20 AM, Carlo Caione wrote:
>>>
>>> From: Carlo Caione <carlo@endlessm.com>
>>>
>>> The temperature provided by the SCP sensors not always is expressed in
>>> millicelsius, whereas this is required by the thermal framework. This is
>>> for example the case for the Amlogic devices, where the SCP sensor
>>> readings are expressed in degree (and not milli degree) Celsius.
>>>
>> Are you saying that SCPI does not specify or provide the units to be used
>> when reading values, and thus effectively just reports a more or less
>> random number ?
>
> AFAICT the standard does not specify the units to be used for the
> values or a way to get that information. For the Amlogic case the SCP
> returns the value of the temperature in degree celsius and I'm not
> sure how common is that.
The standard does specify the units, but the way it is written seems to
suggest that the units are part of the platform implementation rather
than part of the standard [0].
[0] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922g/CABBCJGH.html
>
> [cut]
>>> - *temp = value;
>>> + slope = thermal_zone_get_slope(zone->z);
>>> + offset = thermal_zone_get_offset(zone->z);
>>
>>
>> This is conceptually wrong. The functions return -ENODEV if thermal is
>> disabled.
>> While a negative slope does not make sense, a negative offset does.
>
> Yeah, but in that case we would have already failed to register the
> thermal zone at all in devm_thermal_zone_of_sensor_register().
>
In addition to the thermal sub-subsystem, hwmon sysfs interface also
expects temperature in millidegree Celsius. Ideally, any change should
fix the reporting there as well. More below.
>> The code in the thermal subsystem does not clarify well how slope and offset
>> are supposed to be used. Since coming from the thermal subsystem, one would
>> think
>> that the thermal subsystem would apply any corrections if they are supposed
>> to be software correction values, but that does not appear to be the case,
>> leaving it up to drivers to use or not use the provided values.
>
> Yes, this is my understanding also considering this comment here:
> http://lxr.free-electrons.com/source/drivers/thermal/of-thermal.c#L1006
>
> So apparently the slope and offset values are left to be used by the
> driver, that's why I was changing the temperature driver to use those
> values.
>
>> This is kind of odd; the values are thermal subsystem attributes/properties,
>> and one would think that they are to be used there unless they are supposed
>> to be
>> written into hardware. Given that, I'd rather wait for the API to be
>> clarified
>> instead of jumping into using it.
>
> Zhang, Eduardo (+CC)
> can you clarify a bit this point?
>
Another way to fix this would be to add optional properties to the scpi
sensors binding and use them instead. This could then be used to fixup
values reported to both thermal and hwmon.
>> There are secondary problems with this approach; other drivers such as lm90
>> which
>> support the thermal subsystem have their own means to specify and use the
>> offset
>> (since it needs to be programmed into the chip registers).
>
> I fail to see how this is related to my patch. If no coefficient is
> defined in the thermal zone node in the DT the framework sets slope=1
> and offset=0, so in the hwmon driver nothing changes.
>
>> Also, this would only solve the problem for temperatures and does not
>> address
>> the generic problem (ie voltage and current values).
>
> This problem is specific for the interaction between the hwmon SCPI
> driver and the thermal subsystem. Look for example at the board I'm
> working with one single thermal zone using the temperature data coming
> from SCP:
>
> scpi_sensors: sensors {
> compatible = "arm,scpi-sensors";
> #thermal-sensor-cells = <1>;
> };
>
> thermal-zones {
> soc_thermal {
> thermal-sensors = <&scpi_sensors 0>;
> coefficients = <1000 0>;
>
> trips {
> control: trip-point at 1 {
> temperature = <80000>;
> hysteresis = <1000>;
> type = "passive";
> };
> };
>
> cooling-maps {
> cpufreq_cooling_map {
> trip = <&control>;
> cooling-device = <&cpus THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> };
> };
> };
> };
>
> trip points are defined in milli degree Celsius while the temperature
> returned by the scpi_sensors node is in degree Celsius. Without using
> the coefficients property and my changes how can I make the cooling
> map working fine?
>
> Thanks,
next prev parent reply other threads:[~2017-03-01 16:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 13:20 Carlo Caione
2017-03-01 15:01 ` Guenter Roeck
2017-03-01 16:16 ` Carlo Caione
2017-03-01 16:57 ` Punit Agrawal [this message]
2017-03-01 17:09 ` Carlo Caione
2017-03-01 17:56 ` Guenter Roeck
2017-03-01 18:45 ` Carlo Caione
2017-03-01 20:04 ` Guenter Roeck
2017-03-01 17:46 ` Guenter Roeck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87inntorz7.fsf@e105922-lin.cambridge.arm.com \
--to=punit.agrawal@arm.com \
--cc=linus-amlogic@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®