RE: [PATCH v1 1/2] bindings: iio: adc: Add StarFive JHB100 SARADC

[Xingyu Wu]

On 2026/5/20 23:15, Conor Dooley wrote:
> 
> On Wed, May 20, 2026 at 09:43:02AM +0000, Xingyu Wu wrote:
> > On 2026/5/19 18:00, Conor Dooley wrote:
> > >
> > > On Tue, May 19, 2026 at 09:26:03AM +0000, Xingyu Wu wrote:
> > > > On 2026/5/19 00:24, Conor Dooley wrote:
> > > > >
> > > > > On Mon, May 18, 2026 at 04:18:51PM +0800, Xingyu Wu wrote:
> > > > > > Add the new documentation of SAR-ADC for the StarFive JHB100 SoC.
> > > > > >
> > > > > > Signed-off-by: Xingyu Wu <xingyu.wu@xxxxxxxxxxxxxxxx>
> > > > > > ---
> > > > > >  .../iio/adc/starfive,jhb100-saradc.yaml       | 62 +++++++++++++++++++
> > > > > >  1 file changed, 62 insertions(+)  create mode 100644
> > > > > > Documentation/devicetree/bindings/iio/adc/starfive,jhb100-sara
> > > > > > dc.y
> > > > > > aml
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/iio/adc/starfive,jhb100-sa
> > > > > > radc
> > > > > > .yam
> > > > > > l
> > > > > > b/Documentation/devicetree/bindings/iio/adc/starfive,jhb100-sa
> > > > > > radc
> > > > > > .yam
> > > > > > l
> > > > > > new file mode 100644
> > > > > > index 000000000000..ba8e19b72ad7
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/devicetree/bindings/iio/adc/starfive,jhb10
> > > > > > +++ 0-sa
> > > > > > +++ radc
> > > > > > +++ .yaml
> > > > > > @@ -0,0 +1,62 @@
> > > > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) %YAML
> > > > > > +1.2
> > > > > > +---
> > > > > > +$id:
> > > > > > +http://devicetree.org/schemas/iio/adc/starfive,jhb100-saradc.
> > > > > > +yaml
> > > > > > +#
> > > > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > +
> > > > > > +title: Successive Approximation Register (SAR) A/D converter
> > > > > > +for the StarFive JHB100 SoC
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Xingyu Wu <xingyu.wu@xxxxxxxxxxxxxxxx>
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +    const: starfive,jhb100-saradc
> > > > > > +
> > > > > > +  reg:
> > > > > > +    maxItem: 1
> > > > > > +
> > > > > > +  interrupts:
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  clocks:
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  resets:
> > > > > > +    maxItems: 2
> > > > > > +
> > > > > > +  "#io-channel-cells":
> > > > > > +    const: 1
> > > > > > +
> > > > > > +  upper-bound-mv:
> > > > > > +    description: The upper bound voltage value of the monitor.
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint16
> > > > > > +
> > > > > > +  lower-bound-mv:
> > > > > > +    description: The lower bound voltage value of the monitor.
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint16
> > > > > > +
> > > > > > +  scan-freq:
> > > > > > +    description: Number of the scan cycle interval.
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint16
> > > > >
> > > > > Can you explain why any of these three properties are something
> > > > > that should be in the devicetree rather than software controlled?
> > > >
> > > > My intention is to be able to obtain the initial values from the
> > > > devicetree during
> > > probe and preset them.
> > > > Do I need to drop them and just set them through sysfs?
> > >
> > > Unless the hardware configuration determines the values (which I
> > > can't really see being the case for scan-freq at least) then yes,
> > > you need to drop and set them via sysfs.
> >
> > The ADC hardware can be set the scan-freq register to determine how frequent it
> should scan its inputs.
> > The calculation is:
> > 	frequency = 100/((register value) + 5) MHz, The register value should >= 15.
> > The maximum allowable scan frequency is 5MHz.
> >
> > >
> > > > > How are the bounds calculated?
> > > >
> > > > The measurement range of this ADC hardware is from 0 to 1800 mV.
> > > > This set
> > > value cannot exceed it. This explanation will be added later.
> > >
> > > I'm asking how this is calculated so that I can tell if you the
> > > property is permitted or not.
> >
> > The calculation of bound is:
> > bound-mv = 1800mv * (register value) / 0xFFF
> 
> These are the formulas, but how does someone know what the value for bound-
> mv needs to be? Why would someone not just want to always use 1800mv?
> 

Can I add the 'maximum' and ' minimum' to provide clarification? And the driver will also check.

Best regards,
Xingyu Wu