Hi Jonas, On 10/16/26 12:42 AM, Jonas Karlman wrote:
The CLK_PCIE30PHY_REF_M and CLK_PCIE30PHY_REF_N clocks are by default gated coming out from system reset. The probe() ops of the PMUCRU driver
Are they? I don't have an RK3568 board so cannot test this, but the TRM says the bitfields are 0 at reset with "When high, disable clock", so I am not sure what exactly this is for (except after a reboot where the Linux kernel has disabled the PCIe clocks maybe?).
unconditionally ungate these clocks to help ensure PCIe works in U-Boot proper. Change to only ungate these clocks when the PCI Kconfig option is enabled for current boot phase to delay the ungate as late as possible. Signed-off-by: Jonas Karlman <[email protected]> --- Changes in v3: - New optional patch to help delay the ungate of PCIe ref clocks until U-Boot proper This patch is strictly not needed, however it seems very unnecessary to ungate PCIe ref clocks in SPL when PCIe typically only is used in proper.
Considering the kernel seems (I had a cursory look) to be able to control those clocks and have them handled via the pcie node, it seems fine to me to possibly not have the clock enabled by U-Boot (e.g. with U-Boot proper or xPL not enabling PCI).
So, I'm fine with the content of the patch, not the commit log. Can you please confirm that they are indeed not at 0 when reset (and/or that we do this to be safe when doing reboots) and rework the commit log?
If you want, I can merge patches 2-5 from this series for 2027.01 and we can defer patch 1 here to 2027.04 if you don't have time to send a v4 in the next couple of days.
Cheers, Quentin
