From: Frieder Schrempf <frieder.schrempf@kontron.de> To: Tim Harvey <tharvey@gateworks.com>, Lucas Stach <l.stach@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org>, Rob Herring <robh+dt@kernel.org>, NXP Linux Team <linux-imx@nxp.com>, Adam Ford <aford173@gmail.com>, Peng Fan <peng.fan@nxp.com>, Marek Vasut <marex@denx.de>, Device Tree Mailing List <devicetree@vger.kernel.org>, Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>, Sascha Hauer <kernel@pengutronix.de>, patchwork-lst@pengutronix.de, Fabio Estevam <festevam@gmail.com> Subject: Re: [PATCH v2 00/18] i.MX8MM GPC improvements and BLK_CTRL driver Date: Wed, 1 Sep 2021 12:30:20 +0200 [thread overview] Message-ID: <ec6517f4-e2da-da88-2785-5bbb70131bf9@kontron.de> (raw) In-Reply-To: <CAJ+vNU2tSh-0TuaAZ-_Hkg3K5fudc3U77tAtcRaja-GLzXsYPQ@mail.gmail.com> Hi Tim, On 31.08.21 00:06, Tim Harvey wrote: > On Mon, Aug 9, 2021 at 4:01 AM Lucas Stach <l.stach@pengutronix.de> wrote: >> >> Hi Frieder, >> >> Am Donnerstag, dem 05.08.2021 um 20:56 +0200 schrieb Frieder Schrempf: >>> On 05.08.21 12:18, Frieder Schrempf wrote: >>>> On 21.07.21 22:46, Lucas Stach wrote: >>>>> Hi all, >>>>> >>>>> second revision of the GPC improvements and BLK_CTRL driver to make use >>>>> of all the power-domains on the i.MX8MM. I'm not going to repeat the full >>>>> blurb from the v1 cover letter here, but if you are not familiar with >>>>> i.MX8MM power domains, it may be worth a read. >>>>> >>>>> This 2nd revision fixes the DT bindings to be valid yaml, some small >>>>> failure path issues and most importantly the interaction with system >>>>> suspend/resume. With the previous version some of the power domains >>>>> would not come up correctly after a suspend/resume cycle. >>>>> >>>>> Updated testing git trees here, disclaimer still applies: >>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.pengutronix.de%2Fcgit%2Flst%2Flinux%2Flog%2F%3Fh%3Dimx8m-power-domains&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C35d8c33691eb4355196c08d96c0281b5%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637659580288796439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XrDOPLcL5D6PYt8ihbhURkuD9bzABOOfP6hJ5x341lM%3D&reserved=0 >>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.pengutronix.de%2Fcgit%2Flst%2Flinux%2Flog%2F%3Fh%3Dimx8m-power-domains-testing&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C35d8c33691eb4355196c08d96c0281b5%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637659580288796439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9J016OR46KgfdlM4pG%2F5rkO6pT%2FOBwgLTMRqF10it%2Fg%3D&reserved=0 >>>> >>>> I finally did some tests on my side using USB, GPU and DSI (no PCIe, VPU, CSI so far) and the results are promising. Thanks for the effort! >>>> >>>> I will try to run some more automated suspend/resume and reboot test cycles over the weekend and report the results here afterwards. >>>> >>> >>> Unfortunately I got some results sooner than I had hoped. I set up a simple loop to suspend/resume every few seconds and on the first run it took around 2-3 hours for the device to lock up on resume. On the second run it took less than half an hour. I had glmark2-es2-drm running in the background, but it looks like it crashed at some point before the lockup occurred. >>> >>> Of course this could also be unrelated and caused by some peripheral driver or something but the first suspicion is definitely the power domains. >>> >>> If you have any suggestions for which debug options to enable or where to add some printks, please let me know. If I do another run I would like to make sure that the resulting logs are helpful for debugging. >>> >>> And I would appreciate if someone else could try to reproduce this problem on his/her side. I use this simple script for testing: >>> >>> #!/bin/sh >>> >>> glmark2-es2-drm & >>> >>> while true; >>> do >>> echo +10 > /sys/class/rtc/rtc0/wakealarm >>> echo mem > /sys/power/state >>> sleep 5 >>> done; >> >> Hm, that's unfortunate. >> >> I'm back from a two week vacation, but it looks like I won't have much >> time available to look into this issue soon. It would be very helpful >> if you could try to pinpoint the hang a bit more. If you can reproduce >> the hang with no_console_suspend you might be able to extract a bit >> more info in which stage the hang happens (suspend, resume, TF-A, etc.) >> If the hang is in the kernel you might be able to add some prints to >> the suspend/resume paths to be able to track down the exact point of >> the hang. >> >> I'm happy to look into the issue once it's better known where to look, >> but I fear that I won't have time to do the above investigation myself >> short term. Frieder, is this something you could help with over the >> next few days? >> > > Lucas / Frieder, > > Can you update us on where you are at with this patch series? I fear > we are going to go through another kernel release without IMX8MM > blk-ctl support and all the things that depend on it such as > USB/PCI/DSI/CSI/GPU/VPU. If there is some specific testing you need > please let me know what I can do to help. I have a variety of IMX8MM > hardware but not a lot of time or knowledge with regards to > troubleshooting suspend/resume issues. I try to help as good as I can, but unfortunately my time is very limited and I didn't make much progress in investigating the issue(s) so far. If you could do some testing on your side, this would be very appreciated. It would be good if you could setup a recent kernel with Lucas' patchset applied and do some supsend/resume cycle testing as described above. Use 'no_console_suspend' in the cmdline and look for any error messages in the log or lockups of the device. You probably also need some users for the PD or BLK-CTRL, like GPU, DSI, USB, etc. (that's what I currently have enabled). You can find the tree I'm currently using here: https://github.com/fschrempf/linux/tree/next-ktn-pd-blk-ctl-lucas. > Are the issues found a regression? Regression compared to what? To the v1 patches? I don't think so. We didn't have any stable solution for BLK-CTRL support so far and what we have is probably not tested extensively, yet. So I guess it's not really unexpected that there are still issues, but it's very frustrating that after all the efforts, there maybe is still something in the HW that doesn't behave as expected. Best regards, Frieder
WARNING: multiple messages have this Message-ID (diff)
From: Frieder Schrempf <frieder.schrempf@kontron.de> To: Tim Harvey <tharvey@gateworks.com>, Lucas Stach <l.stach@pengutronix.de> Cc: Shawn Guo <shawnguo@kernel.org>, Rob Herring <robh+dt@kernel.org>, NXP Linux Team <linux-imx@nxp.com>, Adam Ford <aford173@gmail.com>, Peng Fan <peng.fan@nxp.com>, Marek Vasut <marex@denx.de>, Device Tree Mailing List <devicetree@vger.kernel.org>, Linux ARM Mailing List <linux-arm-kernel@lists.infradead.org>, Sascha Hauer <kernel@pengutronix.de>, patchwork-lst@pengutronix.de, Fabio Estevam <festevam@gmail.com> Subject: Re: [PATCH v2 00/18] i.MX8MM GPC improvements and BLK_CTRL driver Date: Wed, 1 Sep 2021 12:30:20 +0200 [thread overview] Message-ID: <ec6517f4-e2da-da88-2785-5bbb70131bf9@kontron.de> (raw) In-Reply-To: <CAJ+vNU2tSh-0TuaAZ-_Hkg3K5fudc3U77tAtcRaja-GLzXsYPQ@mail.gmail.com> Hi Tim, On 31.08.21 00:06, Tim Harvey wrote: > On Mon, Aug 9, 2021 at 4:01 AM Lucas Stach <l.stach@pengutronix.de> wrote: >> >> Hi Frieder, >> >> Am Donnerstag, dem 05.08.2021 um 20:56 +0200 schrieb Frieder Schrempf: >>> On 05.08.21 12:18, Frieder Schrempf wrote: >>>> On 21.07.21 22:46, Lucas Stach wrote: >>>>> Hi all, >>>>> >>>>> second revision of the GPC improvements and BLK_CTRL driver to make use >>>>> of all the power-domains on the i.MX8MM. I'm not going to repeat the full >>>>> blurb from the v1 cover letter here, but if you are not familiar with >>>>> i.MX8MM power domains, it may be worth a read. >>>>> >>>>> This 2nd revision fixes the DT bindings to be valid yaml, some small >>>>> failure path issues and most importantly the interaction with system >>>>> suspend/resume. With the previous version some of the power domains >>>>> would not come up correctly after a suspend/resume cycle. >>>>> >>>>> Updated testing git trees here, disclaimer still applies: >>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.pengutronix.de%2Fcgit%2Flst%2Flinux%2Flog%2F%3Fh%3Dimx8m-power-domains&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C35d8c33691eb4355196c08d96c0281b5%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637659580288796439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=XrDOPLcL5D6PYt8ihbhURkuD9bzABOOfP6hJ5x341lM%3D&reserved=0 >>>>> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.pengutronix.de%2Fcgit%2Flst%2Flinux%2Flog%2F%3Fh%3Dimx8m-power-domains-testing&data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C35d8c33691eb4355196c08d96c0281b5%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637659580288796439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9J016OR46KgfdlM4pG%2F5rkO6pT%2FOBwgLTMRqF10it%2Fg%3D&reserved=0 >>>> >>>> I finally did some tests on my side using USB, GPU and DSI (no PCIe, VPU, CSI so far) and the results are promising. Thanks for the effort! >>>> >>>> I will try to run some more automated suspend/resume and reboot test cycles over the weekend and report the results here afterwards. >>>> >>> >>> Unfortunately I got some results sooner than I had hoped. I set up a simple loop to suspend/resume every few seconds and on the first run it took around 2-3 hours for the device to lock up on resume. On the second run it took less than half an hour. I had glmark2-es2-drm running in the background, but it looks like it crashed at some point before the lockup occurred. >>> >>> Of course this could also be unrelated and caused by some peripheral driver or something but the first suspicion is definitely the power domains. >>> >>> If you have any suggestions for which debug options to enable or where to add some printks, please let me know. If I do another run I would like to make sure that the resulting logs are helpful for debugging. >>> >>> And I would appreciate if someone else could try to reproduce this problem on his/her side. I use this simple script for testing: >>> >>> #!/bin/sh >>> >>> glmark2-es2-drm & >>> >>> while true; >>> do >>> echo +10 > /sys/class/rtc/rtc0/wakealarm >>> echo mem > /sys/power/state >>> sleep 5 >>> done; >> >> Hm, that's unfortunate. >> >> I'm back from a two week vacation, but it looks like I won't have much >> time available to look into this issue soon. It would be very helpful >> if you could try to pinpoint the hang a bit more. If you can reproduce >> the hang with no_console_suspend you might be able to extract a bit >> more info in which stage the hang happens (suspend, resume, TF-A, etc.) >> If the hang is in the kernel you might be able to add some prints to >> the suspend/resume paths to be able to track down the exact point of >> the hang. >> >> I'm happy to look into the issue once it's better known where to look, >> but I fear that I won't have time to do the above investigation myself >> short term. Frieder, is this something you could help with over the >> next few days? >> > > Lucas / Frieder, > > Can you update us on where you are at with this patch series? I fear > we are going to go through another kernel release without IMX8MM > blk-ctl support and all the things that depend on it such as > USB/PCI/DSI/CSI/GPU/VPU. If there is some specific testing you need > please let me know what I can do to help. I have a variety of IMX8MM > hardware but not a lot of time or knowledge with regards to > troubleshooting suspend/resume issues. I try to help as good as I can, but unfortunately my time is very limited and I didn't make much progress in investigating the issue(s) so far. If you could do some testing on your side, this would be very appreciated. It would be good if you could setup a recent kernel with Lucas' patchset applied and do some supsend/resume cycle testing as described above. Use 'no_console_suspend' in the cmdline and look for any error messages in the log or lockups of the device. You probably also need some users for the PD or BLK-CTRL, like GPU, DSI, USB, etc. (that's what I currently have enabled). You can find the tree I'm currently using here: https://github.com/fschrempf/linux/tree/next-ktn-pd-blk-ctl-lucas. > Are the issues found a regression? Regression compared to what? To the v1 patches? I don't think so. We didn't have any stable solution for BLK-CTRL support so far and what we have is probably not tested extensively, yet. So I guess it's not really unexpected that there are still issues, but it's very frustrating that after all the efforts, there maybe is still something in the HW that doesn't behave as expected. Best regards, Frieder _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-09-01 10:30 UTC|newest] Thread overview: 139+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-16 23:28 [PATCH 00/17] i.MX8MM GPC improvements and BLK_CTRL driver Lucas Stach 2021-07-16 23:28 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 01/17] Revert "soc: imx: gpcv2: move reset assert after requesting domain power up" Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 02/17] soc: imx: gpcv2: Turn domain->pgc into bitfield Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 03/17] soc: imx: gpcv2: Set both GPC_PGC_nCTRL(GPU_2D|GPU_3D) for MX8MM GPU domain Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 04/17] soc: imx: gpcv2: add lockdep annotation Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 05/17] soc: imx: gpcv2: add domain option to keep domain clocks enabled Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 06/17] soc: imx: gpcv2: keep i.MX8M* bus " Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 07/17] dt-bindings: soc: add binding for i.MX8MM VPU blk-ctrl Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-19 13:47 ` Rob Herring 2021-07-19 13:47 ` Rob Herring 2021-07-16 23:29 ` [PATCH 08/17] dt-bindings: power: imx8mm: add defines for VPU blk-ctrl domains Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 09/17] soc: imx: add i.MX8M blk-ctrl driver Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 10/17] dt-bindings: soc: add binding for i.MX8MM DISP blk-ctrl Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-19 13:47 ` Rob Herring 2021-07-19 13:47 ` Rob Herring 2021-07-16 23:29 ` [PATCH 11/17] dt-bindings: power: imx8mm: add defines for DISP blk-ctrl domains Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 12/17] soc: imx: imx8m-blk-ctrl: add DISP blk-ctrl Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 13/17] arm64: dts: imx8mm: add GPC node Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 14/17] arm64: dts: imx8mm: put USB controllers into power-domains Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 15/17] arm64: dts: imx8mm: Add GPU nodes for 2D and 3D core Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 16/17] arm64: dts: imx8mm: add VPU blk-ctrl Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-16 23:29 ` [PATCH 17/17] arm64: dts: imx8mm: add DISP blk-ctrl Lucas Stach 2021-07-16 23:29 ` Lucas Stach 2021-07-19 12:53 ` [PATCH 00/17] i.MX8MM GPC improvements and BLK_CTRL driver Peng Fan 2021-07-19 12:53 ` Peng Fan 2021-07-19 16:56 ` Lucas Stach 2021-07-19 16:56 ` Lucas Stach 2021-07-21 11:21 ` Lucas Stach 2021-07-21 11:21 ` Lucas Stach 2021-07-21 20:46 ` [PATCH v2 00/18] " Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-07-21 20:46 ` [PATCH v2 01/18] Revert "soc: imx: gpcv2: move reset assert after requesting domain power up" Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:37 ` Peng Fan 2021-08-05 9:37 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 02/18] soc: imx: gpcv2: Turn domain->pgc into bitfield Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:37 ` Peng Fan 2021-08-05 9:37 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 03/18] soc: imx: gpcv2: Set both GPC_PGC_nCTRL(GPU_2D|GPU_3D) for MX8MM GPU domain Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:37 ` Peng Fan 2021-08-05 9:37 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 04/18] soc: imx: gpcv2: add lockdep annotation Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:38 ` Peng Fan 2021-08-05 9:38 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 05/18] soc: imx: gpcv2: add domain option to keep domain clocks enabled Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:38 ` Peng Fan 2021-08-05 9:38 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 06/18] soc: imx: gpcv2: keep i.MX8M* bus " Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:39 ` Peng Fan 2021-08-05 9:39 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 07/18] soc: imx: gpcv2: support system suspend/resume Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:47 ` Peng Fan 2021-08-05 9:47 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 08/18] dt-bindings: soc: add binding for i.MX8MM VPU blk-ctrl Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-07-22 14:37 ` Rob Herring 2021-07-22 14:37 ` Rob Herring 2021-07-21 20:46 ` [PATCH v2 09/18] dt-bindings: power: imx8mm: add defines for VPU blk-ctrl domains Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-07-21 20:46 ` [PATCH v2 10/18] soc: imx: add i.MX8M blk-ctrl driver Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:54 ` Peng Fan 2021-08-05 9:54 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 11/18] dt-bindings: soc: add binding for i.MX8MM DISP blk-ctrl Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-07-22 14:37 ` Rob Herring 2021-07-22 14:37 ` Rob Herring 2021-07-21 20:46 ` [PATCH v2 12/18] dt-bindings: power: imx8mm: add defines for DISP blk-ctrl domains Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-07-21 20:46 ` [PATCH v2 13/18] soc: imx: imx8m-blk-ctrl: add DISP blk-ctrl Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:53 ` Peng Fan 2021-08-05 9:53 ` Peng Fan 2021-07-21 20:46 ` [PATCH v2 14/18] arm64: dts: imx8mm: add GPC node Lucas Stach 2021-07-21 20:46 ` Lucas Stach 2021-08-05 9:54 ` Peng Fan 2021-08-05 9:54 ` Peng Fan 2021-07-21 20:47 ` [PATCH v2 15/18] arm64: dts: imx8mm: put USB controllers into power-domains Lucas Stach 2021-07-21 20:47 ` Lucas Stach 2021-07-21 20:47 ` [PATCH v2 16/18] arm64: dts: imx8mm: Add GPU nodes for 2D and 3D core Lucas Stach 2021-07-21 20:47 ` Lucas Stach 2021-07-21 20:47 ` [PATCH v2 17/18] arm64: dts: imx8mm: add VPU blk-ctrl Lucas Stach 2021-07-21 20:47 ` Lucas Stach 2021-07-21 20:47 ` [PATCH v2 18/18] arm64: dts: imx8mm: add DISP blk-ctrl Lucas Stach 2021-07-21 20:47 ` Lucas Stach 2021-08-05 9:35 ` [PATCH v2 00/18] i.MX8MM GPC improvements and BLK_CTRL driver Peng Fan (OSS) 2021-08-05 9:35 ` Peng Fan (OSS) 2021-08-05 10:18 ` Frieder Schrempf 2021-08-05 10:18 ` Frieder Schrempf 2021-08-05 18:56 ` Frieder Schrempf 2021-08-05 18:56 ` Frieder Schrempf 2021-08-09 11:01 ` Lucas Stach 2021-08-09 11:01 ` Lucas Stach 2021-08-09 11:50 ` Frieder Schrempf 2021-08-09 11:50 ` Frieder Schrempf 2021-08-09 18:51 ` Adam Ford 2021-08-09 18:51 ` Adam Ford 2021-09-01 10:03 ` Frieder Schrempf 2021-09-01 10:03 ` Frieder Schrempf 2021-09-01 12:16 ` Frieder Schrempf 2021-09-01 12:16 ` Frieder Schrempf 2021-09-02 10:25 ` Lucas Stach 2021-09-02 10:25 ` Lucas Stach 2021-09-06 7:49 ` Frieder Schrempf 2021-09-06 7:49 ` Frieder Schrempf 2021-08-30 22:06 ` Tim Harvey 2021-08-30 22:06 ` Tim Harvey 2021-09-01 10:30 ` Frieder Schrempf [this message] 2021-09-01 10:30 ` Frieder Schrempf 2021-07-18 6:04 [PATCH 09/17] soc: imx: add i.MX8M blk-ctrl driver kernel test robot 2021-07-19 6:12 ` Dan Carpenter 2021-07-19 6:12 ` Dan Carpenter 2021-07-19 6:12 ` Dan Carpenter 2021-07-19 9:11 ` Lucas Stach 2021-07-19 9:11 ` Lucas Stach 2021-07-19 9:11 ` Lucas Stach
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ec6517f4-e2da-da88-2785-5bbb70131bf9@kontron.de \ --to=frieder.schrempf@kontron.de \ --cc=aford173@gmail.com \ --cc=devicetree@vger.kernel.org \ --cc=festevam@gmail.com \ --cc=kernel@pengutronix.de \ --cc=l.stach@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-imx@nxp.com \ --cc=marex@denx.de \ --cc=patchwork-lst@pengutronix.de \ --cc=peng.fan@nxp.com \ --cc=robh+dt@kernel.org \ --cc=shawnguo@kernel.org \ --cc=tharvey@gateworks.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.