Messages in this thread | | | Subject | Re: [PATCH v8] clk: qcom: Add lpass clock controller driver for SDM845 | From | Taniya Das <> | Date | Sat, 3 Nov 2018 08:46:20 +0530 |
| |
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.
--
| |