Hi,
I'm using i.MX8M Plus.
When using pcie, external clock ref is working well.
But when it comes to internal clock ref, it get weird.
root@tek3-imx8mp:~# dmesg |grep -E 'pcie|JOE'
[ 2.921505] imx6q-pcie 33800000.pcie: supply epdev_on not found, using dummy regulator
[ 2.930092] imx6q-pcie 33800000.pcie: PLL REF_CLK is used!.
[ 2.936304] imx6q-pcie 33800000.pcie: PCIe PHY PLL clock is locked.
[ 3.002561] imx6q-pcie 33800000.pcie: PCIe PLL is locked.
[ 3.010897] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[ 3.022247] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
[ 3.035663] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
[ 3.049689] imx6q-pcie 33800000.pcie: No bus range found for /soc@0/pcie@33800000, using [bus 00-ff]
[ 3.063888] imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
[ 3.079154] imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000
[ 3.094686] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[ 3.106630] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
[ 33.014729] imx6q-pcie 33800000.pcie: Link up
[ 33.019138] JOEJOE retries=298
[ 33.022203] imx6q-pcie 33800000.pcie: Link up
[ 33.026598] JOEJOE retries=0
[ 33.029486] imx6q-pcie 33800000.pcie: Link up, Gen1
[ 33.138825] imx6q-pcie 33800000.pcie: Link up
[ 33.143197] JOEJOE retries=0
[ 33.146228] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
[ 33.279021] pcieport 0000:00:00.0: PME: Signaling with IRQ 242
But for nvmem, it can link up normally.
root@tek3-imx8mp:~# dmesg |grep -E 'pcie|JOE'
[ 2.917153] imx6q-pcie 33800000.pcie: supply epdev_on not found, using dummy regulator
[ 2.925829] imx6q-pcie 33800000.pcie: PLL REF_CLK is used!.
[ 2.932041] imx6q-pcie 33800000.pcie: PCIe PHY PLL clock is locked.
[ 2.994093] imx6q-pcie 33800000.pcie: PCIe PLL is locked.
[ 3.000540] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[ 3.011289] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
[ 3.024806] imx6q-pcie 33800000.pcie: host bridge /soc@0/pcie@33800000 ranges:
[ 3.037870] imx6q-pcie 33800000.pcie: No bus range found for /soc@0/pcie@33800000, using [bus 00-ff]
[ 3.054075] imx6q-pcie 33800000.pcie: IO 0x001ff80000..0x001ff8ffff -> 0x0000000000
[ 3.067003] imx6q-pcie 33800000.pcie: MEM 0x0018000000..0x001fefffff -> 0x0018000000
[ 3.082513] imx6q-pcie 33800000.pcie: iATU unroll: enabled
[ 3.094911] imx6q-pcie 33800000.pcie: Detected iATU regions: 4 outbound, 4 inbound
[ 3.209573] imx6q-pcie 33800000.pcie: Link up
[ 3.217410] JOEJOE retries=1
[ 3.321228] imx6q-pcie 33800000.pcie: Link up
[ 3.326577] JOEJOE retries=1
[ 3.339916] imx6q-pcie 33800000.pcie: Link up, Gen3
[ 3.453694] imx6q-pcie 33800000.pcie: Link up
[ 3.463012] JOEJOE retries=0
[ 3.472765] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
[ 3.774871] pcieport 0000:00:00.0: PME: Signaling with IRQ 242
I measure the wave of clock, find nothing different between two cases.
解決済! 解決策の投稿を見る。
Hi @yoooh8668,
I hope you are doing well.
Please accept my apologies for the delay in response.
Kindly note that for PCIe connectivity, external clock is recommended. For more information, please refer to i.MX 8M Plus Hardware Developer’s Guide Table 8. PCIe recommendations and Section 3.8 PCIE connectivity.
In case of using internal clock, if the PCIe controller and the PCIE device use different clock sources, data synchronization is not guaranteed. This maybe a possible cause of higher retry counts to detect the PCIe card.
Thanks & Regards,
Ritesh M Patel
Hi @yoooh8668,
I hope you are doing well.
Please accept my apologies for the delay in response.
Kindly note that for PCIe connectivity, external clock is recommended. For more information, please refer to i.MX 8M Plus Hardware Developer’s Guide Table 8. PCIe recommendations and Section 3.8 PCIE connectivity.
In case of using internal clock, if the PCIe controller and the PCIE device use different clock sources, data synchronization is not guaranteed. This maybe a possible cause of higher retry counts to detect the PCIe card.
Thanks & Regards,
Ritesh M Patel