Hi, Hsin-Yi:
On Wed, 2019-05-29 at 14:08 +0800, Hsin-Yi Wang wrote:
On Wed, May 29, 2019 at 1:58 PM CK Hu ck.hu@mediatek.com wrote:
Hi, Hsin-Yi:
On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
There is no clk_prepare() called in mtk_drm_crtc_reset(), when unbinding drm device, mtk_drm_crtc_destroy() will be triggered, and the clocks will be disabled and unprepared in mtk_crtc_ddp_clk_disable. If clk_unprepare() is called here, we'll get warnings[1], so remove clk_unprepare() here.
In original code, clk_prepare() is called in mtk_drm_crtc_create() and clk_unprepare() is called in mtk_drm_crtc_destroy(). This looks correct.
clk_prepare() is removed in https://patchwork.kernel.org/patch/10872777/.
I think this patch is a fix of that patch, and I've already applied that patch, so I merge this patch with that patch in my tree [1], thanks.
[1] https://github.com/ckhu-mediatek/linux.git-tags/commit/937f861def1a1d49abb92...
Regards, CK
I don't know why we should do any thing about clock in mtk_drm_crtc_reset(). To debug this, the first step is to print message when mediatek drm call clk_prepare() and clk_unprepare(). If these two interface is called in pair, I think we should not modify mediatek drm driver, the bug maybe in clock driver.