On Thu, 10 Feb 2022 19:34:59 +0000,
Nishanth Menon <nm@xxxxxx> wrote:
>
> On 19:10-20220209, Marc Zyngier wrote:
> [...]
>
> > > +&cbass_main {
> > > + gic500: interrupt-controller@1800000 {
> > > + compatible = "arm,gic-v3";
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + ranges;
> > > + #interrupt-cells = <3>;
> > > + interrupt-controller;
> > > + reg = <0x00 0x01800000 0x00 0x10000>, /* GICD */
> > > + <0x00 0x01880000 0x00 0xC0000>; /* GICR */
> >
> > Usual rant: you are missing the GICC, GICH and GICV regions
> > that are implemented by the CPU. Cortex-A53 implements them
> > (they are not optional), so please describe them.
> >
>
>
> -ECONFUSED. TRM for GIC500 refers to just GICD, GICR and ITS range[1].
And I'm not talking about the GIC, but of the CPU interface. The fact
that we describe both in the GIC binding doesn't mean they are
implemented by the same IP block (and the architecture is quite clear
about that).
> Same thing is indicated by Generic Interrupt Controller Architecture
> Specification[2] See table 1-1 (page 23).
>
> I think you are expecting GICV3's backward compatibility mode (Table 1-2
> in page 24), But in K3 architecture, are_option meant for backward
> compatibility is set to true (aka no backward compatibility). I think
> this did popup sometime back as well (first k3 SoC)[3]. I think the more
> clearer description is available in [4].
No, this description is for the architecture as a whole. ARE being
disabled *int the GIC* doesn't mean it is disabled overall, and the
CPU is free to implement the CPU interface by any mean it wants as
long as it communicates with the GIC using the Stream Protocol.
Cortex-A32, A34, 35, A53, A57, A72 and A73 all implement both the
sysreg and MMIO CPU interfaces. Later ARM CPUs don't. Both can work
with GIC500.
> I believe the argumentation that GICC/H/V is mandatory for A53 if GIC500
> is used is not accurate. Please correct me if I am mistaken.
GIC500 is not involved at all, and A53 always implements both the
system register and MMIO interfaces. See the A53 TRM, chapter 9. The
only way to disable this interface is to assert GICCDISABLE, which
disables the whole of the CPU interface. Given that you have a (more
or less) functional system, it probably isn't the case.
See Table 9-1, which tells you where these registers are as an offset
from PERIPHBASE. Dumping these registers should show you that they are
indeed implemented and not solely a figment of my own imagination.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
