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. > > Indeed "explicitly clocked" may not be the right word to describe that, > maybe some thing like that is better : > > "SARADC will use the presence of this clock to determine if the controller > needs to use the clock generator to get its clock signal (Active domain) or > if it is part of the No-Die Domain, along with the RTC, and does not require > the clock generator."
Attachment:
signature.asc
Description: PGP signature
