Documentation: add Device tree bindings for hwmon/nct7802

PATCH Superseded Constantine Shulyupin 3 participants 6 messages Sep 7, 2015 – Sep 8, 2015

Subsystems (2)

Device tree bindings Hardware monitoring

lore

Share & tools

lore

Constantine Shulyupin

author

2015-09-07 22:27 UTC #0 lore raw

PATCH v3 1/1 Documentation: add Device tree bindings for hwmon/nct7802

Add add Device tree bindings for registers which are not covered by hwmon ABI and are required to configure specific HW.
---

Changed in v3:
- Fixed vendor prefix
- Added short registers description,
full registers description is available at
https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/

Changed in v2:
- Removed nct7802,reg-init
- Added registers initialization by names

Introduced in v1:
- nct7802,reg-init

Signed-off-by Constantine Shulyupin <[email protected]>

---
 .../devicetree/bindings/hwmon/nct7802.txt          | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt

Documentation/devicetree/bindings/hwmon/nct7802.txt new file +28 -0

new file mode 100644
index 0000000..5b4c3fe
@@ -0,0 +1,28 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device
+
+Optional properties:
+
+One byte registers:
+ - nuvoton,start - Start register at index 0x21
+ - nuvoton,mode - Mode register at index 0x22
+ - nuvoton,en_peci - PECI enable register at index 0x23
+ - nuvoton,en_fan - Fan Enable Register at index 0x24
+ - nuvoton,en_v - voltage monitor enable register
+		  at index 0x25
+
+A detailed datasheet for registers and the device is
+available at Nuvoton web site.
+
+Example nct7802 node:
+
+nct7802 {
+	compatible = "nuvoton,nct7802";
+	reg = <0x2a>;
+	nuvoton,start = <0x01>;
+	nuvoton,mode = <0x7E>; // RTD1_MD = 2
+};

Signature · 1 line

1.9.1

Mark Rutland

2015-09-08 09:38 UTC #1 lore raw

Quoted 3 lines · Constantine Shulyupin

Add add Device tree bindings for registers which are not covered by hwmon ABI and are required to configure specific HW.

This doesn't really answer my question [1] of why you need these.

We generally don't encode register values unless there's no other way to describe the device. Why can we not describe the physical properties of the device that make these values necessary?

Could you please Cc me on the entire series in future? The driver code is helpful context.

Quoted 7 lines

---
Changed in v3:
- Fixed vendor prefix
- Added short registers description,
full registers description is available at
https://www.nuvoton.com/hq/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/

This seems to require registration, which is unfortuante (and familiar)...

Quoted 26 lines

Changed in v2:
- Removed nct7802,reg-init
- Added registers initialization by names
Introduced in v1:
- nct7802,reg-init
Signed-off-by Constantine Shulyupin <[email protected]>
---
 .../devicetree/bindings/hwmon/nct7802.txt          | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/nct7802.txt
Documentation/devicetree/bindings/hwmon/nct7802.txt new file +6 -0
new file mode 100644
index 0000000..5b4c3fe
@@ -0,0 +1,28 @@
+Nuvoton NCT7802Y Hardware Monitoring IC
+
+Required node properties:
+
+ - "compatible": must be "nuvoton,nct7802"
+ - "reg": I2C bus address of the device

Documentation/devicetree/bindings/hwmon/nct7802.txt line 16

Quoted 10 lines

Documentation/devicetree/bindings/hwmon/nct7802.txt new file +10 -0

+
+Optional properties:
+
+One byte registers:
+ - nuvoton,start - Start register at index 0x21
+ - nuvoton,mode - Mode register at index 0x22
+ - nuvoton,en_peci - PECI enable register at index 0x23
+ - nuvoton,en_fan - Fan Enable Register at index 0x24
+ - nuvoton,en_v - voltage monitor enable register
+		  at index 0x25

Minor nit I missed last time, but s/_/-/ in property names.

That said, as above I don't believe that these properties make sense as they are. I think this needs properties that describe the HW, rather than exposing the intricacies of the programming interface.

Quoted 14 lines

Documentation/devicetree/bindings/hwmon/nct7802.txt new file +12 -0

+
+A detailed datasheet for registers and the device is
+available at Nuvoton web site.
+
+Example nct7802 node:
+
+nct7802 {
+	compatible = "nuvoton,nct7802";
+	reg = <0x2a>;
+	nuvoton,start = <0x01>;
+	nuvoton,mode = <0x7E>; // RTD1_MD = 2
+};

Signature · 1 line

1.9.1

Thanks,
Mark.

[1] http://lkml.kernel.org/r/20150907123531.GA11540@leverpostej

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Constantine Shulyupin

author

2015-09-08 12:07 UTC #2 lore raw

Quoted 10 lines

Quoted 3 lines
Add add Device tree bindings for registers which are not covered by hwmon ABI and are required to configure specific HW.
This doesn't really answer my question [1] of why you need these.
We generally don't encode register values unless there's no other way to describe the device. Why can we not describe the physical properties of the device that make these values necessary?

....

Quoted 3 lines

That said, as above I don't believe that these properties make sense as they are. I think this needs properties that describe the HW, rather than exposing the intricacies of the programming interface.

....

Quoted 5 lines

Thanks,
Mark.
[1] http://lkml.kernel.org/r/20150907123531.GA11540@leverpostej

Sources of the driver:

Let's see to register MODE.
Excerpt from datasheet:

7.2.32 Mode Selection Register
Location : Index 22h
Type : Read/Write
Power on default value : 7Fh
BIT; NAME; FUNC.:
0,1 RTD1_MD : 00=Closed , 01=Current mode , 10=Thermistor mode , 11=Voltage sense
2,3 RTD2_MD : 00=Closed , 01=Current mode , 10=Thermistor mode , 11=Voltage sense
4,5 RTD3_MD : 00=Closed , 01=Reserved , 10=Thermistor mode , 11=Voltage sense 6 EnLTD : 1 indicates the LTD function enabled

The register defines sensors types (Closed, Current mode, Thermistor mode, Voltage sense).
Essential sensors will not work properly with wrong configuration. It is board or platform depended configuration. It should be configured on boot only.
Usually hwmon drivers are managed with utility lm-sensors via Documentation/hwmon/sysfs-interface. By design sensor type should be defined by platform data and lm-sensors only displays it.

Also MODE registers defines visibility temperature and input attributes:

https://git.kernel.org/cgit/linux/kernel/git/mpe/linux-next.git/tree/drivers/hwmon/nct7802.c#n532

https://git.kernel.org/cgit/linux/kernel/git/mpe/linux-next.git/tree/drivers/hwmon/nct7802.c#n641

Mark, does above answers your question?
What do you propose?

Signature · 6 lines

Thanks
Constantine
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mark Rutland

2015-09-08 12:47 UTC #3 lore raw

Quoted 38 lines · Constantine Shulyupin

Quoted 10 lines
Quoted 3 lines
Add add Device tree bindings for registers which are not covered by hwmon ABI and are required to configure specific HW.
This doesn't really answer my question [1] of why you need these.
We generally don't encode register values unless there's no other way to describe the device. Why can we not describe the physical properties of the device that make these values necessary?
....
Quoted 3 lines
That said, as above I don't believe that these properties make sense as they are. I think this needs properties that describe the HW, rather than exposing the intricacies of the programming interface.
....
Quoted 5 lines
Thanks,
Mark.
[1] http://lkml.kernel.org/r/20150907123531.GA11540@leverpostej
Sources of the driver:
Let's see to register MODE.
Excerpt from datasheet:
7.2.32 Mode Selection Register
Location : Index 22h
Type : Read/Write
Power on default value : 7Fh
BIT; NAME; FUNC.:
0,1 RTD1_MD : 00=Closed , 01=Current mode , 10=Thermistor mode , 11=Voltage sense
2,3 RTD2_MD : 00=Closed , 01=Current mode , 10=Thermistor mode , 11=Voltage sense
4,5 RTD3_MD : 00=Closed , 01=Reserved , 10=Thermistor mode , 11=Voltage sense 6 EnLTD : 1 indicates the LTD function enabled

Quoted 3 lines

The register defines sensors types (Closed, Current mode, Thermistor mode, Voltage sense).
Essential sensors will not work properly with wrong configuration.

Sure, but why do you need _raw_ register values?

Why can you not encode this in the DT in a manner that describes what is connected to this device, then have the kernel figure out any particular values that need to be poked into registers?

That'll be easier to read, and it's far more likely people will get things correct in a dts.

Mark.

Quoted 6 lines

It is board or platform depended configuration. It should be configured on boot only.
Usually hwmon drivers are managed with utility lm-sensors via Documentation/hwmon/sysfs-interface. By design sensor type should be defined by platform data and lm-sensors only displays it.

Quoted 13 lines

Also MODE registers defines visibility temperature and input attributes:
https://git.kernel.org/cgit/linux/kernel/git/mpe/linux-next.git/tree/drivers/hwmon/nct7802.c#n532
https://git.kernel.org/cgit/linux/kernel/git/mpe/linux-next.git/tree/drivers/hwmon/nct7802.c#n641
Mark, does above answers your question?
What do you propose?
Signature · 2 lines
Thanks
Constantine

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Constantine Shulyupin

author

2015-09-08 13:49 UTC #4 lore raw

Quoted 10 lines

Sure, but why do you need _raw_ register values?
Why can you not encode this in the DT in a manner that describes what is connected to this device, then have the kernel figure out any particular values that need to be poked into registers?
That'll be easier to read, and it's far more likely people will get things correct in a dts.
Mark.

Theoretically it is possible to use function store_temp_type
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/hwmon/nct7802.c#n87
to set sensors types.
With ABI codes:
3 - thermal diode
4 - thermistor

But:
- Sensor type could be also voltage and is mapped to in_input attributes. Generic code would be over complicated.
- For low level programmers and PCB engineers is much more comfortable and error safe
to works with datasheets, registers and bits than with fancy "human readable" configuration.
- Mapping between raw bits and ABI is not intuitive. More simple and directed configuration is preferable.

Signature · 2 lines

Thanks
Constantine

Guenter Roeck

maintainer

2015-09-08 14:35 UTC #5 lore raw

Constantine,

Quoted 18 lines · Constantine Shulyupin

Quoted 10 lines
Sure, but why do you need _raw_ register values?
Why can you not encode this in the DT in a manner that describes what is connected to this device, then have the kernel figure out any particular values that need to be poked into registers?
That'll be easier to read, and it's far more likely people will get things correct in a dts.
Mark.
Theoretically it is possible to use function store_temp_type
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/drivers/hwmon/nct7802.c#n87
to set sensors types.
With ABI codes:
3 - thermal diode
4 - thermistor

Quoted 10 lines

But:
- Sensor type could be also voltage and is mapped to in_input attributes. Generic code would be over complicated.
- For low level programmers and PCB engineers is much more comfortable and error safe
to works with datasheets, registers and bits than with fancy "human readable" configuration.
- Mapping between raw bits and ABI is not intuitive. More simple and directed configuration is preferable.

Mark is asking why you don't have a 'sensor-type' property (or similar). This is not an ABI issue, since the sensor type is determined by the PCB, not by user space configuration. The only reason to have the attribute writable in the ABI is to be able to support hardware where for some reason the hardware parameters configured by the BIOS or ROMMON are wrong, not as primary means to set the sensor type. Actually, in an automated system where the temperature is used for automatic fan control, waiting for user space to configure the chip might be fatal.

As for your other arguments, pretty much all other devicetree properties use logical values instead of raw register values. It appears that the low level programmers and PCB engineers responsible for writing devicetree files must be able to handle that level of abstraction. And I really would content that it is easier to write

	sensor-type = "thermistor";

than forcing people to look up the datasheet when writing devicetree files.

Thanks,
Guenter