arch/arm64/boot/dts/freescale/imx8mp.dtsi | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
So far, only WFI is supported on i.MX8mp platform. Add support for
deeper cpuidle state "cpu-pd-wait" that would allow for better power
usage during runtime. This is a port from NXP downstream kernel.
Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com>
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index f3531cfb0d79..8b1e0ca248d1 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -47,6 +47,20 @@ cpus {
#address-cells = <1>;
#size-cells = <0>;
+ idle-states {
+ entry-method = "psci";
+
+ cpu_pd_wait: cpu-pd-wait {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x0010033>;
+ local-timer-stop;
+ entry-latency-us = <1000>;
+ exit-latency-us = <700>;
+ min-residency-us = <2700>;
+ wakeup-latency-us = <1500>;
+ };
+ };
+
A53_0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
@@ -65,6 +79,7 @@ A53_0: cpu@0 {
nvmem-cell-names = "speed_grade";
operating-points-v2 = <&a53_opp_table>;
#cooling-cells = <2>;
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_1: cpu@1 {
@@ -83,6 +98,7 @@ A53_1: cpu@1 {
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
#cooling-cells = <2>;
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_2: cpu@2 {
@@ -101,6 +117,7 @@ A53_2: cpu@2 {
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
#cooling-cells = <2>;
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_3: cpu@3 {
@@ -119,6 +136,7 @@ A53_3: cpu@3 {
next-level-cache = <&A53_L2>;
operating-points-v2 = <&a53_opp_table>;
#cooling-cells = <2>;
+ cpu-idle-states = <&cpu_pd_wait>;
};
A53_L2: l2-cache0 {
base-commit: 58ca61c1a866bfdaa5e19fb19a2416764f847d75
prerequisite-patch-id: 0000000000000000000000000000000000000000
--
2.34.1Adding more people.
On 07/10/2024 15:44, Catalin Popescu wrote:
> So far, only WFI is supported on i.MX8mp platform. Add support for
> deeper cpuidle state "cpu-pd-wait" that would allow for better power
> usage during runtime. This is a port from NXP downstream kernel.
>
> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com>
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index f3531cfb0d79..8b1e0ca248d1 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -47,6 +47,20 @@ cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> + idle-states {
> + entry-method = "psci";
> +
> + cpu_pd_wait: cpu-pd-wait {
> + compatible = "arm,idle-state";
> + arm,psci-suspend-param = <0x0010033>;
> + local-timer-stop;
> + entry-latency-us = <1000>;
> + exit-latency-us = <700>;
> + min-residency-us = <2700>;
> + wakeup-latency-us = <1500>;
> + };
> + };
> +
> A53_0: cpu@0 {
> device_type = "cpu";
> compatible = "arm,cortex-a53";
> @@ -65,6 +79,7 @@ A53_0: cpu@0 {
> nvmem-cell-names = "speed_grade";
> operating-points-v2 = <&a53_opp_table>;
> #cooling-cells = <2>;
> + cpu-idle-states = <&cpu_pd_wait>;
> };
>
> A53_1: cpu@1 {
> @@ -83,6 +98,7 @@ A53_1: cpu@1 {
> next-level-cache = <&A53_L2>;
> operating-points-v2 = <&a53_opp_table>;
> #cooling-cells = <2>;
> + cpu-idle-states = <&cpu_pd_wait>;
> };
>
> A53_2: cpu@2 {
> @@ -101,6 +117,7 @@ A53_2: cpu@2 {
> next-level-cache = <&A53_L2>;
> operating-points-v2 = <&a53_opp_table>;
> #cooling-cells = <2>;
> + cpu-idle-states = <&cpu_pd_wait>;
> };
>
> A53_3: cpu@3 {
> @@ -119,6 +136,7 @@ A53_3: cpu@3 {
> next-level-cache = <&A53_L2>;
> operating-points-v2 = <&a53_opp_table>;
> #cooling-cells = <2>;
> + cpu-idle-states = <&cpu_pd_wait>;
> };
>
> A53_L2: l2-cache0 {
>
> base-commit: 58ca61c1a866bfdaa5e19fb19a2416764f847d75
> prerequisite-patch-id: 0000000000000000000000000000000000000000
On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > So far, only WFI is supported on i.MX8mp platform. Add support for > deeper cpuidle state "cpu-pd-wait" that would allow for better power > usage during runtime. This is a port from NXP downstream kernel. > > Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> Applied, thanks!
Hi Catalin, Shawn, On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: > On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > > So far, only WFI is supported on i.MX8mp platform. Add support for > > deeper cpuidle state "cpu-pd-wait" that would allow for better power > > usage during runtime. This is a port from NXP downstream kernel. > > Since the introduction of this patch in mainline, I am facing sluggish network performance with my Debix Model-A board with i.MX8mp SoC. The network latency jumps to >1s after almost every other packet: PING debix (10.0.42.5) 56(84) bytes of data. 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms ^C --- debix ping statistics --- 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 darkapex at freya in ~ If I revert the patch, or disable the deeper cpuidle state through sysfs, the issue goes away. # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable PING debix (10.0.42.5) 56(84) bytes of data. 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms ^C --- debix ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4051ms rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > > Signed-off-by: Catalin Popescu > > <catalin.popescu@leica-geosystems.com> > > Applied, thanks! > > Thanks, Jai
Hi Jai, This issue was already reported by Stefan. The problem is that I don't have a Debix board to investigate. The main difference b/w WFI and cpu-pd-wait is that the first doesn't call PSCI/TF-A. So, the issue looks to be related to some settings in the TF-A. What I don't get is why I don't see this issue neither on our IMX8MP specific design nor on the EVK, which uses the same PHY as the Debix board. BR, Catalin On 14/04/2025 14:07, Jai Luthra wrote: > Hi Catalin, Shawn, > > On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: >> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: >>> So far, only WFI is supported on i.MX8mp platform. Add support for >>> deeper cpuidle state "cpu-pd-wait" that would allow for better power >>> usage during runtime. This is a port from NXP downstream kernel. >>> > Since the introduction of this patch in mainline, I am facing sluggish > network performance with my Debix Model-A board with i.MX8mp SoC. > > The network latency jumps to >1s after almost every other packet: > > PING debix (10.0.42.5) 56(84) bytes of data. > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms > 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms > ^C > --- debix ping statistics --- > 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms > rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 > darkapex at freya in ~ > > If I revert the patch, or disable the deeper cpuidle state through > sysfs, the issue goes away. > > # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable > > PING debix (10.0.42.5) 56(84) bytes of data. > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms > ^C > --- debix ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4051ms > rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > >>> Signed-off-by: Catalin Popescu >>> <catalin.popescu@leica-geosystems.com> >> Applied, thanks! >> >> > Thanks, > Jai
Hi Catalin, On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote: > Hi Jai, > > This issue was already reported by Stefan. The problem is that I don't > have a Debix board to investigate. > The main difference b/w WFI and cpu-pd-wait is that the first doesn't > call PSCI/TF-A. So, the issue looks to be related to some settings in > the TF-A. Jai, are you using mainline U-Boot and TF-A, or a downstream version of either (or both) ? > What I don't get is why I don't see this issue neither on our IMX8MP > specific design nor on the EVK, which uses the same PHY as the Debix board. > > On 14/04/2025 14:07, Jai Luthra wrote: > > On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: > >> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > >>> So far, only WFI is supported on i.MX8mp platform. Add support for > >>> deeper cpuidle state "cpu-pd-wait" that would allow for better power > >>> usage during runtime. This is a port from NXP downstream kernel. > >>> > > Since the introduction of this patch in mainline, I am facing sluggish > > network performance with my Debix Model-A board with i.MX8mp SoC. > > > > The network latency jumps to >1s after almost every other packet: > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms > > ^C > > --- debix ping statistics --- > > 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms > > rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 > > darkapex at freya in ~ > > > > If I revert the patch, or disable the deeper cpuidle state through > > sysfs, the issue goes away. > > > > # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms > > ^C > > --- debix ping statistics --- > > 5 packets transmitted, 5 received, 0% packet loss, time 4051ms > > rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > > > >>> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> > >> > >> Applied, thanks! -- Regards, Laurent Pinchart
On Tue, Apr 15, 2025 at 06:47:26PM +0300, Laurent Pinchart wrote: > Hi Catalin, > > On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote: > > Hi Jai, > > > > This issue was already reported by Stefan. The problem is that I don't > > have a Debix board to investigate. > > The main difference b/w WFI and cpu-pd-wait is that the first doesn't > > call PSCI/TF-A. So, the issue looks to be related to some settings in > > the TF-A. > > Jai, are you using mainline U-Boot and TF-A, or a downstream version of > either (or both) ? Actually, same question for Calatin :-) I'm running mainline U-Boot 2025.01 and TF-A rel_imx_5.4.70_2.3.6 (from https://github.com/nxp-imx/imx-atf) and don't seem to experience the issue: # cat /sys/devices/system/cpu/cpu*/cpuidle/state1/disable 0 0 0 0 $ ping debix PING debix.farm.ideasonboard.com (192.168.2.230) 56(84) bytes of data. 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=1 ttl=64 time=1.03 ms 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=2 ttl=64 time=0.800 ms 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=3 ttl=64 time=0.935 ms 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=4 ttl=64 time=0.902 ms 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=5 ttl=64 time=0.738 ms 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=6 ttl=64 time=0.939 ms > > What I don't get is why I don't see this issue neither on our IMX8MP > > specific design nor on the EVK, which uses the same PHY as the Debix board. > > > > On 14/04/2025 14:07, Jai Luthra wrote: > > > On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: > > >> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > > >>> So far, only WFI is supported on i.MX8mp platform. Add support for > > >>> deeper cpuidle state "cpu-pd-wait" that would allow for better power > > >>> usage during runtime. This is a port from NXP downstream kernel. > > >>> > > > Since the introduction of this patch in mainline, I am facing sluggish > > > network performance with my Debix Model-A board with i.MX8mp SoC. > > > > > > The network latency jumps to >1s after almost every other packet: > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms > > > ^C > > > --- debix ping statistics --- > > > 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms > > > rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 > > > darkapex at freya in ~ > > > > > > If I revert the patch, or disable the deeper cpuidle state through > > > sysfs, the issue goes away. > > > > > > # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms > > > ^C > > > --- debix ping statistics --- > > > 5 packets transmitted, 5 received, 0% packet loss, time 4051ms > > > rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > > > > > >>> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> > > >> > > >> Applied, thanks! -- Regards, Laurent Pinchart
On 15/04/2025 17:52, Laurent Pinchart wrote: > [Some people who received this message don't often get email from laurent.pinchart@ideasonboard.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > This email is not from Hexagon’s Office 365 instance. Please be careful while clicking links, opening attachments, or replying to this email. > > > On Tue, Apr 15, 2025 at 06:47:26PM +0300, Laurent Pinchart wrote: >> Hi Catalin, >> >> On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote: >>> Hi Jai, >>> >>> This issue was already reported by Stefan. The problem is that I don't >>> have a Debix board to investigate. >>> The main difference b/w WFI and cpu-pd-wait is that the first doesn't >>> call PSCI/TF-A. So, the issue looks to be related to some settings in >>> the TF-A. >> Jai, are you using mainline U-Boot and TF-A, or a downstream version of >> either (or both) ? > Actually, same question for Calatin :-) Bonjour Laurent, I'm running a yocto scarthgap custom build : - barebox : http://barebox.org/download/barebox-2024.05.0.tar.bz2 _with_ custom patches - kernel : 6.12.16 _with_ custom patches - TF-A : git://github.com/hexagon-geo-surv/trusted-firmware-a;protocol=https;branch=leica/v2.12 / SRCREV=46c962c654de4ab734f936f472508edf20c6c049 (_no_ custom patches) Catalin > > I'm running mainline U-Boot 2025.01 and TF-A rel_imx_5.4.70_2.3.6 (from > https://github.com/nxp-imx/imx-atf) and don't seem to experience the > issue: > > # cat /sys/devices/system/cpu/cpu*/cpuidle/state1/disable > 0 > 0 > 0 > 0 > > $ ping debix > PING debix.farm.ideasonboard.com (192.168.2.230) 56(84) bytes of data. > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=1 ttl=64 time=1.03 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=2 ttl=64 time=0.800 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=3 ttl=64 time=0.935 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=4 ttl=64 time=0.902 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=5 ttl=64 time=0.738 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=6 ttl=64 time=0.939 ms > >>> What I don't get is why I don't see this issue neither on our IMX8MP >>> specific design nor on the EVK, which uses the same PHY as the Debix board. >>> >>> On 14/04/2025 14:07, Jai Luthra wrote: >>>> On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: >>>>> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: >>>>>> So far, only WFI is supported on i.MX8mp platform. Add support for >>>>>> deeper cpuidle state "cpu-pd-wait" that would allow for better power >>>>>> usage during runtime. This is a port from NXP downstream kernel. >>>>>> >>>> Since the introduction of this patch in mainline, I am facing sluggish >>>> network performance with my Debix Model-A board with i.MX8mp SoC. >>>> >>>> The network latency jumps to >1s after almost every other packet: >>>> >>>> PING debix (10.0.42.5) 56(84) bytes of data. >>>> 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms >>>> ^C >>>> --- debix ping statistics --- >>>> 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms >>>> rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 >>>> darkapex at freya in ~ >>>> >>>> If I revert the patch, or disable the deeper cpuidle state through >>>> sysfs, the issue goes away. >>>> >>>> # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable >>>> >>>> PING debix (10.0.42.5) 56(84) bytes of data. >>>> 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms >>>> 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms >>>> ^C >>>> --- debix ping statistics --- >>>> 5 packets transmitted, 5 received, 0% packet loss, time 4051ms >>>> rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms >>>> >>>>>> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> >>>>> Applied, thanks! > -- > Regards, > > Laurent Pinchart
Hi Catalin, On Wed, Apr 16, 2025 at 06:57:35AM +0000, POPESCU Catalin wrote: > On 15/04/2025 17:52, Laurent Pinchart wrote: > > On Tue, Apr 15, 2025 at 06:47:26PM +0300, Laurent Pinchart wrote: > >> On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote: > >>> Hi Jai, > >>> > >>> This issue was already reported by Stefan. The problem is that I don't > >>> have a Debix board to investigate. > >>> The main difference b/w WFI and cpu-pd-wait is that the first doesn't > >>> call PSCI/TF-A. So, the issue looks to be related to some settings in > >>> the TF-A. > >> > >> Jai, are you using mainline U-Boot and TF-A, or a downstream version of > >> either (or both) ? > > > > Actually, same question for Calatin :-) > > Bonjour Laurent, > > I'm running a yocto scarthgap custom build : > > - barebox : http://barebox.org/download/barebox-2024.05.0.tar.bz2 _with_ > custom patches > - kernel : 6.12.16 _with_ custom patches > - TF-A : > git://github.com/hexagon-geo-surv/trusted-firmware-a;protocol=https;branch=leica/v2.12 > / SRCREV=46c962c654de4ab734f936f472508edf20c6c049 (_no_ custom patches) Could you please run tests with the latest mainline kernel ? > > I'm running mainline U-Boot 2025.01 and TF-A rel_imx_5.4.70_2.3.6 (from > > https://github.com/nxp-imx/imx-atf) and don't seem to experience the > > issue: > > > > # cat /sys/devices/system/cpu/cpu*/cpuidle/state1/disable > > 0 > > 0 > > 0 > > 0 > > > > $ ping debix > > PING debix.farm.ideasonboard.com (192.168.2.230) 56(84) bytes of data. > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=1 ttl=64 time=1.03 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=2 ttl=64 time=0.800 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=3 ttl=64 time=0.935 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=4 ttl=64 time=0.902 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=5 ttl=64 time=0.738 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=6 ttl=64 time=0.939 ms > > > >>> What I don't get is why I don't see this issue neither on our IMX8MP > >>> specific design nor on the EVK, which uses the same PHY as the Debix board. > >>> > >>> On 14/04/2025 14:07, Jai Luthra wrote: > >>>> On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: > >>>>> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > >>>>>> So far, only WFI is supported on i.MX8mp platform. Add support for > >>>>>> deeper cpuidle state "cpu-pd-wait" that would allow for better power > >>>>>> usage during runtime. This is a port from NXP downstream kernel. > >>>>>> > >>>> Since the introduction of this patch in mainline, I am facing sluggish > >>>> network performance with my Debix Model-A board with i.MX8mp SoC. > >>>> > >>>> The network latency jumps to >1s after almost every other packet: > >>>> > >>>> PING debix (10.0.42.5) 56(84) bytes of data. > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms > >>>> ^C > >>>> --- debix ping statistics --- > >>>> 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms > >>>> rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 > >>>> darkapex at freya in ~ > >>>> > >>>> If I revert the patch, or disable the deeper cpuidle state through > >>>> sysfs, the issue goes away. > >>>> > >>>> # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable > >>>> > >>>> PING debix (10.0.42.5) 56(84) bytes of data. > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms > >>>> 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms > >>>> ^C > >>>> --- debix ping statistics --- > >>>> 5 packets transmitted, 5 received, 0% packet loss, time 4051ms > >>>> rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > >>>> > >>>>>> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> > >>>>> Applied, thanks! -- Regards, Laurent Pinchart
Hi Laurent, On Apr 15, 2025 at 18:52:39 +0300, Laurent Pinchart wrote: > On Tue, Apr 15, 2025 at 06:47:26PM +0300, Laurent Pinchart wrote: > > Hi Catalin, > > > > On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote: > > > Hi Jai, > > > > > > This issue was already reported by Stefan. The problem is that I don't > > > have a Debix board to investigate. > > > The main difference b/w WFI and cpu-pd-wait is that the first doesn't > > > call PSCI/TF-A. So, the issue looks to be related to some settings in > > > the TF-A. > > > > Jai, are you using mainline U-Boot and TF-A, or a downstream version of > > either (or both) ? I am running mainline U-Boot 2024.01 (with cherry-picked Debix support) and the same TF-A tag as you rel_imx_5.4.70_2.3.6 I can compile and test with U-Boot 2025.01, will report if it fixes the issue on my setup. > > Actually, same question for Calatin :-) > > I'm running mainline U-Boot 2025.01 and TF-A rel_imx_5.4.70_2.3.6 (from > https://github.com/nxp-imx/imx-atf) and don't seem to experience the > issue: > > # cat /sys/devices/system/cpu/cpu*/cpuidle/state1/disable > 0 > 0 > 0 > 0 > > $ ping debix > PING debix.farm.ideasonboard.com (192.168.2.230) 56(84) bytes of data. > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=1 ttl=64 time=1.03 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=2 ttl=64 time=0.800 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=3 ttl=64 time=0.935 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=4 ttl=64 time=0.902 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=5 ttl=64 time=0.738 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=6 ttl=64 time=0.939 ms > > > > What I don't get is why I don't see this issue neither on our IMX8MP > > > specific design nor on the EVK, which uses the same PHY as the Debix board. > > > > > > On 14/04/2025 14:07, Jai Luthra wrote: > > > > On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: > > > >> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > > > >>> So far, only WFI is supported on i.MX8mp platform. Add support for > > > >>> deeper cpuidle state "cpu-pd-wait" that would allow for better power > > > >>> usage during runtime. This is a port from NXP downstream kernel. > > > >>> > > > > Since the introduction of this patch in mainline, I am facing sluggish > > > > network performance with my Debix Model-A board with i.MX8mp SoC. > > > > > > > > The network latency jumps to >1s after almost every other packet: > > > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms > > > > ^C > > > > --- debix ping statistics --- > > > > 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms > > > > rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 > > > > darkapex at freya in ~ > > > > > > > > If I revert the patch, or disable the deeper cpuidle state through > > > > sysfs, the issue goes away. > > > > > > > > # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable > > > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms > > > > ^C > > > > --- debix ping statistics --- > > > > 5 packets transmitted, 5 received, 0% packet loss, time 4051ms > > > > rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > > > > > > > >>> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> > > > >> > > > >> Applied, thanks! > > -- > Regards, > > Laurent Pinchart -- Thanks, Jai
On Apr 16, 2025 at 10:29:27 +0530, Jai Luthra wrote: > Hi Laurent, > > On Apr 15, 2025 at 18:52:39 +0300, Laurent Pinchart wrote: > > On Tue, Apr 15, 2025 at 06:47:26PM +0300, Laurent Pinchart wrote: > > > Hi Catalin, > > > > > > On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote: > > > > Hi Jai, > > > > > > > > This issue was already reported by Stefan. The problem is that I don't > > > > have a Debix board to investigate. > > > > The main difference b/w WFI and cpu-pd-wait is that the first doesn't > > > > call PSCI/TF-A. So, the issue looks to be related to some settings in > > > > the TF-A. > > > > > > Jai, are you using mainline U-Boot and TF-A, or a downstream version of > > > either (or both) ? > > I am running mainline U-Boot 2024.01 (with cherry-picked Debix support) > and the same TF-A tag as you rel_imx_5.4.70_2.3.6 > > I can compile and test with U-Boot 2025.01, will report if it fixes the > issue on my setup. > FYI, switching to U-Boot 2025.01 does *not* fix the issue on my setup. I'm happy to test some other TF-A branch on my board if someone can point to it. > > > > Actually, same question for Calatin :-) > > > > I'm running mainline U-Boot 2025.01 and TF-A rel_imx_5.4.70_2.3.6 (from > > https://github.com/nxp-imx/imx-atf) and don't seem to experience the > > issue: > > > > # cat /sys/devices/system/cpu/cpu*/cpuidle/state1/disable > > 0 > > 0 > > 0 > > 0 > > > > $ ping debix > > PING debix.farm.ideasonboard.com (192.168.2.230) 56(84) bytes of data. > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=1 ttl=64 time=1.03 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=2 ttl=64 time=0.800 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=3 ttl=64 time=0.935 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=4 ttl=64 time=0.902 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=5 ttl=64 time=0.738 ms > > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=6 ttl=64 time=0.939 ms > > > > > > What I don't get is why I don't see this issue neither on our IMX8MP > > > > specific design nor on the EVK, which uses the same PHY as the Debix board. > > > > > > > > On 14/04/2025 14:07, Jai Luthra wrote: > > > > > On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: > > > > >> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > > > > >>> So far, only WFI is supported on i.MX8mp platform. Add support for > > > > >>> deeper cpuidle state "cpu-pd-wait" that would allow for better power > > > > >>> usage during runtime. This is a port from NXP downstream kernel. > > > > >>> > > > > > Since the introduction of this patch in mainline, I am facing sluggish > > > > > network performance with my Debix Model-A board with i.MX8mp SoC. > > > > > > > > > > The network latency jumps to >1s after almost every other packet: > > > > > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms > > > > > ^C > > > > > --- debix ping statistics --- > > > > > 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms > > > > > rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 > > > > > darkapex at freya in ~ > > > > > > > > > > If I revert the patch, or disable the deeper cpuidle state through > > > > > sysfs, the issue goes away. > > > > > > > > > > # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable > > > > > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms > > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms > > > > > ^C > > > > > --- debix ping statistics --- > > > > > 5 packets transmitted, 5 received, 0% packet loss, time 4051ms > > > > > rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > > > > > -- Thanks, Jai
Hi Laurent, On 25-04-15, Laurent Pinchart wrote: > On Tue, Apr 15, 2025 at 06:47:26PM +0300, Laurent Pinchart wrote: > > Hi Catalin, > > > > On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote: > > > Hi Jai, > > > > > > This issue was already reported by Stefan. The problem is that I don't > > > have a Debix board to investigate. > > > The main difference b/w WFI and cpu-pd-wait is that the first doesn't > > > call PSCI/TF-A. So, the issue looks to be related to some settings in > > > the TF-A. > > > > Jai, are you using mainline U-Boot and TF-A, or a downstream version of > > either (or both) ? > > Actually, same question for Calatin :-) > > I'm running mainline U-Boot 2025.01 and TF-A rel_imx_5.4.70_2.3.6 (from > https://github.com/nxp-imx/imx-atf) and don't seem to experience the > issue: Interessting, can you share your imx-atf build-config please? I checked the code base and found a missing SLPCR_A53_FASTWUP_STOP_MODE during the imx_set_sys_lpm() which is called during .pwr_domain_suspend(). Can you check/trace if pwr_domain_suspend() was entered? Regards, Marco > # cat /sys/devices/system/cpu/cpu*/cpuidle/state1/disable > 0 > 0 > 0 > 0 > > $ ping debix > PING debix.farm.ideasonboard.com (192.168.2.230) 56(84) bytes of data. > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=1 ttl=64 time=1.03 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=2 ttl=64 time=0.800 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=3 ttl=64 time=0.935 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=4 ttl=64 time=0.902 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=5 ttl=64 time=0.738 ms > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=6 ttl=64 time=0.939 ms > > > > What I don't get is why I don't see this issue neither on our IMX8MP > > > specific design nor on the EVK, which uses the same PHY as the Debix board. > > > > > > On 14/04/2025 14:07, Jai Luthra wrote: > > > > On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote: > > > >> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote: > > > >>> So far, only WFI is supported on i.MX8mp platform. Add support for > > > >>> deeper cpuidle state "cpu-pd-wait" that would allow for better power > > > >>> usage during runtime. This is a port from NXP downstream kernel. > > > >>> > > > > Since the introduction of this patch in mainline, I am facing sluggish > > > > network performance with my Debix Model-A board with i.MX8mp SoC. > > > > > > > > The network latency jumps to >1s after almost every other packet: > > > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms > > > > ^C > > > > --- debix ping statistics --- > > > > 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms > > > > rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2 > > > > darkapex at freya in ~ > > > > > > > > If I revert the patch, or disable the deeper cpuidle state through > > > > sysfs, the issue goes away. > > > > > > > > # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable > > > > > > > > PING debix (10.0.42.5) 56(84) bytes of data. > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms > > > > ^C > > > > --- debix ping statistics --- > > > > 5 packets transmitted, 5 received, 0% packet loss, time 4051ms > > > > rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms > > > > > > > >>> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com> > > > >> > > > >> Applied, thanks! > > -- > Regards, > > Laurent Pinchart >
Hi Marco,
On Tue, Apr 15, 2025 at 08:14:23PM +0200, Marco Felsch wrote:
> On 25-04-15, Laurent Pinchart wrote:
> > On Tue, Apr 15, 2025 at 06:47:26PM +0300, Laurent Pinchart wrote:
> > > On Tue, Apr 15, 2025 at 03:42:22PM +0000, POPESCU Catalin wrote:
> > > > Hi Jai,
> > > >
> > > > This issue was already reported by Stefan. The problem is that I don't
> > > > have a Debix board to investigate.
> > > > The main difference b/w WFI and cpu-pd-wait is that the first doesn't
> > > > call PSCI/TF-A. So, the issue looks to be related to some settings in
> > > > the TF-A.
> > >
> > > Jai, are you using mainline U-Boot and TF-A, or a downstream version of
> > > either (or both) ?
> >
> > Actually, same question for Calatin :-)
> >
> > I'm running mainline U-Boot 2025.01 and TF-A rel_imx_5.4.70_2.3.6 (from
> > https://github.com/nxp-imx/imx-atf) and don't seem to experience the
> > issue:
>
> Interessting, can you share your imx-atf build-config please?
I've followed the instructions in the doc/board/nxp/imx8mp_evk.rst file
(in the U-Boot source):
```
Get and Build the ARM Trusted firmware
--------------------------------------
Get ATF from: https://github.com/nxp-imx/imx-atf
branch: imx_5.4.70_2.3.0
.. code-block:: bash
$ make PLAT=imx8mp bl31
```
I had to patch the TF-A makefile as follows to fix errors with recent
versions of gcc:
```
diff --git a/Makefile b/Makefile
index 2ae12fda741a..46512993c6e0 100644
--- a/Makefile
+++ b/Makefile
@@ -285,7 +285,8 @@ ASFLAGS += $(CPPFLAGS) $(ASFLAGS_$(ARCH)) \
-ffreestanding -Wa,--fatal-warnings
TF_CFLAGS += $(CPPFLAGS) $(TF_CFLAGS_$(ARCH)) \
-ffreestanding -fno-builtin -Wall -std=gnu99 \
- -Os -ffunction-sections -fdata-sections
+ -Os -ffunction-sections -fdata-sections \
+ -Wno-error=array-bounds
ifeq (${SANITIZE_UB},on)
TF_CFLAGS += -fsanitize=undefined -fno-sanitize-recover
@@ -300,9 +301,11 @@ GCC_V_OUTPUT := $(shell $(CC) -v 2>&1)
ifneq ($(findstring armlink,$(notdir $(LD))),)
TF_LDFLAGS += --diag_error=warning --lto_level=O1
TF_LDFLAGS += --remove --info=unused,unusedsymbols
+TF_LDFLAGS += -Wl,--no-warn-rwx-segment
else
TF_LDFLAGS += --fatal-warnings -O1
TF_LDFLAGS += --gc-sections
+TF_LDFLAGS += --no-warn-rwx-segment
endif
TF_LDFLAGS += $(TF_LDFLAGS_$(ARCH))
```
> I checked the code base and found a missing SLPCR_A53_FASTWUP_STOP_MODE
> during the imx_set_sys_lpm() which is called during
> .pwr_domain_suspend(). Can you check/trace if pwr_domain_suspend() was
> entered?
I'm no TF-A expert, can you tell me how to check/trace that ?
> > # cat /sys/devices/system/cpu/cpu*/cpuidle/state1/disable
> > 0
> > 0
> > 0
> > 0
> >
> > $ ping debix
> > PING debix.farm.ideasonboard.com (192.168.2.230) 56(84) bytes of data.
> > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=1 ttl=64 time=1.03 ms
> > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=2 ttl=64 time=0.800 ms
> > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=3 ttl=64 time=0.935 ms
> > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=4 ttl=64 time=0.902 ms
> > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=5 ttl=64 time=0.738 ms
> > 64 bytes from debix.farm.ideasonboard.com (192.168.2.230): icmp_seq=6 ttl=64 time=0.939 ms
> >
> > > > What I don't get is why I don't see this issue neither on our IMX8MP
> > > > specific design nor on the EVK, which uses the same PHY as the Debix board.
> > > >
> > > > On 14/04/2025 14:07, Jai Luthra wrote:
> > > > > On Oct 21, 2024 at 17:42:34 +0800, Shawn Guo wrote:
> > > > >> On Mon, Oct 07, 2024 at 03:44:24PM +0200, Catalin Popescu wrote:
> > > > >>> So far, only WFI is supported on i.MX8mp platform. Add support for
> > > > >>> deeper cpuidle state "cpu-pd-wait" that would allow for better power
> > > > >>> usage during runtime. This is a port from NXP downstream kernel.
> > > > >>>
> > > > > Since the introduction of this patch in mainline, I am facing sluggish
> > > > > network performance with my Debix Model-A board with i.MX8mp SoC.
> > > > >
> > > > > The network latency jumps to >1s after almost every other packet:
> > > > >
> > > > > PING debix (10.0.42.5) 56(84) bytes of data.
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=1008 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=0.488 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=1025 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.810 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=590 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=6 ttl=64 time=0.351 ms
> > > > > ^C
> > > > > --- debix ping statistics ---
> > > > > 7 packets transmitted, 6 received, 14.2857% packet loss, time 6126ms
> > > > > rtt min/avg/max/mdev = 0.351/437.416/1024.755/459.370 ms, pipe 2
> > > > > darkapex at freya in ~
> > > > >
> > > > > If I revert the patch, or disable the deeper cpuidle state through
> > > > > sysfs, the issue goes away.
> > > > >
> > > > > # echo 1 > /sys/devices/system/cpu/cpu$i/cpuidle/state1/disable
> > > > >
> > > > > PING debix (10.0.42.5) 56(84) bytes of data.
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=1 ttl=64 time=0.482 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=2 ttl=64 time=2.28 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=3 ttl=64 time=2.26 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=4 ttl=64 time=0.848 ms
> > > > > 64 bytes from debix (10.0.42.5): icmp_seq=5 ttl=64 time=0.406 ms
> > > > > ^C
> > > > > --- debix ping statistics ---
> > > > > 5 packets transmitted, 5 received, 0% packet loss, time 4051ms
> > > > > rtt min/avg/max/mdev = 0.406/1.255/2.280/0.842 ms
> > > > >
> > > > >>> Signed-off-by: Catalin Popescu <catalin.popescu@leica-geosystems.com>
> > > > >>
> > > > >> Applied, thanks!
--
Regards,
Laurent Pinchart
© 2016 - 2026 Red Hat, Inc.