All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taniya Das <tdas@codeaurora.org>
To: Stephen Boyd <sboyd@kernel.org>,
	Michael Turquette <mturquette@baylibre.com>
Cc: Andy Gross <andy.gross@linaro.org>,
	David Brown <david.brown@linaro.org>,
	Rajendra Nayak <rnayak@codeaurora.org>,
	linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] clk: qcom: lpass: Add CLK_IGNORE_UNUSED for lpass clocks
Date: Mon, 7 Jan 2019 11:56:00 +0530	[thread overview]
Message-ID: <b6397ef1-a6df-0040-9dcc-c491b76a2f8f@codeaurora.org> (raw)
In-Reply-To: <154533989563.79149.10213938035592547726@swboyd.mtv.corp.google.com>

Hello Stephen,

On 12/21/2018 2:34 AM, Stephen Boyd wrote:
> Quoting Taniya Das (2018-12-20 03:46:25)
>> The LPASS clocks has a dependency on the GCC lpass clocks to be enabled
>> before accessing them and that was the reason to mark the gcc lpass clocks
>> as critical. But in the case where the lpass subsystem would require a
>> restart, toggling the lpass reset would from HW clear the SW enable bits
>> of the GCC lpass clocks. Thus the next time bringing up the lpass subsystem
>> out of reset would fail.
>>
>> Allow the lpass clock driver to enable/disable the gcc lpass clocks and
>> mark the lpass clocks not be accessed during late_init if no client vote.
> 
> You need to add more details here. It feels like you wrote the beginning
> of a paragraph and then stopped abruptly, leaving the reader hanging for
> the whole story. Why is late_init important? Why do we need to leave
> them on from the bootloader? What if the bootloader doesn't leave them
> enabled? This is all rather hacky so I'm deeply confused. Does the lpass
> driver need to get these gcc clks and enable/prepare them during probe?
> But then it needs to also allow a reset happen and change the clk state?
> 
> I suspect this situation is circling a larger problem where a reset is
> toggled and that changes some clk state without the clk framework
> knowing. There's not much we can do about that besides having some
> mechanism for the clks to know that their state is now out of sync. If
> that can be done on the provider driver side then we should have an
> easier time not needing to write a bunch of framework code to handle
> this. OMAP folks are dealing with the same problems from what I recall.
> 

Hmm, if I mark the CLK_IS_CRITICAL, I don't see a way to handle it in 
provider. Please suggest if you think provider could handle it.

>>
>> Signed-off-by: Taniya Das <tdas@codeaurora.org>
> 
>> @@ -77,6 +81,7 @@
>>                  .enable_mask = BIT(0),
>>                  .hw.init = &(struct clk_init_data){
>>                          .name = "lpass_qdsp6ss_sleep_clk",
>> +                       .flags = CLK_IGNORE_UNUSED,
> 
> All uses of CLK_IGNORE_UNUSED and CLK_IS_CRITICAL need comments about
> why they're there. It's never obvious why these things are being done.
> 

Sure, would add comments.

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.

--

  reply	other threads:[~2019-01-07  6:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-20 11:46 [PATCH v1] clk: qcom: lpass: Add CLK_IGNORE_UNUSED for lpass clocks Taniya Das
2018-12-20 21:04 ` Stephen Boyd
2018-12-20 21:04   ` Stephen Boyd
2019-01-07  6:26   ` Taniya Das [this message]
2019-01-07 21:04     ` Stephen Boyd
2019-01-14  6:12       ` Taniya Das
2019-01-14 22:25         ` Stephen Boyd
2019-01-17 11:19           ` Taniya Das
2019-01-18 19:01             ` Stephen Boyd
2019-01-22  9:31               ` Taniya Das
2019-02-13  7:17 ` Bjorn Andersson

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=b6397ef1-a6df-0040-9dcc-c491b76a2f8f@codeaurora.org \
    --to=tdas@codeaurora.org \
    --cc=andy.gross@linaro.org \
    --cc=david.brown@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-soc@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=rnayak@codeaurora.org \
    --cc=sboyd@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.