[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXMV2uMEr4gkNc4rzAJQ1YfL5=j=mGVksEaQQABh8iGcQ@mail.gmail.com>
Date: Tue, 3 Sep 2024 09:40:24 +0200
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Biju Das <biju.das.jz@...renesas.com>
Cc: "Claudiu.Beznea" <claudiu.beznea@...on.dev>,
"geert+renesas@...der.be" <geert+renesas@...der.be>,
"mturquette@...libre.com" <mturquette@...libre.com>, "sboyd@...nel.org" <sboyd@...nel.org>,
"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
"conor+dt@...nel.org" <conor+dt@...nel.org>,
"alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
"magnus.damm@...il.com" <magnus.damm@...il.com>, "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
Subject: Re: [PATCH v3 01/12] dt-bindings: clock: renesas,r9a08g045-vbattb:
Document VBATTB
Hi Biju,
On Tue, Sep 3, 2024 at 9:36 AM Biju Das <biju.das.jz@...renesas.com> wrote:
> > -----Original Message-----
> > From: claudiu beznea <claudiu.beznea@...on.dev>
> > Sent: Tuesday, September 3, 2024 8:28 AM
> > Subject: Re: [PATCH v3 01/12] dt-bindings: clock: renesas,r9a08g045-vbattb: Document VBATTB
> >
> > On 03.09.2024 09:58, Biju Das wrote:
> > >> -----Original Message-----
> > >> From: Claudiu <claudiu.beznea@...on.dev>
> > >> Sent: Friday, August 30, 2024 2:02 PM
> > >> Subject: [PATCH v3 01/12] dt-bindings: clock:
> > >> renesas,r9a08g045-vbattb: Document VBATTB
> > >>
> > >> From: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> > >>
> > >> The VBATTB IP of the Renesas RZ/G3S SoC controls the clock for RTC,
> > >> the tamper detector and a small general usage memory of 128B. Add documentation for it.
> > >>
> > >> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> > >> ---
> > >>
> > >> Changes in v3:
> > >> - moved the file to clock dt bindings directory as it is the
> > >> only functionality supported at the moment; the other functionalities
> > >> (tamper detector, SRAM) are offered though register spreaded
> > >> though the address space of the VBATTB IP and not actually
> > >> individual devices; the other functionalities are not
> > >> planned to be supported soon and if they will be I think they
> > >> fit better on auxiliary bus than MFD
> > >> - dropped interrupt names as requested in the review process
> > >> - dropped the inner node for clock controller
> > >> - added #clock-cells
> > >> - added rtx clock
> > >> - updated description for renesas,vbattb-load-nanofarads
> > >> - included dt-bindings/interrupt-controller/irq.h in examples section
> > >>
> > >> Changes in v2:
> > >> - changed file name and compatible
> > >> - updated title, description sections
> > >> - added clock controller part documentation and drop dedicated file
> > >> for it included in v1
> > >> - used items to describe interrupts, interrupt-names, clocks, clock-names,
> > >> resets
> > >> - dropped node labels and status
> > >> - updated clock-names for clock controller to cope with the new
> > >> logic on detecting the necessity to setup bypass
> > >>
> > >> .../clock/renesas,r9a08g045-vbattb.yaml | 81 +++++++++++++++++++
> > >> 1 file changed, 81 insertions(+)
> > >> create mode 100644
> > >> Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbattb.yaml
> > >>
> > >> diff --git
> > >> a/Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbattb.ya
> > >> ml
> > >> b/Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbattb.ya
> > >> ml
> > >> new file mode 100644
> > >> index 000000000000..29df0e01fae5
> > >> --- /dev/null
> > >> +++ b/Documentation/devicetree/bindings/clock/renesas,r9a08g045-vbatt
> > >> +++ b.y
> > >> +++ aml
> > >> @@ -0,0 +1,81 @@
> > >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > >> +---
> > >> +$id:
> > >> +http://devicetree.org/schemas/clock/renesas,r9a08g045-vbattb.yaml#
> > >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > >> +
> > >> +title: Renesas Battery Backup Function (VBATTB)
> > >> +
> > >> +description:
> > >> + Renesas VBATTB is an always on powered module (backed by battery)
> > >> +which
> > >> + controls the RTC clock (VBATTCLK), tamper detection logic and a
> > >> +small
> > >> + general usage memory (128B).
> > >> +
> > >> +maintainers:
> > >> + - Claudiu Beznea <claudiu.beznea.uj@...renesas.com>
> > >> +
> > >> +properties:
> > >> + compatible:
> > >> + const: renesas,r9a08g045-vbattb
> > >> +
> > >> + reg:
> > >> + maxItems: 1
> > >> +
> > >> + interrupts:
> > >> + items:
> > >> + - description: tamper detector interrupt
> > >> +
> > >> + clocks:
> > >> + items:
> > >> + - description: VBATTB module clock
> > >> + - description: RTC input clock (crystal oscillator or external
> > >> + clock device)
> > >> +
> > >> + clock-names:
> > >> + items:
> > >> + - const: bclk
> > >> + - const: rtx
> > >> +
> > >> + '#clock-cells':
> > >> + const: 1
> > >> +
> > >> + power-domains:
> > >> + maxItems: 1
> > >
> > > Not sure, you need to document "PD_VBATT" power domain as per Table
> > > 41.2, this LSI supports 3 power domains(PD_ISOVCC, PD_VCC, PD_VBATT)
> > >
> > > Power Mode PD_ISOVCC PD_VCC PD_VBATT
> > > ALL_ON ON ON ON
> > > AWO OFF ON ON
> > > VBATT OFF OFF ON
> > > ALL_OFF OFF OFF OFF
> > >
> > > PD_VBATT domain is the area where the RTC/backup register is located,
> > > works on battery power when the power of PD_VCC and PD_ISOVCC domain are turned off.
> >
> > In Linux, the CPG is the power domain provider for all the IPs in RZ/G3S SoC (modeled though MSTOP CPG
> > support). This is how it is currently implemented.
> >
> > Then groups of IPs are part of power domains PD_ISOVCC, PD_VCC, PD_VBATT.
> > These power domains are i2c controlled with the help of firmware (at least at the moment).
> >
> > From HW manual:
> > - PD_VCC domain always powered on area.
> >
> > - PD_ISOVCC domain is the area where the power can be turned off.
> >
> > - PD_VBATT domain is the area where the RTC/backup register is located,
> > works on battery power when the power of .
> >
> > The power to these domains are controlled with the help of firmware. Linux cannot do control itself as
> > the CPU is in the PD_ISOVCC. If you look at picture 41.3 Power mode transition [1] it is mentioned the
> > relation b/w these power domains (controlled by PMIC though firmware) and the supported power saving
> > modes: ALL_ON, AWO, VBATT.
>
> DT describes hardware. So, the question was, from that perspective, do we need to document PD_VBATT domain,
> as it can be controlled outside linux??
No, as it is controlled by an external entity, outside the system you
are describing.
DT also doesn't describe external power input, power switches, power cords,
low/medium/high voltage circuit breakers, nuclear power plants, the Sun, ...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Powered by blists - more mailing lists