Message ID | 20240227084008.2086287-1-lukas.funke-oss@weidmueller.com |
---|---|
State | Superseded |
Delegated to: | Michal Simek |
Headers | show |
Series | arm64: zynqmp: Add label to pmu fwnode | expand |
On 2/27/24 09:40, lukas.funke-oss@weidmueller.com wrote: > From: Lukas Funke <lukas.funke@weidmueller.com> > > Some zynqmp SoCs (the cg series) only have two cpus. Thus, for some > cases the cpu-affinity has to adapted, because cpu3 and cpu4 are interrupt-affinity right? > missing. By adding a label to the pmu fwnode the cpu affinity can > be adapted in a device specific dt. Why do you need to do it? What problem do you have if you don't change it? It shouldn't be different compare to max_cpus=2 right? > > Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com> > --- > arch/arm/dts/zynqmp.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi > index b50b83b772..457f8e394f 100644 > --- a/arch/arm/dts/zynqmp.dtsi > +++ b/arch/arm/dts/zynqmp.dtsi > @@ -168,7 +168,7 @@ > bootph-all; > }; > > - pmu { > + pmu: pmu { > compatible = "arm,armv8-pmuv3"; > interrupt-parent = <&gic>; > interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>, And I actually prefer to have labels for all nodes to be able to reference it. That's why patch itself is good. Thanks, Michal
On 27.02.2024 09:45, Michal Simek wrote: > > > On 2/27/24 09:40, lukas.funke-oss@weidmueller.com wrote: >> From: Lukas Funke <lukas.funke@weidmueller.com> >> >> Some zynqmp SoCs (the cg series) only have two cpus. Thus, for some >> cases the cpu-affinity has to adapted, because cpu3 and cpu4 are > > interrupt-affinity right? Duh. Can you update the message accordingly or should I send a new version? > > >> missing. By adding a label to the pmu fwnode the cpu affinity can >> be adapted in a device specific dt. > > Why do you need to do it? What problem do you have if you don't change it? > It shouldn't be different compare to max_cpus=2 right? We remove the cpu nodes for our cg devices in order to have a dt that really reflects the hardware. This way one does not have to pass additional parameters to the kernel. Unfortunately if the cpu nodes are missing dtc complaits about them due to the interrupt-affinity property. Since you seem surprised by this: is this the correct way? > >> >> Signed-off-by: Lukas Funke <lukas.funke@weidmueller.com> >> --- >> arch/arm/dts/zynqmp.dtsi | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi >> index b50b83b772..457f8e394f 100644 >> --- a/arch/arm/dts/zynqmp.dtsi >> +++ b/arch/arm/dts/zynqmp.dtsi >> @@ -168,7 +168,7 @@ >> bootph-all; >> }; >> - pmu { >> + pmu: pmu { >> compatible = "arm,armv8-pmuv3"; >> interrupt-parent = <&gic>; >> interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>, > > And I actually prefer to have labels for all nodes to be able to > reference it. > That's why patch itself is good. > > Thanks, > Michal Best regards Lukas
On 2/27/24 09:57, Lukas Funke wrote: > On 27.02.2024 09:45, Michal Simek wrote: >> >> >> On 2/27/24 09:40, lukas.funke-oss@weidmueller.com wrote: >>> From: Lukas Funke <lukas.funke@weidmueller.com> >>> >>> Some zynqmp SoCs (the cg series) only have two cpus. Thus, for some >>> cases the cpu-affinity has to adapted, because cpu3 and cpu4 are >> >> interrupt-affinity right? > > Duh. Can you update the message accordingly or should I send a new version? new version please. > >> >> >>> missing. By adding a label to the pmu fwnode the cpu affinity can >>> be adapted in a device specific dt. >> >> Why do you need to do it? What problem do you have if you don't change it? >> It shouldn't be different compare to max_cpus=2 right? > > We remove the cpu nodes for our cg devices in order to have a dt that really > reflects the hardware. This way one does not have to pass additional parameters > to the kernel. Unfortunately if the cpu nodes are missing dtc complaits about > them due to the interrupt-affinity property. > > Since you seem surprised by this: is this the correct way? At the end of a day it is up to you which way you choose. Removing unused cpus and aligning pmu is likely the best static way to go. max_cpus=2 is another way. And definitely I would also check that even on CG device you can have unchanged DT and firmware will just reject psci up request for cpu2/cpu3. It means OS send request for cpu2/3 up and firmware will reject that request. Back to your system. I expect you are making product out of it that's why likely make no sense to keep pmu even in DT. And for removing that node you don't need to have pmu there at all. / { /delete-node/ pmu; }; What about this description? ZynqMP CG series only have two cpus. When cpu3/4 are removed from DT there are missing references to these nodes in pmu interrupt-affinity DT property. To make alignment easier provide the label to pmu node for adaption in a device specific DT. On production systems the whole pmu node should be likely removed or at least disabled via status property that's why label can be also useful in this case. Thanks, Michal
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi index b50b83b772..457f8e394f 100644 --- a/arch/arm/dts/zynqmp.dtsi +++ b/arch/arm/dts/zynqmp.dtsi @@ -168,7 +168,7 @@ bootph-all; }; - pmu { + pmu: pmu { compatible = "arm,armv8-pmuv3"; interrupt-parent = <&gic>; interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,