diff mbox series

[v3,1/3] dt-bindings: thermal: sophgo,cv1800-thermal: Add Sophgo CV1800 thermal

Message ID SEYPR01MB42217228213F5F2C739088DED7DC2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com (mailing list archive)
State Handled Elsewhere, archived
Headers show
Series riscv: sophgo: add thermal sensor support for cv180x/sg200x SoCs | expand

Commit Message

Haylen Chu July 2, 2024, 9:30 a.m. UTC 
Add devicetree binding documentation for thermal sensors integrated in
Sophgo CV180X SoCs.

Signed-off-by: Haylen Chu <heylenay@outlook.com>
---
 .../thermal/sophgo,cv1800-thermal.yaml        | 74 +++++++++++++++++++
 1 file changed, 74 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml

Comments

Conor Dooley July 2, 2024, 3 p.m. UTC | #1 
Rob/Krzysztof, Haylen,

On Tue, Jul 02, 2024 at 09:30:24AM +0000, Haylen Chu wrote:
> Add devicetree binding documentation for thermal sensors integrated in
> Sophgo CV180X SoCs.
> 
> Signed-off-by: Haylen Chu <heylenay@outlook.com>
> ---
>  .../thermal/sophgo,cv1800-thermal.yaml        | 74 +++++++++++++++++++
>  1 file changed, 74 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml
> 
> diff --git a/Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml b/Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml
> new file mode 100644
> index 000000000000..016299822c16
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/thermal/sophgo,cv1800-thermal.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Sophgo CV1800 on-SoC Thermal Sensor
> +
> +maintainers:
> +  - Haylen Chu <heylenay@outlook.com>
> +
> +description: Binding for Sophgo CV1800 on-SoC thermal sensor
> +
> +properties:
> +  compatible:
> +    enum:
> +      - sophgo,cv1800-thermal
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    description: The thermal sensor clock
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  accumulation-period:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: Accumulation period for a sample
> +    enum:
> +      - 512
> +      - 1024
> +      - 2048
> +      - 4096
> +    default: 2048
> +
> +  chop-period:
> +    $ref: /schemas/types.yaml#/definitions/uint32
> +    description: ADC chop period
> +    enum:
> +      - 128
> +      - 256
> +      - 512
> +      - 1024
> +    default: 1024
> +
> +  sample-cycle-us:

the more common term btw would be "sample-rate" rather than
"sample-cycle".

> +    description: Period between samples. Should be greater than 524us.

The constraint here should be "minimum: 524". What's the upper limit?

> +    default: 1000000

Rob/Krzysztof, could you comment on the suitability of the three custom
properties here? I know if this was an IIO device, these kinds of things
would be controllable from userspace, and not in the binding. I
mentioned this on the previous version, but I'm not really sure if
thermal devices are somehow different:
https://lore.kernel.org/all/SEYPR01MB4221A739D0645EF0255336EBD7CE2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com/

Cheers,
Conor.

> +
> +  '#thermal-sensor-cells':
> +    const: 0
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +        #include <dt-bindings/clock/sophgo,cv1800.h>
> +        #include <dt-bindings/interrupt-controller/irq.h>
> +        thermal-sensor@30e0000 {
> +            compatible = "sophgo,cv1800-thermal";
> +            reg = <0x30e0000 0x100>;
> +            clocks = <&clk CLK_TEMPSEN>;
> +            interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
> +            #thermal-sensor-cells = <0>;
> +        };
> +...
> -- 
> 2.45.2
>
Krzysztof Kozlowski July 2, 2024, 3:09 p.m. UTC | #2 
On 02/07/2024 17:00, Conor Dooley wrote:
> Rob/Krzysztof, Haylen,
>> +
>> +maintainers:
>> +  - Haylen Chu <heylenay@outlook.com>
>> +
>> +description: Binding for Sophgo CV1800 on-SoC thermal sensor

Drop "Binding"

>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - sophgo,cv1800-thermal
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    description: The thermal sensor clock
>> +
>> +  interrupts:
>> +    maxItems: 1
>> +
>> +  accumulation-period:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description: Accumulation period for a sample
>> +    enum:
>> +      - 512
>> +      - 1024
>> +      - 2048
>> +      - 4096
>> +    default: 2048
>> +
>> +  chop-period:

period in what sort of units? Sounds like time to me, so this would
require proper unit suffix.

>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description: ADC chop period
>> +    enum:
>> +      - 128
>> +      - 256
>> +      - 512
>> +      - 1024
>> +    default: 1024
>> +
>> +  sample-cycle-us:
> 
> the more common term btw would be "sample-rate" rather than
> "sample-cycle".

yeah, sample-rate-hz

> 
>> +    description: Period between samples. Should be greater than 524us.
> 
> The constraint here should be "minimum: 524". What's the upper limit?
> 
>> +    default: 1000000
> 
> Rob/Krzysztof, could you comment on the suitability of the three custom
> properties here? I know if this was an IIO device, these kinds of things
> would be controllable from userspace, and not in the binding. I
> mentioned this on the previous version, but I'm not really sure if
> thermal devices are somehow different:
> https://lore.kernel.org/all/SEYPR01MB4221A739D0645EF0255336EBD7CE2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com/
> 

Why would different boards have different values here? Does it affect
accuracy? If so, how much?

I doubt there are any boards with different values, thus it sounds like
unnecessary tuning parameter.

Best regards,
Krzysztof
Haylen Chu July 4, 2024, 8:25 a.m. UTC | #3 
On Tue, Jul 02, 2024 at 05:09:35PM +0200, Krzysztof Kozlowski wrote:
> >> +
> >> +properties:
> >> +  compatible:
> >> +    enum:
> >> +      - sophgo,cv1800-thermal
> >> +
> >> +  reg:
> >> +    maxItems: 1
> >> +
> >> +  clocks:
> >> +    description: The thermal sensor clock
> >> +
> >> +  interrupts:
> >> +    maxItems: 1
> >> +
> >> +  accumulation-period:
> >> +    $ref: /schemas/types.yaml#/definitions/uint32
> >> +    description: Accumulation period for a sample
> >> +    enum:
> >> +      - 512
> >> +      - 1024
> >> +      - 2048
> >> +      - 4096
> >> +    default: 2048
> >> +
> >> +  chop-period:
> 
> period in what sort of units? Sounds like time to me, so this would
> require proper unit suffix.

In clock ticks.

When setting to 1024, a time of sample takes (1024 + 2 + 64) clock
ticks. The clock runs at (25MHz / divider) and the divider is
configurable.

> > 
> >> +    description: Period between samples. Should be greater than 524us.
> > 
> > The constraint here should be "minimum: 524". What's the upper limit?
> > 
> >> +    default: 1000000
> > 
> > Rob/Krzysztof, could you comment on the suitability of the three custom
> > properties here? I know if this was an IIO device, these kinds of things
> > would be controllable from userspace, and not in the binding. I
> > mentioned this on the previous version, but I'm not really sure if
> > thermal devices are somehow different:
> > https://lore.kernel.org/all/SEYPR01MB4221A739D0645EF0255336EBD7CE2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com/
> > 
> 
> Why would different boards have different values here? Does it affect
> accuracy? If so, how much?
> 
> I doubt there are any boards with different values, thus it sounds like
> unnecessary tuning parameter.

Theses values affect accuracy in a minor way (about 1 Celsius degree in
my test) and could be shared between CV18xx/SG20xx SoCs as they have the
same design.

In the first revision, fixed values are used, and I was asked to add
support for all possible configuration[1]. Now I think this introduces
extra unnecessary complexity and should be avoided, since this is a
simple thermal sensor, tuning seems to be useless.

I suggest renaming "sample-cycle-us" to "sample-rate-hz" and dropping
other parameters for simplicity.

Best regards,
Haylen Chu

[1]: https://lore.kernel.org/all/IA1PR20MB49533177BEFC431FC16D1AB8BBF32@IA1PR20MB4953.namprd20.prod.outlook.com/
Krzysztof Kozlowski July 4, 2024, 8:41 a.m. UTC | #4 
On 04/07/2024 10:25, Haylen Chu wrote:
> On Tue, Jul 02, 2024 at 05:09:35PM +0200, Krzysztof Kozlowski wrote:
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - sophgo,cv1800-thermal
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clocks:
>>>> +    description: The thermal sensor clock
>>>> +
>>>> +  interrupts:
>>>> +    maxItems: 1
>>>> +
>>>> +  accumulation-period:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>> +    description: Accumulation period for a sample
>>>> +    enum:
>>>> +      - 512
>>>> +      - 1024
>>>> +      - 2048
>>>> +      - 4096
>>>> +    default: 2048
>>>> +
>>>> +  chop-period:
>>
>> period in what sort of units? Sounds like time to me, so this would
>> require proper unit suffix.
> 
> In clock ticks.

Then please mention it in the property description.

> 
> When setting to 1024, a time of sample takes (1024 + 2 + 64) clock
> ticks. The clock runs at (25MHz / divider) and the divider is
> configurable.

> 
>>>
>>>> +    description: Period between samples. Should be greater than 524us.
>>>
>>> The constraint here should be "minimum: 524". What's the upper limit?
>>>
>>>> +    default: 1000000
>>>
>>> Rob/Krzysztof, could you comment on the suitability of the three custom
>>> properties here? I know if this was an IIO device, these kinds of things
>>> would be controllable from userspace, and not in the binding. I
>>> mentioned this on the previous version, but I'm not really sure if
>>> thermal devices are somehow different:
>>> https://lore.kernel.org/all/SEYPR01MB4221A739D0645EF0255336EBD7CE2@SEYPR01MB4221.apcprd01.prod.exchangelabs.com/
>>>
>>
>> Why would different boards have different values here? Does it affect
>> accuracy? If so, how much?
>>
>> I doubt there are any boards with different values, thus it sounds like
>> unnecessary tuning parameter.
> 
> Theses values affect accuracy in a minor way (about 1 Celsius degree in
> my test) and could be shared between CV18xx/SG20xx SoCs as they have the
> same design.
> 
> In the first revision, fixed values are used, and I was asked to add
> support for all possible configuration[1]. Now I think this introduces
> extra unnecessary complexity and should be avoided, since this is a
> simple thermal sensor, tuning seems to be useless.
> 
> I suggest renaming "sample-cycle-us" to "sample-rate-hz" and dropping
> other parameters for simplicity.

Ack for me.

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml b/Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml
new file mode 100644
index 000000000000..016299822c16
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/sophgo,cv1800-thermal.yaml
@@ -0,0 +1,74 @@ 
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/thermal/sophgo,cv1800-thermal.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo CV1800 on-SoC Thermal Sensor
+
+maintainers:
+  - Haylen Chu <heylenay@outlook.com>
+
+description: Binding for Sophgo CV1800 on-SoC thermal sensor
+
+properties:
+  compatible:
+    enum:
+      - sophgo,cv1800-thermal
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    description: The thermal sensor clock
+
+  interrupts:
+    maxItems: 1
+
+  accumulation-period:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Accumulation period for a sample
+    enum:
+      - 512
+      - 1024
+      - 2048
+      - 4096
+    default: 2048
+
+  chop-period:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: ADC chop period
+    enum:
+      - 128
+      - 256
+      - 512
+      - 1024
+    default: 1024
+
+  sample-cycle-us:
+    description: Period between samples. Should be greater than 524us.
+    default: 1000000
+
+  '#thermal-sensor-cells':
+    const: 0
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - interrupts
+
+additionalProperties: false
+
+examples:
+  - |
+        #include <dt-bindings/clock/sophgo,cv1800.h>
+        #include <dt-bindings/interrupt-controller/irq.h>
+        thermal-sensor@30e0000 {
+            compatible = "sophgo,cv1800-thermal";
+            reg = <0x30e0000 0x100>;
+            clocks = <&clk CLK_TEMPSEN>;
+            interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
+            #thermal-sensor-cells = <0>;
+        };
+...