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

[Xingyu Wu]

On 2026/5/22 00:42, Conor Dooley wrote:
> 
> On Thu, May 21, 2026 at 12:39:49PM +0100, Jonathan Cameron wrote:
> > On Thu, 21 May 2026 11:20:52 +0100
> > Conor Dooley <conor@xxxxxxxxxx> wrote:
> >
> > > On Thu, May 21, 2026 at 09:54:27AM +0000, Xingyu Wu wrote:
> > > > 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,jhb
> > > > > > > > > > 100-sara
> > > > > > > > > > dc.y
> > > > > > > > > > aml
> > > > > > > > > >
> > > > > > > > > > diff --git
> > > > > > > > > > a/Documentation/devicetree/bindings/iio/adc/starfive,j
> > > > > > > > > > hb100-sa
> > > > > > > > > > radc
> > > > > > > > > > .yam
> > > > > > > > > > l
> > > > > > > > > > b/Documentation/devicetree/bindings/iio/adc/starfive,j
> > > > > > > > > > hb100-sa
> > > > > > > > > > radc
> > > > > > > > > > .yam
> > > > > > > > > > l
> > > > > > > > > > new file mode 100644
> > > > > > > > > > index 000000000000..ba8e19b72ad7
> > > > > > > > > > --- /dev/null
> > > > > > > > > > +++ b/Documentation/devicetree/bindings/iio/adc/starfi
> > > > > > > > > > +++ ve,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.
> > >
> > > All that does is repeat the 1800 mV though, what I am interested in
> > > is how someone determines if they should use 1600 mV or 200 mV etc.
> > > What aspect of the hardware do the bounds depend on?
> >
> > There are two options here
> > 1. This is critical stuff to avoid hardware damage. (If you are relying on
> >    Linux for that you built your system wrong but if we ignore that...)
> >    Then userspace control should not be possible - or at least should
> >    only be able to move boundaries in directions that make them tighter.
> > 2. It is advisory only and not related to hardware damage - in that case
> >    generally doesn't belong in DT.
> 
> Per Xingyu's latest response
> | These bounds are just for the monitor mode. If the input voltage is outside this
> range, interrupt will be triggered to report the user space.
> | The bounds value (1600mv or 200mv) are determined by the users' applications.
> Users can freely set them according to the range they want to monitor.
> it controls the level at which interrupts occur, and is therefore not suitable for DT.
> 

OK, I will drop them in DT and use IIO event to set them in driver by user.

Best regards,
Xingyu Wu