Quoting Vinod Polimera (2022-03-08 08:54:56)
Kernel clock driver assumes that initial rate is the max rate for that clock and was not allowing it to scale beyond the assigned clock value.
How? I see ftbl_disp_cc_mdss_mdp_clk_src[] has multiple frequencies and clk_rcg2_shared_ops so it doesn't look like anything in the clk driver is preventing the frequency from changing beyond the assigned value.
Drop the assigned clock rate property and vote on the mdp clock as per calculated value during the usecase.
Changes in v2:
- Remove assigned-clock-rate property and set mdp clk during resume sequence.
- Add fixes tag.
Changes in v3:
- Remove extra line after fixes tag.(Stephen Boyd)
This changelog should be removed.
Fixes: 62fbdce91("arm64: dts: qcom: sc7280: add display dt nodes")
I thought folks were saying that this is bad to keep? I don't really mind either way, but I guess it's better to drop the fixes tag because this is largely a performance improvement?
Signed-off-by: Vinod Polimera quic_vpolimer@quicinc.com Reviewed-by: Stephen Boyd swboyd@chromium.org