lkml.org 
[lkml]   [2018]   [Oct]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v6] clk: qcom: Add lpass clock controller driver for SDM845
From
Date


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.

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

--

\
 
 \ /
  Last update: 2018-10-19 12:39    [W:0.253 / U:4.388 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site