From: 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,
linux-clk-owner@vger.kernel.org
Subject: Re: [PATCH v6] clk: qcom: Add lpass clock controller driver for SDM845
Date: Thu, 25 Oct 2018 16:21:01 +0530 [thread overview]
Message-ID: <360c18d625d6e4792e9ba830c6d0b6ea@codeaurora.org> (raw)
In-Reply-To: <5f1b1ab5-e2eb-05ff-7b6d-8557f6dd2ad9@codeaurora.org>
On 2018-10-19 16:09, Taniya Das wrote:
> On 10/17/2018 7:50 PM, Stephen Boyd wrote:
>> Quoting Taniya Das (2018-10-17 05:04:10)
>>>
>>>
>>> On 10/17/2018 5:07 PM, Taniya Das wrote:
>>>> Hello Stephen,
>>>>
>>>> On 10/12/2018 11:05 PM, Stephen Boyd wrote:
>>>>> Quoting Taniya Das (2018-10-09 23:12:27)
>>>>>>
>>>>>>
>>>>>> On 10/10/2018 2:22 AM, Stephen Boyd wrote:
>>>>>>> Quoting Taniya Das (2018-10-09 10:26:38)
>>>>>>>> Hello Stephen,
>>>>>>>>
>>>>>>>> On 10/8/2018 8:14 AM, Stephen Boyd wrote:
>>>>>>>>> Quoting Taniya Das (2018-10-04 05:02:26)
>>>>>>>>>> Add support for the lpass clock controller found on SDM845
>>>>>>>>>> based
>>>>>>>>>> devices.
>>>>>>>>>> This would allow lpass peripheral loader drivers to control
>>>>>>>>>> the
>>>>>>>>>> clocks to
>>>>>>>>>> bring the subsystem out of reset.
>>>>>>>>>> LPASS clocks present on the global clock controller would be
>>>>>>>>>> registered
>>>>>>>>>> with the clock framework based on the device tree flag. Also
>>>>>>>>>> do
>>>>>>>>>> not gate
>>>>>>>>>> these clocks if they are left unused.
>>>>>>>>>
>>>>>>>>> Why not gate them? This statement states what the code is
>>>>>>>>> doing,
>>>>>>>>> not why
>>>>>>>>> it's doing it which is the more crucial information that should
>>>>>>>>> be
>>>>>>>>> described in the commit text. Also, please add a comment about
>>>>>>>>> it
>>>>>>>>> to the
>>>>>>>>> code next to the flag.
>>>>>>>>>
>>>>>>>>> I am concerned that it doesn't make any sense though, so
>>>>>>>>> probably it
>>>>>>>>> shouldn't be marked as CLK_IGNORE_UNUSED and it's papering over
>>>>>>>>> some
>>>>>>>>> other larger bug that needs to be fixed.
>>>>>>>>>
>>>>>>>>
>>>>>>>> It does not have any bug, it is just that to access these lpass
>>>>>>>> registers we would need the GCC lpass registers to be enabled. I
>>>>>>>> would
>>>>>>>> update the same in the commit text.
>>>>>>>>
>>>>>>>> During clock late_init these clocks should not be accessed to
>>>>>>>> check
>>>>>>>> the
>>>>>>>> clock status as they would result in unclocked access. The
>>>>>>>> client
>>>>>>>> would
>>>>>>>> request these clocks in the correct order and it would not have
>>>>>>>> any
>>>>>>>> issue.
>>>>>>>>
>>>>>>>
>>>>>>> That seems like the bug right there. If the LPASS registers can't
>>>>>>> be
>>>>>>> accessed unless the clks in GCC are enabled then this driver
>>>>>>> needs to
>>>>>>> turn the clks on before reading/writing registers. Marking the
>>>>>>> clks as
>>>>>>> ignore unused is skipping around the real problem.
>>>>>>>
>>>>>>
>>>>>> If the driver requests for the clocks they would maintain the
>>>>>> order. But
>>>>>> if the clock late init call is invoked before the driver requests,
>>>>>> there
>>>>>> is no way I could manage this dependency, that is the only reason
>>>>>> to
>>>>>> mark them unused.
>>>>>>
>>>>>
>>>>> Which driver are we talking about here? The lpass clk driver?
>>>>> Presumably
>>>>> the lpass clk driver would request the GCC clks and turn them on in
>>>>> probe and then register any lpass clks. If the lpass clk driver
>>>>> probes
>>>>> bfeore late init, then the gcc clks will be enabled and everything
>>>>> works, and if the lpass clk driver probes after late init then the
>>>>> clks
>>>>> that can't be touched without gcc clks enabled won't be registered,
>>>>> and
>>>>> then they won't be touched. What goes wrong?
>>>>>
>>>>>
>>>>
>>>> Okay, sure, I will take the GCC clock handles and then
>>>> enable/disable
>>>> them accordingly.
>>>>
>>>> I missed earlier, so here is what you suggest
>>>
>>> gcc_probe --> GCC LPASS clocks registered.
>>> lpass_probe --> clk_get on gcc_lpass_clocks/ clk_prepare_enable -->
>>> register the lpass clocks --> clk_disable_unprepare gcc_lpass_clocks.
>>
>> Why did the gcc_lpass_clocks get turned off? Shouldn't they just stay
>> enabled all the time?
>>
>
> I don't think they are kept enabled all the time.
>
>>>
>>> But the problem is not during the above. It is the below
>>> static void clk_disable_unused_subtree(struct clk_core *core)
>>> {
>>> ....
>>>
>>> if (clk_core_is_enabled(core)) { --> This access fails.
>>> ....
>>>
>>> }
>>>
>>
>> You may need to add some prepare_ops to turn on clks needed to
>> read/write lpass registers. Or you can look into using some sort of
>> genpd to enable required clks when these clks are enabled or disabled.
>> But I suspect it would be easier to just leave the clks in GCC for
>> lpass
>> always enabled and not worry about the complicated genpd things.
>>
>
> I need to check if keeping them enabled/marking them CRITICAL could
> have an impact on the reset of the subsystem.
I have checked internally with the teams and the GCC LPASS clocks could
be left enabled.
Would submit a patch keeping them CRITICAL.
next prev parent reply other threads:[~2018-10-25 10:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 12:02 [PATCH v6] Add support for LPASS clock controller for SDM845 Taniya Das
2018-10-04 12:02 ` [PATCH v6] clk: qcom: Add lpass clock controller driver " Taniya Das
2018-10-08 2:44 ` Stephen Boyd
2018-10-08 2:44 ` Stephen Boyd
2018-10-09 17:26 ` Taniya Das
2018-10-09 20:52 ` Stephen Boyd
2018-10-10 6:12 ` Taniya Das
2018-10-12 17:35 ` Stephen Boyd
2018-10-17 11:37 ` Taniya Das
2018-10-17 12:04 ` Taniya Das
2018-10-17 14:20 ` Stephen Boyd
2018-10-19 10:39 ` Taniya Das
2018-10-25 10:51 ` tdas [this message]
2018-10-29 18:44 ` Stephen Boyd
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=360c18d625d6e4792e9ba830c6d0b6ea@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-owner@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.