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

[Conor Dooley]

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,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.  
> > 
> > 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.

Cheers,
Conor.

Attachment: signature.asc
Description: PGP signature