Hi, Geert, On 18.06.2024 10:56, Geert Uytterhoeven wrote: > Hi Claudiu, > > On Tue, Jun 18, 2024 at 9:34 AM claudiu beznea <claudiu.beznea@xxxxxxxxx> wrote: >> 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@xxxxxxxxxxxxxx> >>>>>> >>>>>> 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@xxxxxxxxxxxxxx> >>>>>> --- >>>>>> .../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 >>>>>> + renesas,vbattb-osc-bypass: >>>>>> + description: set when external clock is connected to RTXOUT pin > > FTR, this contradicts the explanation below, which states the external > clock oscillator is connected to RTXIN. I agree. > >>>>>> + 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. > > Sounds similar to the RAA215300 PMIC, which includes an ISL1208-derived > RTC, where this was handled using two different clock names: > https://elixir.bootlin.com/linux/v6.10-rc1/source/Documentation/devicetree/bindings/regulator/renesas,raa215300.yaml#L49 > https://elixir.bootlin.com/linux/v6.10-rc1/source/drivers/rtc/rtc-isl1208.c#L869 Yes, seem similar. I wasn't aware of this approach. I'll switch to it. Thank you, Claudiu Beznea > > Gr{oetje,eeting}s, > > Geert >
