Re: [PATCH v3 6/6] arm64: dts: cix: add initial CIX P1(SKY1) dts support

[Marc Zyngier <maz@kernel.org>]

On Mon, 03 Mar 2025 11:38:47 +0000,
Peter Chen <peter.chen@cixtech.com> wrote:
> 
> On 25-02-28 15:10:24, Marc Zyngier wrote:
> 
> Hi Marc,
> 
> Thanks for your detail review.
> 
> > > +
> > > +             cpu10: cpu@a00 {
> > > +                     compatible = "arm,cortex-a720";
> > > +                     enable-method = "psci";
> > > +                     reg = <0x0 0xa00>;
> > > +                     device_type = "cpu";
> > > +                     capacity-dmips-mhz = <1024>;
> > > +             };
> > > +
> > > +             cpu11: cpu@b00 {
> > > +                     compatible = "arm,cortex-a720";
> > > +                     enable-method = "psci";
> > > +                     reg = <0x0 0xb00>;
> > > +                     device_type = "cpu";
> > > +                     capacity-dmips-mhz = <1024>;
> > > +             };
> > 
> > Given that half the A720s are advertised with lower clock speed, how
> > comes they all have the same capacity?
> 
> According to Documentation/devicetree/bindings/cpu/cpu-capacity.txt
> "capacity-dmips-mhz" is u32 value representing CPU capacity expressed
> in normalized DMIPS/MHz, it means CPU capability per MHz. For sky1
> SoC, both middle and big cores are A720, so their capability per MHz
> are the same.

Ah, fair enough. I missed that detail.

> 
> > > +
> > > +     pmu-a520 {
> > > +             compatible = "arm,cortex-a520-pmu";
> > > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
> > > +     };
> > > +
> > > +     pmu-a720 {
> > > +             compatible = "arm,cortex-a720-pmu";
> > > +             interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>;
> > > +     };
> > 
> > This is wrong. The default configuration for PPIs is to expose the
> > *same* device on all CPUs. You must use PPI affinities for your PMUs.
> > Please see the GICv3 binding for the details.
> 
> We have discussed internally, we have not seen the benefits routing
> different PPI interrupt to dedicated CPUs. Any use cases?

This isn't about changing the PPI. It is about matching CPUs with
their PMU. Here, you are saying "both PMU types are connected to all
the CPUs using PPI7".

That's obviously not the case.

> I prefer changing pmu nodes as one generic Armv8 PMU node. Is it accepted?

No, that's not acceptable.

> Or must I keep both pmu for A520 and A720, and add PPI affinities to
> describe hardware well?

This is an established practice on all big-little systems: each PMU
node has an affinity that indicates which CPUs they are connected
to. For GICv3+, this is carried by the interrupt specifier.

Please look at existing SoCs supported, such as rk3399, for example.

> 
> > 
> > > +
> > > +     pmu-spe {
> > > +             compatible = "arm,statistical-profiling-extension-v1";
> > > +             interrupts = <GIC_PPI 5 IRQ_TYPE_LEVEL_LOW>;
> > > +     };
> > > +
> > > +     psci {
> > > +             compatible = "arm,psci-1.0";
> > > +             method = "smc";
> > > +     };
> > > +
> > > +     soc@0 {
> > > +             compatible = "simple-bus";
> > > +             ranges = <0 0 0 0 0x20 0>;
> > > +             dma-ranges;
> > > +             #address-cells = <2>;
> > > +             #size-cells = <2>;
> > > +
> > > +             gic: interrupt-controller@e010000 {
> > > +                     compatible = "arm,gic-v3";
> > > +                     reg = <0x0 0x0e010000 0 0x10000>,       /* GICD */
> > > +                           <0x0 0x0e090000 0 0x300000>;       /* GICR * 12 */
> > > +                     interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_LOW>;
> > > +                     #interrupt-cells = <3>;
> > 
> > This will need to be bumped up to 4, and all the interrupt specifiers adjusted.
> 
> Depends on if PPI affinities is must.

Definitely a must, unless you want to completely remove all traces of
the PMU, which is of course silly, but a valid alternative.

[...]

> > > +             arm,no-tick-in-suspend;
> > 
> > Why do you need this? Is the HW so broken that you have implemented
> > the global counter in a power domain that isn't always on?
> > 
> 
> Not hardware broken, just arch timer will be powered off at cpu idle
> and system suspend due to power consumption reason.

This is not about the timer. This is about the global counter. If your
counter stops ticking when you're in idle or suspended, your system is
broken and you need this property. If the timer (or more precisely the
comparator) is turned off because the CPU is off, then that's the
expected behaviour and you don't need this property.


-- 
Without deviation from the norm, progress is not possible.