From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Biju Das <biju.das.jz@bp.renesas.com>
Cc: "Rob Herring" <robh@kernel.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Lee Jones" <lee.jones@linaro.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"linux-pwm@vger.kernel.org" <linux-pwm@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Chris Paterson" <Chris.Paterson2@renesas.com>,
"Biju Das" <biju.das@bp.renesas.com>,
"Prabhakar Mahadev Lad" <prabhakar.mahadev-lad.rj@bp.renesas.com>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: Re: [RFC 1/8] dt-bindings: soc: renesas: Add RZ/G2L POEG binding
Date: Thu, 19 May 2022 11:06:50 +0200 [thread overview]
Message-ID: <CAMuHMdWPy4HmPrfnL8kZmFBBcHY-EoNm7Z6CoJyudhKornTS=g@mail.gmail.com> (raw)
In-Reply-To: <OS0PR01MB5922BC7AAC6154DEF7B98F0386D19@OS0PR01MB5922.jpnprd01.prod.outlook.com>
Hi Biju,
On Wed, May 18, 2022 at 8:34 PM Biju Das <biju.das.jz@bp.renesas.com> wrote:
> > Subject: Re: [RFC 1/8] dt-bindings: soc: renesas: Add RZ/G2L POEG binding
> > On Wed, May 18, 2022 at 05:58:00AM +0000, Biju Das wrote:
> > > > Subject: Re: [RFC 1/8] dt-bindings: soc: renesas: Add RZ/G2L POEG
> > > > binding
> > > >
> > > > On Tue, May 10, 2022 at 04:11:05PM +0100, Biju Das wrote:
> > > > > Add device tree bindings for the RZ/G2L Port Output Enable for GPT
> > > > (POEG).
> > > > >
> > > > > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > > > > +examples:
> > > > > + - |
> > > > > + #include <dt-bindings/clock/r9a07g044-cpg.h>
> > > > > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > > +
> > > > > + poeggd: poeg@10049400 {
> > > > > + compatible = "renesas,r9a07g044-poeg", "renesas,rzg2l-poeg";
> > > > > + reg = <0x10049400 0x4>;
> > > >
> > > > This looks like it is part of some larger block?
> > >
> > > There are 2 IP blocks GPT(PWM) and POEG with its own resources like
> > > (register map, clk, reset and interrupts)
> > >
> > > Larger block is GPT, which has lot of functionalities. The output from
> > > GPT block can be disabled by this IP either by external trigger,
> > > request from GPT(Deadtime error, both output low/high) or explicit
> > > software control). This IP has only a single register. Currently I am not
> > sure which framework to be used for this IP?? Or should it be merged with
Yeah, POEG is a weird beast.
Some of it fits under pin control, but not all of it.
From a quick glance, most of its configuration is intended to be
static, i.e. could be done from DT, like pin control?
I have no idea how to use the POEG interrupts, though.
> > larger block GPT by combining the resources?
> >
> > Usually, IP blocks would have some minimum address alignment (typ 4K or 64K
> > to be page aligned), but if there's no other IP in this address range as-is
> > is fine. The question is what's before or after the above address?
>
> As per the HW manual, before GPT IP block and after POE3 block(Port Output Enable 3 (POE3) for MTU).
>
> Before
> H'0_1004_8000 H'0_1004_87FF 2 Kbytes GPT
>
> After
> H'0_1004_9800 H'0_1004_9BFF 1 Kbyte POE3
>
> Please find the address map for the IP blocks near to it.
>
> H'0_1004_A000 H'0_1004_A3FF 1 Kbyte SSIF ch1
> H'0_1004_9C00 H'0_1004_9FFF 1 Kbyte SSIF ch0
> H'0_1004_9800 H'0_1004_9BFF 1 Kbyte POE3
> H'0_1004_9400 H'0_1004_97FF 1 Kbyte POEGD
> H'0_1004_9000 H'0_1004_93FF 1 Kbyte POEGC
> H'0_1004_8C00 H'0_1004_8FFF 1 Kbyte POEGB
> H'0_1004_8800 H'0_1004_8BFF 1 Kbyte POEGA
> H'0_1004_8000 H'0_1004_87FF 2 Kbytes GPT
This is actually 8 x 256 bytes, for 8 GPT instances.
> H'0_1004_7000 H'0_1004_7FFF 4 Kbytes SRC (Reg)
> H'0_1004_0000 H'0_1004_6FFF 28 Kbytes SRC (Memory)
So you can combine GPT and POEG[A-D] into a single block.
However, doing so will make life harder when reusing the driver on
an SoC with a different layout, or a different number of POEG blocks
and GPT channels.
BTW, POE3 is a similar (in spirit) block on top of the MTU
(Multi-Function Timer Pulse Unit 3, which seems to be an
enhanced version of the already-supported MTU2 on RZ/A1?).
But the POE3 block is not located next to the MTU block, so you cannot
combine them without overlap.
Note that the minimum page size on Cortex-A seems to be 4 kiB, and
several blocks are spaced apart less, so even with a different OS
than Linux you cannot implement page-based access control.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
next prev parent reply other threads:[~2022-05-19 9:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-10 15:11 [RFC 0/8] Add RZ/G2L POEG support Biju Das
2022-05-10 15:11 ` [RFC 1/8] dt-bindings: soc: renesas: Add RZ/G2L POEG binding Biju Das
2022-05-17 21:04 ` Rob Herring
2022-05-18 5:58 ` Biju Das
2022-05-18 18:17 ` Rob Herring
2022-05-18 18:34 ` Biju Das
2022-05-19 9:06 ` Geert Uytterhoeven [this message]
2022-05-19 9:30 ` Biju Das
2022-05-19 20:04 ` Rob Herring
2022-06-08 16:11 ` Biju Das
2022-05-10 15:11 ` [RFC 3/8] dt-bindings: pwm: rzg2l-gpt: Document renesas,poeg-group property Biju Das
2022-05-10 18:29 ` Rob Herring
2022-05-10 15:11 ` [RFC 5/8] arm64: dts: renesas: r9a07g044: Add POEG nodes Biju Das
2022-05-10 15:11 ` [RFC 6/8] arm64: dts: renesas: r9a07g054: " Biju Das
2022-05-10 15:11 ` [RFC 7/8] arm64: dts: renesas: rzg2l-smarc: Enable POEGG{A,B,C,D} on carrier board Biju Das
2022-05-10 15:11 ` [RFC 8/8] arm64: dts: renesas: rzg2l-smarc: Link GPT4 with POEGGD " Biju Das
2022-05-10 16:00 ` [RFC 0/8] Add RZ/G2L POEG support Uwe Kleine-König
2022-05-10 16:08 ` Biju Das
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdWPy4HmPrfnL8kZmFBBcHY-EoNm7Z6CoJyudhKornTS=g@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=Chris.Paterson2@renesas.com \
--cc=biju.das.jz@bp.renesas.com \
--cc=biju.das@bp.renesas.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee.jones@linaro.org \
--cc=linux-pwm@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=prabhakar.mahadev-lad.rj@bp.renesas.com \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).