mailbox: mtk-cmdq-mailbox: Implement Runtime PM with autosuspend
MediaTek found an issue with display HW registers configuration, and located the reason in the CMDQ Mailbox driver; reporting the original comment with the analysis of this problem by Jason-JH Lin: GCE should config HW in every vblanking duration. The stream done event is the start signal of vblanking. If stream done event is sent between GCE clk_disable and clk_enable. After GCE clk_enable the stream done event may not appear immediately and have about 3us delay. Normal case: clk_disable -> get EventA -> clk_enable -> clear EventA -> wait EventB -> get EventB -> config HW Abnormal case: clk_disable -> get EventA -> clk_enable -> EventA delay appear -> clear EventA fail -> wait EventB but get EventA -> config HW This abnormal case may configure display HW in the vactive or non-vblanking duration. From his analysis we get that the GCE may finish its event processing after some amount of time (and not immediately after sending commands to it); since the GCE is used for more than just display, and it gets used frequently, solve this issue by implementing Runtime PM handlers with autosuspend: this allows us to overcome to the remote processor delay issues and reduce the clock enable()/disable() calls, while also still managing to save some power, which is something that we wouldn't be able to do if we just enable the GCE clocks at probe. Speaking of which: if Runtime PM is not available there will obviously be no way to get this power saving action so, in this case, the clocks will be enabled at probe() time, kept enabled for the entire driver's life and disabled at remove(). Reported-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Showing
Please register or sign in to comment