lkml.org 
[lkml]   [2018]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v8] clk: qcom: Add lpass clock controller driver for SDM845
From
Date
Hello Stephen,

On 11/2/2018 10:08 PM, Stephen Boyd wrote:
> Quoting Taniya Das (2018-10-28 00:35:40)
>> 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, as the lpass clocks require the
>> global clock controller lpass clocks to be enabled before they are
>> accessed. Mark the GCC lpass clocks as CRITICAL, for the LPASS clock
>> access.
>
> Thanks for the useful commit text!
>
>>
>> diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
>> index 08d593e..9d60474 100644
>> --- a/drivers/clk/qcom/gcc-sdm845.c
>> +++ b/drivers/clk/qcom/gcc-sdm845.c
>> @@ -3583,6 +3613,13 @@ static int gcc_sdm845_probe(struct platform_device *pdev)
>> if (ret)
>> return ret;
>>
>> + if (!of_property_read_bool(pdev->dev.of_node, "qcom,lpass-protected")) {
>
> Bjorn told me over IRC that the QSPI clks are also protected on MTP and
> can't be read. So we're now causing MTP to fail on linus' tree. I think
> we need to add a generic property to the GCC node to indicate what clks
> are protected and shouldn't be touched by the OS. The function would go
> and knock out any protected clks by replacing their pointers with NULL.
> The property would be:
>
> protected-clocks = <clock-specifier-list>;
>
> So for this node it would look like:
>
> gcc: clock-controller@f000 {
> reg = <0xf00 0xbaf>;
>
> protected-clocks = <&gcc GCC_LPASS_Q6_AXI_CLK>,
> <&gcc GCC_LPASS_SWAY_CLK>,
> <&gcc GCC_QSPI_CORE_CLK_SRC>,
> etc.
> };
>
> Sorry for derailing this patch series so late in the process. This patch
> will need to be updated to work with that new DT property instead of
> having a custom qcom property. Otherwise the patch looks good and I
> think we're ready to merge it when the merge window closes and I can
> rewind clk-next.
>

How about moving the QSPI clocks too under this qcom property? Later
could add the support?

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

--

\
 
 \ /
  Last update: 2018-11-03 04:17    [W:0.088 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site