From: Conor Dooley <conor@kernel.org>
To: Inochi Amaoto <inochiama@outlook.com>
Cc: Haylen Chu <heylenay@outlook.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Lukasz Luba <lukasz.luba@arm.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Chen Wang <unicorn_wang@outlook.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Jisheng Zhang <jszhang@kernel.org>,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v2 1/3] dt-bindings: thermal: sophgo,cv180x-thermal: Add Sophgo CV180x thermal
Date: Wed, 5 Jun 2024 18:54:17 +0100 [thread overview]
Message-ID: <20240605-tightwad-janitor-82cfceb1469d@spud> (raw)
In-Reply-To: <IA1PR20MB49531F55C8D7DC5D0050CAF9BBF92@IA1PR20MB4953.namprd20.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]
On Wed, Jun 05, 2024 at 11:40:32AM +0800, Inochi Amaoto wrote:
> On Tue, Jun 04, 2024 at 12:54:19PM GMT, 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,cv180x-thermal.yaml | 82 +++++++++++++++++++
> > 1 file changed, 82 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml b/Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml
> > new file mode 100644
> > index 000000000000..1c3a6f74ff1d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml
> > @@ -0,0 +1,82 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/thermal/sophgo,cv180x-thermal.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Sophgo CV180x on-SoC Thermal Sensor
> > +
> > +maintainers:
> > + - Haylen Chu <heylenay@outlook.com>
> > +
> > +description: Binding for Sophgo CV180x on-SoC thermal sensor
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - sophgo,cv1800-thermal
> > + - sophgo,cv180x-thermal
> > +
>
> Is this necessary? I don't find any change between the sensor of these.
"cv180x" isn't even a real device. Either we have a compatible that
matches an actual SoC and use it everywhere, or we add ones for each SoC
and have a fallback to cv1800.
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + description: The thermal sensor clock
> > +
> > + clock-names:
> > + const: clk_tempsen
clock-names is not useful here as there's only one clock.
"clk_tempsen" sounds more like the name for this clock at the provider
than at the consumer anyway.
> > +
> > + accumulation-period:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: Accumulation period for a sample
> > + oneOf:
> > + - const: 0
> > + description: 512 ticks
> > + - const: 1
> > + description: 1024 ticks
> > + - const: 2
> > + description: 2048 ticks
> > + - const: 3
> > + description: 4096 ticks
> > + default: 2
> > +
> > + chop-period:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: ADC chop period
What's a "chop" and why is either this or the accumulation-period a
fixed property of the hardware? Shouldn't this choice really be up to
the user?
> > + oneOf:
> > + - const: 0
> > + description: 128 ticks
> > + - const: 1
> > + description: 256 ticks
> > + - const: 2
> > + description: 512 ticks
> > + - const: 3
> > + description: 1024 ticks
Can we just make the number of ticks the unit here, and above?
Also, a "oneOf: - const" structure is just an enum.
> > + default: 3
> > +
> > + sample-cycle-us:
> > + description: Period between samples
> > + default: 1000000
No constraints?
Thanks,
Conor.
> > +
> > + '#thermal-sensor-cells':
> > + const: 0
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/sophgo,cv1800.h>
> > + thermal-sensor@30e0000 {
> > + compatible = "sophgo,cv180x-thermal";
> > + reg = <0x30e0000 0x100>;
> > + clocks = <&clk CLK_TEMPSEN>;
> > + clock-names = "clk_tempsen";
> > + #thermal-sensor-cells = <0>;
> > + };
> > +...
>
> Where is the interrupt number? The sensors does support the interrupt,
> but I don't see you describe it in the binding.
>
> > --
> > 2.45.2
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Inochi Amaoto <inochiama@outlook.com>
Cc: Haylen Chu <heylenay@outlook.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Zhang Rui <rui.zhang@intel.com>,
Lukasz Luba <lukasz.luba@arm.com>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Chen Wang <unicorn_wang@outlook.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Jisheng Zhang <jszhang@kernel.org>,
linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH v2 1/3] dt-bindings: thermal: sophgo,cv180x-thermal: Add Sophgo CV180x thermal
Date: Wed, 5 Jun 2024 18:54:17 +0100 [thread overview]
Message-ID: <20240605-tightwad-janitor-82cfceb1469d@spud> (raw)
In-Reply-To: <IA1PR20MB49531F55C8D7DC5D0050CAF9BBF92@IA1PR20MB4953.namprd20.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 4012 bytes --]
On Wed, Jun 05, 2024 at 11:40:32AM +0800, Inochi Amaoto wrote:
> On Tue, Jun 04, 2024 at 12:54:19PM GMT, 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,cv180x-thermal.yaml | 82 +++++++++++++++++++
> > 1 file changed, 82 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml b/Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml
> > new file mode 100644
> > index 000000000000..1c3a6f74ff1d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/thermal/sophgo,cv180x-thermal.yaml
> > @@ -0,0 +1,82 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/thermal/sophgo,cv180x-thermal.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Sophgo CV180x on-SoC Thermal Sensor
> > +
> > +maintainers:
> > + - Haylen Chu <heylenay@outlook.com>
> > +
> > +description: Binding for Sophgo CV180x on-SoC thermal sensor
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - sophgo,cv1800-thermal
> > + - sophgo,cv180x-thermal
> > +
>
> Is this necessary? I don't find any change between the sensor of these.
"cv180x" isn't even a real device. Either we have a compatible that
matches an actual SoC and use it everywhere, or we add ones for each SoC
and have a fallback to cv1800.
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + description: The thermal sensor clock
> > +
> > + clock-names:
> > + const: clk_tempsen
clock-names is not useful here as there's only one clock.
"clk_tempsen" sounds more like the name for this clock at the provider
than at the consumer anyway.
> > +
> > + accumulation-period:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: Accumulation period for a sample
> > + oneOf:
> > + - const: 0
> > + description: 512 ticks
> > + - const: 1
> > + description: 1024 ticks
> > + - const: 2
> > + description: 2048 ticks
> > + - const: 3
> > + description: 4096 ticks
> > + default: 2
> > +
> > + chop-period:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: ADC chop period
What's a "chop" and why is either this or the accumulation-period a
fixed property of the hardware? Shouldn't this choice really be up to
the user?
> > + oneOf:
> > + - const: 0
> > + description: 128 ticks
> > + - const: 1
> > + description: 256 ticks
> > + - const: 2
> > + description: 512 ticks
> > + - const: 3
> > + description: 1024 ticks
Can we just make the number of ticks the unit here, and above?
Also, a "oneOf: - const" structure is just an enum.
> > + default: 3
> > +
> > + sample-cycle-us:
> > + description: Period between samples
> > + default: 1000000
No constraints?
Thanks,
Conor.
> > +
> > + '#thermal-sensor-cells':
> > + const: 0
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - clock-names
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/clock/sophgo,cv1800.h>
> > + thermal-sensor@30e0000 {
> > + compatible = "sophgo,cv180x-thermal";
> > + reg = <0x30e0000 0x100>;
> > + clocks = <&clk CLK_TEMPSEN>;
> > + clock-names = "clk_tempsen";
> > + #thermal-sensor-cells = <0>;
> > + };
> > +...
>
> Where is the interrupt number? The sensors does support the interrupt,
> but I don't see you describe it in the binding.
>
> > --
> > 2.45.2
> >
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-06-05 17:54 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 12:51 [PATCH v2 0/3] riscv: sophgo: add thermal sensor support for cv180x/sg200x SoCs Haylen Chu
2024-06-04 12:51 ` Haylen Chu
2024-06-04 12:54 ` [PATCH v2 1/3] dt-bindings: thermal: sophgo,cv180x-thermal: Add Sophgo CV180x thermal Haylen Chu
2024-06-04 12:54 ` Haylen Chu
2024-06-05 3:40 ` Inochi Amaoto
2024-06-05 3:40 ` Inochi Amaoto
2024-06-05 17:54 ` Conor Dooley [this message]
2024-06-05 17:54 ` Conor Dooley
2024-06-06 13:32 ` Haylen Chu
2024-06-06 13:32 ` Haylen Chu
2024-06-06 17:05 ` Conor Dooley
2024-06-06 17:05 ` Conor Dooley
2024-06-18 7:56 ` Haylen Chu
2024-06-18 7:56 ` Haylen Chu
2024-06-04 12:54 ` [PATCH v2 2/3] riscv: dts: sophgo: cv18xx: Add sensor device and thermal zone Haylen Chu
2024-06-04 12:54 ` Haylen Chu
2024-06-06 20:34 ` kernel test robot
2024-06-06 20:34 ` kernel test robot
2024-06-04 12:54 ` [PATCH v2 3/3] thermal: cv180x: Add cv180x thermal driver support Haylen Chu
2024-06-04 12:54 ` Haylen Chu
2024-06-06 22:36 ` Inochi Amaoto
2024-06-06 22:36 ` Inochi Amaoto
2024-06-17 11:35 ` Inochi Amaoto
2024-06-17 11:35 ` Inochi Amaoto
2024-06-17 15:01 ` Jisheng Zhang
2024-06-17 15:01 ` Jisheng Zhang
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=20240605-tightwad-janitor-82cfceb1469d@spud \
--to=conor@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=conor+dt@kernel.org \
--cc=daniel.lezcano@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=heylenay@outlook.com \
--cc=inochiama@outlook.com \
--cc=jszhang@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lukasz.luba@arm.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rui.zhang@intel.com \
--cc=unicorn_wang@outlook.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.