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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.



Signed-off-by: Taniya Das <tdas@xxxxxxxxxxxxxx>
---
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
index 08d593e..6379b8b 100644
--- a/drivers/clk/qcom/gcc-sdm845.c
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -3583,6 +3611,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")) {
+               gcc_sdm845_clocks[GCC_LPASS_Q6_AXI_CLK] =
+                       &gcc_lpass_q6_axi_clk.clkr;
+               gcc_sdm845_clocks[GCC_LPASS_SWAY_CLK] =
+                       &gcc_lpass_sway_clk.clkr;

For all intents and purposes could we not just mark these two as
CLK_IS_CRITICAL and then let the LPASS turn these on and off when it
cares (does it ever do so)? Or even just turn them on once in probe here
with direct register writes and then not care anymore to touch them
again? Or do we need to turn these clks on again later on when the
subsystem crashes to read/write the registers and cycle the clks back on
and off?

+       }
+
          return qcom_cc_really_probe(pdev, &gcc_sdm845_desc, regmap);
   }

diff --git a/drivers/clk/qcom/lpasscc-sdm845.c b/drivers/clk/qcom/lpasscc-sdm845.c
new file mode 100644
index 0000000..f7b9b0f
--- /dev/null
+++ b/drivers/clk/qcom/lpasscc-sdm845.c
+               },
+       },
+};
+
+static int lpass_clocks_sdm845_probe(struct platform_device *pdev, int index,
+                                    const struct qcom_cc_desc *desc)
+{
+       struct regmap *regmap;
+       struct resource *res;
+       void __iomem *base;
+
+       res = platform_get_resource(pdev, IORESOURCE_MEM, index);
+       base = devm_ioremap_resource(&pdev->dev, res);
+       if (IS_ERR(base))
+               return PTR_ERR(base);
+
+       regmap = devm_regmap_init_mmio(&pdev->dev, base, desc->config);
+       if (IS_ERR(regmap))
+               return PTR_ERR(regmap);

If this happens again in the future we should move this into the
common.c file and let qcom_cc_probe_index() exist.


Yes, I agree, could submit a patch to add the new function and then
clean it up.

Ok, but please don't do anything now because we don't care yet.


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

--



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux