From: Jeffrey Hugo <jhugo@codeaurora.org>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
freedreno <freedreno@lists.freedesktop.org>,
aarch64-laptops@lists.linaro.org,
linux-clk <linux-clk@vger.kernel.org>,
Linux PM <linux-pm@vger.kernel.org>,
Rob Clark <robdclark@chromium.org>, Sean Paul <sean@poorly.run>,
David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
Jordan Crouse <jcrouse@codeaurora.org>,
Abhinav Kumar <abhinavk@codeaurora.org>,
Sibi Sankar <sibis@codeaurora.org>,
Mamta Shukla <mamtashukla555@gmail.com>,
Chandan Uddaraju <chandanu@codeaurora.org>,
Archit Taneja <architt@codeaurora.org>,
Rajesh Yadav <ryadav@codeaurora.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init
Date: Mon, 1 Jul 2019 13:07:44 -0600 [thread overview]
Message-ID: <9fbf9226-578a-90aa-693d-9ea4fcda8281@codeaurora.org> (raw)
In-Reply-To: <CAF6AEGufiSU_sFZFdLH=KT5iCQGwccszURqAQCHd=dhuZafvZg@mail.gmail.com>
On 7/1/2019 12:58 PM, Rob Clark wrote:
> On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo <jhugo@codeaurora.org> wrote:
>>
>> On 6/30/2019 9:01 AM, Rob Clark wrote:
>>> From: Rob Clark <robdclark@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 <robdclark@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?
next prev parent reply other threads:[~2019-07-01 19:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190630150230.7878-1-robdclark@gmail.com>
2019-06-30 15:01 ` [PATCH 1/5] clk: inherit clocks enabled by bootloader Rob Clark
2019-07-01 18:02 ` [Freedreno] " Jeffrey Hugo
2019-07-01 18:25 ` Eric Anholt
2019-07-01 19:05 ` Rob Clark
2019-06-30 15:01 ` [PATCH 2/5] genpd/gdsc: inherit display powerdomain from bootloader Rob Clark
2019-07-01 18:08 ` [Freedreno] " Jeffrey Hugo
2019-06-30 15:01 ` [PATCH 3/5] drm/msm/dsi: split clk rate setting and enable Rob Clark
2019-07-01 18:32 ` [Freedreno] " Jeffrey Hugo
2019-06-30 15:01 ` [PATCH 4/5] drm/msm/dsi: get the clocks into OFF state at init Rob Clark
2019-07-01 18:37 ` Jeffrey Hugo
2019-07-01 18:58 ` Rob Clark
2019-07-01 19:07 ` Jeffrey Hugo [this message]
2019-07-01 19:34 ` Rob Clark
2019-07-02 13:53 ` Rob Clark
2019-06-30 15:01 ` [PATCH 5/5] drm/bridge: ti-sn65dsi86: support booloader enabled display Rob Clark
2019-07-01 18:39 ` Jeffrey Hugo
2019-07-02 15:20 ` Laurent Pinchart
2019-07-02 15:38 ` Rob Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9fbf9226-578a-90aa-693d-9ea4fcda8281@codeaurora.org \
--to=jhugo@codeaurora.org \
--cc=aarch64-laptops@lists.linaro.org \
--cc=abhinavk@codeaurora.org \
--cc=airlied@linux.ie \
--cc=architt@codeaurora.org \
--cc=chandanu@codeaurora.org \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jcrouse@codeaurora.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mamtashukla555@gmail.com \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=ryadav@codeaurora.org \
--cc=sean@poorly.run \
--cc=sibis@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox