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

From: Conor Dooley

Date: Wed May 20 2026 - 11:32:20 EST


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-saradc.y
> > > > > aml
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/iio/adc/starfive,jhb100-saradc
> > > > > .yam
> > > > > l
> > > > > b/Documentation/devicetree/bindings/iio/adc/starfive,jhb100-saradc
> > > > > .yam
> > > > > l
> > > > > new file mode 100644
> > > > > index 000000000000..ba8e19b72ad7
> > > > > --- /dev/null
> > > > > +++ b/Documentation/devicetree/bindings/iio/adc/starfive,jhb100-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?

>
> Best regards,
> Xingyu Wu
>

Attachment: signature.asc
Description: PGP signature