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

Thomas Bonnefille
2024-07-08T15:10:44Z

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