Re: [PATCH v2 1/3] dt-bindings: iio: adc: sophgo,cv18xx-saradc.yaml: Add Sophgo SARADC binding documentation

[Thomas Bonnefille]

On 7/6/24 2:42 PM, Conor Dooley wrote:
> On Fri, Jul 05, 2024 at 05:24:19PM +0200, Thomas Bonnefille wrote:
> > On 7/5/24 5:01 PM, Conor Dooley wrote:
> > > On Fri, Jul 05, 2024 at 03:42:23PM +0200, Thomas Bonnefille wrote:
> > > > The Sophgo SARADC is a Successive Approximation ADC that can be found in
> > > > the Sophgo SoC.
> > > >
> > > > Signed-off-by: Thomas Bonnefille <thomas.bonnefille@xxxxxxxxxxx>
> > > > ---
> > > >    .../bindings/iio/adc/sophgo,cv18xx-saradc.yaml     | 63 ++++++++++++++++++++++
> > > >    1 file changed, 63 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/iio/adc/sophgo,cv18xx-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/sophgo,cv18xx-saradc.yaml
> > > > new file mode 100644
> > > > index 000000000000..31bd8ac6dfa5
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/iio/adc/sophgo,cv18xx-saradc.yaml
> > > > @@ -0,0 +1,63 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/iio/adc/sophgo,cv18xx-saradc.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title:
> > > > +  Sophgo CV18XX SoC series 3 channels Successive Approximation Analog to
> > > > +  Digital Converters
> > > > +
> > > > +maintainers:
> > > > +  - Thomas Bonnefille <thomas.bonnefille@xxxxxxxxxxx>
> > > > +
> > > > +description:
> > > > +  Datasheet at https://github.com/sophgo/sophgo-doc/releases
> > > > +
> > > > +properties:
> > > > +  compatible:
> > > > +    oneOf:
> > > > +      - items:
> > > > +          - enum:
> > > > +              - sophgo,cv1800b-saradc
> > > > +          - const: sophgo,cv18xx-saradc
> > >
> > > I don't think the fallback here makes sense. If there's other devices
> > > with a compatible programming model added later, we can fall back to the
> > > cv1800b.
> >
> > Ok I'll do that, I wasn't sure if it was a good practice to fallback on
> > another SoC specific compatible.
> >
> > > > +
> > > > +  reg:
> > > > +    maxItems: 1
> > > > +
> > > > +  interrupts:
> > > > +    maxItems: 1
> > > > +
> > > > +  clocks:
> > > > +    description:
> > > > +      SARADC will use the presence of this clock to determine if the controller
> > > > +      needs to be explicitly clocked by it (Active domain) or if it is part of
> > > > +      the No-Die Domain, along with the RTC, which does not require explicit
> > > > +      clocking.
> > >
> > > What does "explicit clocking" mean? Is it clocked directly (or via
> > > dividers) by a clock on the board or another source?
> >
> > It means that, if a clock is provided, the driver will work in "Active
> > Domain" and will use the clock generator of the SoC to get the right clock
> > signal.
> >
> > However if no clock is provided, the controller will work in "No-Die" domain
> > (Always On) and use the RTCSYS subsystem to get its clock signal.
>
> So it does have a clock, but provided by a different provider. I don't
> really understand why that would "excuse" it from having a clocks
> property, with the RTCSYS as the provider.

By digging into the datasheet, I discovered that there might be a way to 
use a valid clock as the input of the No-Die domain ADC. I would like to 
ask Inochi about this, as he wrote the clock driver for this SoC.

As I understand it, the SARADC working in the No-Die domain is fed, like 
every other IP in the No-Die domain, by the CLK_SRC_RTC_SYS_0. This 
clock source is either a division of the main oscillator (referred to as 
osc_parents in the clock driver) or "xtal," which is an external 
oscillator. Am I right? What is the role of CLK_RTC_24M?

If I'm correct, this description isn't needed anymore in the bindings, 
and the device tree node for the SARADC in the No-Die domain will need 
this line:

+                       clocks = <&clk CLK_SRC_RTC_SYS_0>;