Hi Biju,
On Wed, May 18, 2022 at 8:34 PM Biju Das <biju.das.jz@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx>
> > > > > +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@xxxxxxxxxxxxxx
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
