* Re: [PATCH] arm64: dts: imx8mp: add cpuidle state "cpu-pd-wait"
2025-04-15 15:52 ` Laurent Pinchart
@ 2025-04-15 18:14 ` Marco Felsch
2025-04-15 23:01 ` Laurent Pinchart
2025-04-16 4:59 ` Jai Luthra
2025-04-16 6:57 ` POPESCU Catalin
2 siblings, 1 reply; 13+ messages in thread
From: Marco Felsch @ 2025-04-15 18:14 UTC (permalink / raw)
To: Laurent Pinchart
Cc: POPESCU Catalin, Jai Luthra, Shawn Guo, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, GEO-CHHER-bsp-development,
stefan.klug@ideasonboard.com
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] arm64: dts: imx8mp: add cpuidle state "cpu-pd-wait"
2025-04-15 18:14 ` Marco Felsch
@ 2025-04-15 23:01 ` Laurent Pinchart
0 siblings, 0 replies; 13+ messages in thread
From: Laurent Pinchart @ 2025-04-15 23:01 UTC (permalink / raw)
To: Marco Felsch
Cc: POPESCU Catalin, Jai Luthra, Shawn Guo, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, GEO-CHHER-bsp-development,
stefan.klug@ideasonboard.com
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] arm64: dts: imx8mp: add cpuidle state "cpu-pd-wait"
2025-04-15 15:52 ` Laurent Pinchart
2025-04-15 18:14 ` Marco Felsch
@ 2025-04-16 4:59 ` Jai Luthra
2025-04-16 8:46 ` Jai Luthra
2025-04-16 6:57 ` POPESCU Catalin
2 siblings, 1 reply; 13+ messages in thread
From: Jai Luthra @ 2025-04-16 4:59 UTC (permalink / raw)
To: Laurent Pinchart
Cc: POPESCU Catalin, Shawn Guo, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, m.felsch@pengutronix.de,
GEO-CHHER-bsp-development, stefan.klug@ideasonboard.com
[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] arm64: dts: imx8mp: add cpuidle state "cpu-pd-wait"
2025-04-16 4:59 ` Jai Luthra
@ 2025-04-16 8:46 ` Jai Luthra
0 siblings, 0 replies; 13+ messages in thread
From: Jai Luthra @ 2025-04-16 8:46 UTC (permalink / raw)
To: Laurent Pinchart
Cc: POPESCU Catalin, Shawn Guo, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, m.felsch@pengutronix.de,
GEO-CHHER-bsp-development, stefan.klug@ideasonboard.com
[-- Attachment #1: Type: text/plain, Size: 4654 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] arm64: dts: imx8mp: add cpuidle state "cpu-pd-wait"
2025-04-15 15:52 ` Laurent Pinchart
2025-04-15 18:14 ` Marco Felsch
2025-04-16 4:59 ` Jai Luthra
@ 2025-04-16 6:57 ` POPESCU Catalin
2025-04-16 17:04 ` Laurent Pinchart
2 siblings, 1 reply; 13+ messages in thread
From: POPESCU Catalin @ 2025-04-16 6:57 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Jai Luthra, Shawn Guo, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, m.felsch@pengutronix.de,
GEO-CHHER-bsp-development, stefan.klug@ideasonboard.com
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] arm64: dts: imx8mp: add cpuidle state "cpu-pd-wait"
2025-04-16 6:57 ` POPESCU Catalin
@ 2025-04-16 17:04 ` Laurent Pinchart
0 siblings, 0 replies; 13+ messages in thread
From: Laurent Pinchart @ 2025-04-16 17:04 UTC (permalink / raw)
To: POPESCU Catalin
Cc: Jai Luthra, Shawn Guo, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, m.felsch@pengutronix.de,
GEO-CHHER-bsp-development, stefan.klug@ideasonboard.com
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
^ permalink raw reply [flat|nested] 13+ messages in thread