Re: [PATCH 02/12] dt-bindings: clock: renesas,rzg3s-vbattb-clk: Document the VBATTB clock driver

[claudiu beznea <claudiu.beznea@tuxon.dev>]

On 17.06.2024 18:19, Conor Dooley wrote:
> On Mon, Jun 17, 2024 at 10:02:47AM +0300, claudiu beznea wrote:
>>
>>
>> On 15.06.2024 15:17, Conor Dooley wrote:
>>> On Fri, Jun 14, 2024 at 10:19:22AM +0300, Claudiu wrote:
>>>> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>>
>>>> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock that feeds
>>>> the RTC and the tamper detector. Add documentation for the VBATTB clock
>>>> driver.
>>>>
>>>> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>> ---
>>>>  .../clock/renesas,rzg3s-vbattb-clk.yaml       | 90 +++++++++++++++++++
>>>>  1 file changed, 90 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml
>>>> new file mode 100644
>>>> index 000000000000..ef52a0c0f874
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/renesas,rzg3s-vbattb-clk.yaml
>>>> @@ -0,0 +1,90 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/clock/renesas,rzg3s-vbattb-clk.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Renesas VBATTB clock
>>>> +
>>>> +maintainers:
>>>> +  - Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>>>> +
>>>> +description:
>>>> +  Renesas VBATTB module is an always on powered module (backed by battery) which
>>>> +  generates a clock (VBATTCLK). This clocks feeds the RTC and the tamper detector
>>>> +  modules.
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    const: renesas,rzg3s-vbattb-clk
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clocks:
>>>> +    items:
>>>> +      - description: VBATTB module clock
>>>> +      - description: VBATTB input xtal
>>>> +
>>>> +  clock-names:
>>>> +    items:
>>>> +      - const: bclk
>>>> +      - const: vbattb_xtal
>>>> +
>>>> +  '#clock-cells':
>>>> +    const: 0
>>>> +
>>>> +  power-domains:
>>>> +    maxItems: 1
>>>> +
>>>> +  renesas,vbattb-load-nanofarads:
>>>> +    description: load capacitance of the on board xtal
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>>> +    enum: [ 4000, 7000, 9000, 12500 ]
>>>> +
>>>> +  renesas,vbattb-osc-bypass:
>>>> +    description: set when external clock is connected to RTXOUT pin
>>>> +    type: boolean
>>>
>>> When you say "external clock", is that an input or an output?
>>
>> I took that statement from the HW manual. As of the HW manual [1], table
>> 42.2, that would be an input.
> 
> Forgive me for not wanting to open the zip etc and find the information
> in the document, but why do you need an extra property? Is it not
> something you can determine from the clocks/clock-names properties?

It can't be determined from clocks/clock-names as of my understanding. It
depends on the type of the input clock (crystal oscillator or external
hardware device generating the clock).

> It sounds like an additional clock from your description, is it actually
> different way to provide the second clock you mention above?

This is the block diagram (see [1], only picture this time) of the module
controlling the clock. Please open it, it helps in understanding what I'll
explain above.

The VBATTB blocks controlling the VBATTBCLK are:
- 32KHz-clock oscillator
- the mux controlled by BKSCCR.SOSEL
- the gate who's input is the mux output and XOSCCR.OUTEN

To the 32 KHz-clock oscillator block could be connected:
1/ either a crystal oscillator in which case it will be connected to both
RTXIN and RTXOUT pins (the direction of RTXOUT is wrong in this picture for
this case)
2/ or a device (like [2]) generating a clock which has a single output and,
from my understanding and experience with devices like this, only RTXIN is
needed, RTXOUT is connected to the ground; for this case the 32KHz-clock
oscillator block from [1] need to be bypassed in which case the newly
introduced property will be used; this will select the XBYP on the mux.

Thank you,
Claudiu Beznea

[1] https://pasteboard.co/QYsCvhfQlX6n.png
[2]
https://ro.mouser.com/datasheet/2/268/DSC1001_3_4_1_8V_3_3V_Low_Power_Precision_CMOS_Osc-3314582.pdf

> 
>>
>> [1]
>> https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz-mpus/rzg3s-general-purpose-microprocessors-single-core-arm-cortex-a55-11-ghz-cpu-and-dual-core-cortex-m33-250
>>