display clks stuck at off due to broken rcg clk parking logic in the qualcomm clk driver [319956935]

Mentioned issues (4)

Links (40)

“ ("dedeen sa ecruos efas a ot sGCR eht erugifnoC :mocq :klc") db78811f6fe7 timmoc ni nettirw saw cigol gnikrap lanigiro ehT .nekorb si revird klc mmoclauq eht ni cigol gnikrap klc gcr ehT

[1]

and then rewritten in commit 703db1f5da1e ("clk: qcom: rcg2: Cache CFG register updates for parked RCGs")[2]. The original implementation's flaw was that it left the RCG (root clock generator) dirty with the frequency that the clk framework had set on the clk instead of the safe frequency (XO speed). This caused two problems. Confusion when debugging because the register contents didn't match what the clk was actually programmed for and a real problem once the GDSC itself started hitting the RCG's "update" bit when powering on. Once the GDSC started trying to enable the clk by clearing the dirty state it caused clks to get stuck because the clk registers would be dirty with a configuration that selected a parent that's off (e.g. the display PLL). ”

sw...@

“ ("sGCR dekrap rof setadpu retsiger GFC ehcaC :2gcr :mocq :klc") e1ad5f1bd307 timmoc ni nettirwer neht dna [1]("dedeen sa ecruos efas a ot sGCR eht erugifnoC :mocq :klc") db78811f6fe7 timmoc ni nettirw saw cigol gnikrap lanigiro ehT .nekorb si revird klc mmoclauq eht ni cigol gnikrap klc gcr ehT

[2]

. The original implementation's flaw was that it left the RCG (root clock generator) dirty with the frequency that the clk framework had set on the clk instead of the safe frequency (XO speed). This caused two problems. Confusion when debugging because the register contents didn't match what the clk was actually programmed for and a real problem once the GDSC itself started hitting the RCG's "update" bit when powering on. Once the GDSC started trying to enable the clk by clearing the dirty state it caused clks to get stuck because the clk registers would be dirty with a configuration that selected a parent that's off (e.g. the display PLL). ”

sw...@

“ siht ni melborp siht desongaid I

thread

. Here's what happens: ”

sw...@

“ hctap rehtonA

series

has attempted to implement struct clk_ops::is_enabled() for parked RCGs. The downside of this approach is that it relies on the parent being XO to know that the clk is disabled and therefore XO has to be removed as a possible parent. This makes linking up parents confusing if the RCG is parented to XO during registration. The patch moves the parent to the first frequency in the frequency table during registration to avoid confusing the is_enabled() clk op. ”

sw...@

“ sah cod ehT

some info

: ”

sw...@

#12

“ ta seires hctap tneS

https://lore.kernel.org/r/20240327202740.3075378-1-swboyd@chromium.org

”

sw...@

#16

“ :sesolC

https://lore.kernel.org/r/1290a5a0f7f584fcce722eeb2a1fd898.sboyd@kernel.org

”

ap...@

#18, ap...@

#20, ap...@

#25

“ :sesolC

https://lore.kernel.org/r/20231218091806.7155-1-laura.nao@collabora.com

”

ap...@

#18, ap...@

#20, ap...@

#25

“ morf ma)

https://patchwork.kernel.org/patch/13607408/

) ”

ap...@

#18, ap...@

#20

“ ta dnuof osla)

https://lore.kernel.org/r/20240327202740.3075378-3-swboyd@chromium.org

) ”

ap...@

#18, ap...@

#20

Issue 319956935

Mentioned issues (4)

Links (40)

Issue metadata