[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <42e20a5e-beb4-fdc1-cf4a-f6329b09a476@codeaurora.org>
Date: Wed, 17 Oct 2018 17:34:10 +0530
From: Taniya Das <tdas@...eaurora.org>
To: Stephen Boyd <sboyd@...nel.org>,
Michael Turquette <mturquette@...libre.com>
Cc: Andy Gross <andy.gross@...aro.org>,
David Brown <david.brown@...aro.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6] clk: qcom: Add lpass clock controller driver for
SDM845
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.
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.
....
}
Please let me know your comments in case I missed something.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Powered by blists - more mailing lists