[PATCH v1] PCI: imx6: Fix i.MX6Q/DL boot hang by separating PHY power and reference clock control

Wed Jul 8 03:43:08 PDT 2026

On 08.07.26 11:50, Hongxing Zhu (OSS) wrote:
>> -----Original Message-----
>> From: Soeren Moch <smoch at web.de>
>> Sent: Tuesday, July 7, 2026 7:04 PM
>> To: Hongxing Zhu (OSS) <hongxing.zhu at oss.nxp.com>; Frank Li
>> <frank.li at nxp.com>; l.stach at pengutronix.de; lpieralisi at kernel.org;
>> kwilczynski at kernel.org; mani at kernel.org; robh at kernel.org;
>> bhelgaas at google.com; s.hauer at pengutronix.de; kernel at pengutronix.de;
>> festevam at gmail.com
>> Cc: linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>> imx at lists.linux.dev; linux-kernel at vger.kernel.org; Hongxing Zhu
>> <hongxing.zhu at nxp.com>
>> Subject: Re: [PATCH v1] PCI: imx6: Fix i.MX6Q/DL boot hang by separating PHY
>> power and reference clock control
>>
>> On 07.07.26 10:55, Soeren Moch wrote:
>>> On 07.07.26 05:03, Hongxing Zhu (OSS) wrote:
>>>>> -----Original Message-----
>>>>> From: Soeren Moch <smoch at web.de>
>>>>> Sent: Monday, July 6, 2026 10:09 PM
>>>>> To: Hongxing Zhu (OSS) <hongxing.zhu at oss.nxp.com>; Frank Li
>>>>> <frank.li at nxp.com>; l.stach at pengutronix.de; lpieralisi at kernel.org;
>>>>> kwilczynski at kernel.org; mani at kernel.org; robh at kernel.org;
>>>>> bhelgaas at google.com; s.hauer at pengutronix.de; kernel at pengutronix.de;
>>>>> festevam at gmail.com
>>>>> Cc: linux-pci at vger.kernel.org; linux-arm-kernel at lists.infradead.org;
>>>>> imx at lists.linux.dev; linux-kernel at vger.kernel.org; Hongxing Zhu
>>>>> <hongxing.zhu at nxp.com>
>>>>> Subject: Re: [PATCH v1] PCI: imx6: Fix i.MX6Q/DL boot hang by
>>>>> separating PHY power and reference clock control
>>>>>
>>>>>
>>>>>
>>>>> On 06.07.26 05:06, hongxing.zhu at oss.nxp.com wrote:
>>>>>> From: Richard Zhu <hongxing.zhu at nxp.com>
>>>>>>
>>>>>> Commit 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling
>>>>>> regulators") introduced a boot hang on i.MX6Q/DL variants by
>>>>>> changing the initialization sequence.
>>>>>>
>>>>>> The issue stems from coupling PHY power (TEST_PD) and reference
>>>>>> clock
>>>>>> (REF_CLK_EN) control in imx6q_pcie_enable_ref_clk(). When these are
>>>>>> managed together, the timing between PHY power-up and reference
>>>>>> clock enablement cannot be properly controlled, leading to
>>>>>> initialization failures.
>>>>>>
>>>>>> Fix this by separating the two concerns:
>>>>>>
>>>>>> - Move PHY power control (TEST_PD) to imx6q_pcie_core_reset() where
>>>>>> it
>>>>>>      logically belongs with reset operations. This ensures PHY power
>>>>>> state
>>>>>>      is managed as part of the core reset sequence.
>>>>>>
>>>>>> - Update imx6qp_pcie_core_reset() to call imx6q_pcie_core_reset()
>>>>>> for
>>>>>>      shared PHY power management, avoiding code duplication.
>>>>>>
>>>>>> - Make imx6q_pcie_enable_ref_clk() responsible only for reference
>>>>>> clock
>>>>>>      (REF_CLK_EN) control, simplifying its purpose.
>>>>>>
>>>>>> - Remove the 10us delay workaround from imx6q_pcie_enable_ref_clk()
>>>>>> as
>>>>>>      proper sequencing is now handled by the core_reset functions.
>>>>>>
>>>>>> This refactoring ensures PHY power is controlled during reset
>>>>>> operations, fixing the boot hang while improving code maintainability.
>>>>>>
>>>>>> Fixes: 610fa91d9863 ("PCI: imx6: Assert PERST# before enabling
>>>>>> regulators")
>>>>>> Signed-off-by: Richard Zhu <hongxing.zhu at nxp.com>
>>>>> With this patch on top of v7.2-rc2 I see everything booting, lspci
>>>>> shows the root complex, but no PCIe device behind it.
>>>>> Tested on a i.MX6Q based tbs2910 board.
>>>>>
>>>>> For me it is not clear whether this fail to detect PCIe devices is
>>>>> related to the patches in question, the reset timing, or something
>>>>> else. Needs further investigation.
>>>> Thanks for your kindly help to tests.
>>>> Did you ever encounter the boot failure without this patch based on
>>>> v7.2-rc1
>>>> or later?
>>> Have not tested this. Unfortunately currently I have no access to my
>>> tbs2910 test board.
>>> I used a production system for this test here, but this is very
>>> difficult to recover from boot hangs.
>>>> After applied this patch, my i.MX6Q Sabresd board can boot up
>>>> successfully.
>>>> And the endpoint device can be detected as well.
>>>>
>>>> My Local commits:
>>>> ad5939d49b268 (HEAD -> v7.2-rc2_pcie) PCI: imx6: Add runtime PM
>>>> support for i.MX95
>>>> db7b15f198125 PCI: imx6: Update MPLLB bandwidth for i.MX95 PCIe Gen3
>>>> stability
>>>> a26735515c076 PCI: imx6: Fix i.MX6Q/DL boot hang by separating PHY
>>>> power and reference clock control
>>>> d617eadf52a46 PCI: dwc: Add force_l2 flag for platforms requiring L2
>>>> entry without D3cold 8cdeaa50eae8d (tag: v7.2-rc2) Linux 7.2-rc2
>>> My commits (v7.2-rc2 plus my patch to enable MSIs for the endpoint
>>> plus this patch discussed here):
>>> 8cdeaa50eae8 Linux 7.2-rc2
>>> b62414d07e24 PCI: imx6: Keep Root Port MSI capability also for i.MX6Q
>>> e8176c6a27ed PCI: imx6: Fix i.MX6Q/DL boot hang by separating PHY
>>> power and reference clock control
>>>
>>> I'm not sure what your other mentioned patches are.
>>>> Kernel logs:
>>>> Starting kernel ...
>>>>
>>>> [    0.000000] Booting Linux on physical CPU 0x0 [    0.000000] Linux
>>>> version 7.2.0-rc2-00004-gad5939d49b26
>>>> (nxa08258 at shlinux89) (arm-poky-linux-gnueabi-gcc (GCC) 15.2.0, GNU ld
>>>> (GNU Binutils) 2.45.0.20250908) #38 SMP Tue Jul  7 02:36:46 UTC 2026
>>>> ...
>>>> root at imx6qpdlsolox:~# lspci
>>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>> 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
>>>> Connection
>>> on linux-7.2-rc2 plus patches (see above):
>>> root at matrix2:~# lspci
>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>>
>>> on linux-7.0 (not tested on 7.1):
>>> root at matrix2:~# lspci
>>> 00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)
>>> 01:00.0 Multimedia controller: Philips Semiconductors SAA7160 (rev 02)
>>>
>>> I guess the new power-on/reset timing is not sufficient to init the
>>> endpoint in time.
>>> Did you reduce the time from powering up the PCIe slot to release of
>>> PERST#?
>>> There is a power switch on the tbs2910 board for the PCIe slot, not
>>> sure if this is available also on SabreSD.
> No, i.MX6Q Sabresd board doesn't have a power switch.
Sorry, I was wrong here. On tbs2910 there is no separate 3V3 regulator 
for the
PCIe slot, on sabresd there is (reg_pcie, gpio3 19).

At least there still is a difference, which could be a reason for the 
different
PCIe endpoint detection behavior on cold boot.

Best Regards,
Soeren
>> I found out that the endpoint device is (often?) detected after reboot, it is not
>> (never) on cold boot. (linux-7.2-rc2 plus patches) Could also point to timing
>> problems of the slot power supply (or reset duration).
>> Unfortunately I have only very limited time for testing.
> Understand, thanks for your kindly help.
>
> Best Regards
> Richard Zhu
>>> Best regards,
>>> Soeren
>>>> Best Regards
>>>> Richard Zhu
>>>>> Regards,
>>>>> Soeren