Re: [PATCH v6] clk: qcom: Add lpass clock controller driver for SDM845

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 v6] clk: qcom: Add lpass clock controller driver for SDM845
Date: Wed, 17 Oct 2018 17:07:29 +0530	[thread overview]
Message-ID: <7ad2344b-2307-3fb3-c34e-7443fb3a1ec8@codeaurora.org> (raw)
In-Reply-To: <153936574404.5275.10513827793530511886@swboyd.mtv.corp.google.com>

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.

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

--