Re: [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init
From: Rob Clark
Date: Mon Jul 01 2019 - 15:34:46 EST
On Mon, Jul 1, 2019 at 12:07 PM Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote:
> On 7/1/2019 12:58 PM, Rob Clark wrote:
> > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo <jhugo@xxxxxxxxxxxxxx> wrote:
> >> On 6/30/2019 9:01 AM, Rob Clark wrote:
> >>> From: Rob Clark <robdclark@xxxxxxxxxxxx>
> >>> 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 <robdclark@xxxxxxxxxxxx>
> >>> ---
> >>> 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