| Message ID | 20170309101759.18081-2-carlo@caione.org (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
On 09/03/17 10:17, Carlo Caione wrote: > From: Carlo Caione <carlo@endlessm.com> > > Document the new property `scpi,sensors-scale` used by the hwmon-scpi > driver to convert the sensor readings to the correct / expected scale. > I am fine with DT bindings if DT maintainers agree with having one but I would like to add couple of points to get their feedback: 1. ARM recognized the drawbacks of SCPI which started informally with ARM Ltd platforms and got adopted by few vendors. It's now being worked on and a much better and scalable replacement protocol is being discussed with vendors now. So future enhancement to this SCPI protocol is unlikely. 2. AmLogic has diverted from base protocol in many ways and most of them are handled with just compatible so far without any need for additional bindings. Can we avoid it ? So based on these, I prefer not to add more bindings to handle such deviations but make it just AmLogic specific.
On Wed, Mar 15, 2017 at 06:20:33PM +0000, Sudeep Holla wrote: > > > On 09/03/17 10:17, Carlo Caione wrote: > > From: Carlo Caione <carlo@endlessm.com> > > > > Document the new property `scpi,sensors-scale` used by the hwmon-scpi > > driver to convert the sensor readings to the correct / expected scale. > > > > I am fine with DT bindings if DT maintainers agree with having one but I > would like to add couple of points to get their feedback: > > 1. ARM recognized the drawbacks of SCPI which started informally with > ARM Ltd platforms and got adopted by few vendors. It's now being > worked on and a much better and scalable replacement protocol is > being discussed with vendors now. So future enhancement to this SCPI > protocol is unlikely. > > 2. AmLogic has diverted from base protocol in many ways and most of them > are handled with just compatible so far without any need for > additional bindings. Can we avoid it ? > > So based on these, I prefer not to add more bindings to handle such > deviations but make it just AmLogic specific. > I like the idea. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 15, 2017 at 06:20:33PM +0000, Sudeep Holla wrote: > > > On 09/03/17 10:17, Carlo Caione wrote: > > From: Carlo Caione <carlo@endlessm.com> > > > > Document the new property `scpi,sensors-scale` used by the hwmon-scpi > > driver to convert the sensor readings to the correct / expected scale. > > > > I am fine with DT bindings if DT maintainers agree with having one but I > would like to add couple of points to get their feedback: > > 1. ARM recognized the drawbacks of SCPI which started informally with > ARM Ltd platforms and got adopted by few vendors. It's now being > worked on and a much better and scalable replacement protocol is > being discussed with vendors now. So future enhancement to this SCPI > protocol is unlikely. > > 2. AmLogic has diverted from base protocol in many ways and most of them > are handled with just compatible so far without any need for > additional bindings. Can we avoid it ? > > So based on these, I prefer not to add more bindings to handle such > deviations but make it just AmLogic specific. Agreed. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 15, 2017 at 7:20 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > On 09/03/17 10:17, Carlo Caione wrote: >> From: Carlo Caione <carlo@endlessm.com> >> >> Document the new property `scpi,sensors-scale` used by the hwmon-scpi >> driver to convert the sensor readings to the correct / expected scale. >> > > I am fine with DT bindings if DT maintainers agree with having one but I > would like to add couple of points to get their feedback: > > 1. ARM recognized the drawbacks of SCPI which started informally with > ARM Ltd platforms and got adopted by few vendors. It's now being > worked on and a much better and scalable replacement protocol is > being discussed with vendors now. So future enhancement to this SCPI > protocol is unlikely. > > 2. AmLogic has diverted from base protocol in many ways and most of them > are handled with just compatible so far without any need for > additional bindings. Can we avoid it ? > > So based on these, I prefer not to add more bindings to handle such > deviations but make it just AmLogic specific. could you please share your idea where this "Amlogic specific implementation" fits best? - in firmware/arm_scpi to keep a contract (for example: millicelsius) to everyone who reads a temperature sensor for example - or in hwmon/scpi-hwmon Regards, Martin -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 15, 2017 at 09:56:09PM +0100, Martin Blumenstingl wrote: > On Wed, Mar 15, 2017 at 7:20 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > > > > On 09/03/17 10:17, Carlo Caione wrote: > >> From: Carlo Caione <carlo@endlessm.com> > >> > >> Document the new property `scpi,sensors-scale` used by the hwmon-scpi > >> driver to convert the sensor readings to the correct / expected scale. > >> > > > > I am fine with DT bindings if DT maintainers agree with having one but I > > would like to add couple of points to get their feedback: > > > > 1. ARM recognized the drawbacks of SCPI which started informally with > > ARM Ltd platforms and got adopted by few vendors. It's now being > > worked on and a much better and scalable replacement protocol is > > being discussed with vendors now. So future enhancement to this SCPI > > protocol is unlikely. > > > > 2. AmLogic has diverted from base protocol in many ways and most of them > > are handled with just compatible so far without any need for > > additional bindings. Can we avoid it ? > > > > So based on these, I prefer not to add more bindings to handle such > > deviations but make it just AmLogic specific. > could you please share your idea where this "Amlogic specific > implementation" fits best? > - in firmware/arm_scpi to keep a contract (for example: millicelsius) > to everyone who reads a temperature sensor for example > - or in hwmon/scpi-hwmon > So far the assumption was that it would be in hwmon. I don't mind for it to be elsewhere, but I would think that the presence or non-presence of a devicetree property should not affect or change the implementation. Thanks, Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt index 4018319..35c621c 100644 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -84,6 +84,24 @@ Required properties: as used by the firmware. Refer to platform details for your implementation for the IDs to use. +Optional properties: +- scpi,sensors-scale: array of 5 elements defining the unit scale used by the + SCP for the 5 different sensor classes (temperature, + voltage, current, power, energy) such that 1 == unit, + 1000 == milli, 1000000 == micro, ... + + Example: + scpi,sensors-scale = <1 1000 1000 1000000 1000000> + In this case the values reported by SCP are: + -> temperature in degree Celsius + -> voltage in millivolts + -> current in milliamperes + -> power in microwatts + -> energy in microjoules + + The default value is: + scpi,sensors-scale = <1000 1000 1000 1000000 1000000> + Power domain bindings for the power domains based on SCPI Message Protocol ------------------------------------------------------------