Hi Jonas, Quentin, We are an embedded design house building products on the RK3576, and this series lines up with several clock-related issues we have hit during our own U-Boot bring-up. Thanks for putting it together ― and for the honest note that some of these fixes are only compile-tested. That is exactly the gap we can help close. On the RK3576 side specifically, the fixes in patch 11 that matter most to us in production are the VPLL mode register correction (we rely on VPLL for display clocks) and the PPLL base fix from PMU domain to PHP domain (PPLL feeds the DRAM controller, so a wrong register window here is the kind of thing that only shows up as intermittent instability rather than a clean failure).
Happy to share more concrete observations if useful. On Quentin's point about RK3576_MODE_CON0 being incorrect for PPLL but masked by ROCKCHIP_PLL_FIXED_MODE: I agree a new macro is the right long-term direction, and I would add one more angle ― the same latent hazard exists in the RK3588 PPLL entry, so whatever we settle on should be applied to both drivers in the same series. In the meantime, a compile-time assertion in the PLL() macro (e.g. BUILD_BUG_ON when FIXED_MODE is set but a mode register is still required) would prevent future contributors from silently reintroducing the wrong address. If useful, we can draft that as a follow-up patch. Finally, if a v2 is not already in flight: we would be happy to test patches 4, 5, and 11 on our RK3576 reference hardware (DDR init, VPLL/display bring-up, and I2C parent selection are all exercised during our regular boot testing) and provide Tested-by tags plus any rate mismatches we observe. Best regards, Owen Boardcon Embedded Design Limited https://www.boardcon.com
