Re: [PATCH 6/9] arm64: dts/media: qcom: keep PLL8 out of Purwa camss hot path

[Krzysztof Kozlowski]

On 10/06/2026 13:09, Ramshouriesh wrote:
> cam_cc_pll8 (defined in camcc-x1e80100.c) doesn't latch on Purwa
> silicon. "Lucid PLL latch failed. Output may be unstable!" fires from
> wait_for_pll() whenever something asks for a PLL8-sourced rate, and
> the camera pipeline ends up dead with "Failed to start media
> pipeline: -32" even after the qcom,x1p42100-camss compatible is in
> place.
> 
> PLL8 sneaks into the streaming path via two RCG freq tables: the
> slow_ahb RCG defaults to its 64 MHz entry (PLL8-sourced) when CSID
> pulls it during csid_set_power, and vfe_lite picks its highest entry
> (480 MHz, also PLL8) at streamon.
> 
> Fix this from the DT side:
> 
>   * pin slow_ahb at 80 MHz via assigned-clock-rates in purwa.dtsi so
>     the RCG is reprogrammed to PLL0_OUT_EVEN at clk-init time and
>     never reaches PLL8;
>   * drop the 480 MHz entry from the Purwa vfe_lite clock_rate array
>     so the driver caps at 400 MHz (PLL0_OUT_ODD).
> 
> I went poking at the Qualcomm Windows BSP shipped for the UX3407QA to
> see what rates the vendor side actually uses. The AeoB resource blob
> at qccamplatform_ext8380/CAMP_{PERF,RES}_MTP.bin lists the camera
> clocks Windows enables, and PLL8 isn't referenced once. For CCI in
> particular Windows runs at 37.5 MHz off PLL0_OUT_EVEN, not the
> 30 MHz/PLL8 alternative the Linux driver happens to pick first.
> Whether PLL8 is fused off, trust-zone-only, or just unwired on this
> SoC I don't know, but treating it as unavailable matches what the
> vendor does.
> 
> Signed-off-by: Ramshouriesh <rshouriesh@xxxxxxxxx>
> ---
>  arch/arm64/boot/dts/qcom/purwa.dtsi       | 12 ++++++++++++
>  drivers/media/platform/qcom/camss/camss.c | 16 ++++++++--------

You cannot combine such changes. DTS must be separate, see submitting
patches in DT, DTS coding style, SoC maintainer profile...

Best regards,
Krzysztof