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

[Thomas Bonnefille <thomas.bonnefille@bootlin.com>]

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@bootlin.com>
>>>> ---
>>>>    .../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@bootlin.com>
>>>> +
>>>> +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>;