On Mon, Jul 1, 2019 at 12:07 PM Jeffrey Hugo <jh...@codeaurora.org> wrote: > > On 7/1/2019 12:58 PM, Rob Clark wrote: > > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo <jh...@codeaurora.org> wrote: > >> > >> On 6/30/2019 9:01 AM, Rob Clark wrote: > >>> From: Rob Clark <robdcl...@chromium.org> > >>> > >>> Do an extra enable/disable cycle at init, to get the clks into disabled > >>> state in case bootloader left them enabled. > >>> > >>> In case they were already enabled, the clk_prepare_enable() has no real > >>> effect, other than getting the enable_count/prepare_count into the right > >>> state so that we can disable clocks in the correct order. This way we > >>> avoid having stuck clocks when we later want to do a modeset and set the > >>> clock rates. > >>> > >>> Signed-off-by: Rob Clark <robdcl...@chromium.org> > >>> --- > >>> drivers/gpu/drm/msm/dsi/dsi_host.c | 18 +++++++++++++++--- > >>> drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 1 + > >>> 2 files changed, 16 insertions(+), 3 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c > >>> b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c > >>> index aabab6311043..d0172d8db882 100644 > >>> --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c > >>> +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c > >>> @@ -354,6 +354,7 @@ static int dsi_pll_10nm_lock_status(struct > >>> dsi_pll_10nm *pll) > >>> if (rc) > >>> pr_err("DSI PLL(%d) lock failed, status=0x%08x\n", > >>> pll->id, status); > >>> +rc = 0; // HACK, this will fail if PLL already running.. > >> > >> Umm, why? Is this intentional? > >> > > > > I need to sort out a proper solution for this.. but PLL lock will fail > > if the clk is already running (which, in that case, is fine since it > > is already running and locked), which will cause the clk_enable to > > fail.. > > > > I guess there is some way that I can check that clk is already running > > and skip this check.. > > > I'm sorry, but this makes no sense to me. What clock are we talking > about here? > > If the pll is locked, the the lock check should just drop through. If > the pll cannot lock, you have an issue. I'm confused as to how any of > the downstream clocks can actually be running if the pll isn't locked. > > I feel like we are not yet on the same page about what situation you > seem to be in. Can you describe in exacting detail?
yeah, I'd expect the lock bit to still be set (since the display is obviously running at that point).. but I didn't really debug it yet, I just hacked that in so the clk_enable didn't fail, so that we could get correct enable/prepare_counts in order to do the clk_disable_unprepare().. BR, -R