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

[Taniya Das]

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.

--