Messages in this thread | | | Subject | Re: [PATCH v2 5/9] clk: qcom: rcg2: Stop hardcoding gfx3d pingpong parent numbers | From | AngeloGioacchino Del Regno <> | Date | Thu, 11 Feb 2021 22:46:14 +0100 |
| |
Il 11/02/21 21:19, Stephen Boyd ha scritto: > Quoting AngeloGioacchino Del Regno (2021-01-13 10:38:13) >> The function clk_gfx3d_determine_rate is selecting different PLLs >> to manage the GFX3D clock source in a special way: this one needs >> to be ping-pong'ed on different PLLs to ensure stability during >> frequency switching (set a PLL rate, let it stabilize, switch the >> RCG to the new PLL) and fast frequency transitions. >> >> This technique is currently being used in the MSM8996 SoC and the >> function was assuming that the parents were always at a specific >> index in the parents list, which is TRUE, if we use this only on >> the MSM8996 MMCC. >> Unfortunately, MSM8996 is not the only SoC that needs to ping-pong >> the graphics RCG, so choices are: >> 1. Make new special ops just to hardcode *again* other indexes, >> creating code duplication for (imo) no reason; or >> 2. Generalize this function, so that it becomes usable for a range >> of SoCs with slightly different ping-pong configuration. >> >> In this commit, the second road was taken: define a new "special" >> struct clk_rcg2_gfx3d, containing the ordered list of parents to >> ping-pong the graphics clock on, and the "regular" rcg2 clock >> structure in order to generalize the clk_gfx3d_determine_rate >> function and make it working for other SoCs. >> >> As for the function itself it is left with the assumption that we >> need to ping-pong over three parents. The reasons for this are: >> 1. The initial model was MSM8996, which has 3 parents for the >> graphics clock pingpong; >> 2. The other example that was taken into consideration is the >> SDM630/636/660 SoC gpu clock controller, which is ping-ponging >> over two dynamic clocked and one fixed clock PLL. >> >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> >> --- > > Applied to clk-next but I modified it a bunch. Let me know if it doesn't > work. >
Will check asap!
| |