| Message ID | 20240418092305.2337429-5-quic_varada@quicinc.com (mailing list archive) |
|---|---|
| State | Under Review |
| Headers | show |
| Series | Add interconnect driver for IPQ9574 SoC | expand |
On 4/18/24 11:23, Varadarajan Narayanan wrote: > Unlike MSM platforms that manage NoC related clocks and scaling > from RPM, IPQ SoCs dont involve RPM in managing NoC related > clocks and there is no NoC scaling. > > However, there is a requirement to enable some NoC interface > clocks for accessing the peripheral controllers present on > these NoCs. Though exposing these as normal clocks would work, > having a minimalistic interconnect driver to handle these clocks > would make it consistent with other Qualcomm platforms resulting > in common code paths. This is similar to msm8996-cbf's usage of > icc-clk framework. > > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> > --- One more thing that we don't seem to have squared out is how to handle .sync_state. We can just jerryrig icc_sync_state in here, but I'm not sure how that goes with some floating ideas of clk_sync_state that have been tried in the past Konrad
On Tue, Apr 23, 2024 at 01:05:16AM +0200, Konrad Dybcio wrote: > > > On 4/18/24 11:23, Varadarajan Narayanan wrote: > > Unlike MSM platforms that manage NoC related clocks and scaling > > from RPM, IPQ SoCs dont involve RPM in managing NoC related > > clocks and there is no NoC scaling. > > > > However, there is a requirement to enable some NoC interface > > clocks for accessing the peripheral controllers present on > > these NoCs. Though exposing these as normal clocks would work, > > having a minimalistic interconnect driver to handle these clocks > > would make it consistent with other Qualcomm platforms resulting > > in common code paths. This is similar to msm8996-cbf's usage of > > icc-clk framework. > > > > Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> > > --- > > One more thing that we don't seem to have squared out is how to handle > .sync_state. We can just jerryrig icc_sync_state in here, but I'm not > sure how that goes with some floating ideas of clk_sync_state that have > been tried in the past Ok. Will add that and post a new version. Thanks Varada
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c index 75f09e6e057e..a6410b1828ca 100644 --- a/drivers/clk/qcom/common.c +++ b/drivers/clk/qcom/common.c @@ -8,6 +8,7 @@ #include <linux/regmap.h> #include <linux/platform_device.h> #include <linux/clk-provider.h> +#include <linux/interconnect-clk.h> #include <linux/reset-controller.h> #include <linux/of.h> @@ -234,6 +235,38 @@ static struct clk_hw *qcom_cc_clk_hw_get(struct of_phandle_args *clkspec, return cc->rclks[idx] ? &cc->rclks[idx]->hw : NULL; } +static int qcom_cc_icc_register(struct device *dev, + const struct qcom_cc_desc *desc) +{ + struct icc_clk_data *icd; + struct clk_hw *hws; + int i; + + if (!IS_ENABLED(CONFIG_INTERCONNECT_CLK)) + return 0; + + if (!desc->icc_hws) + return 0; + + icd = devm_kcalloc(dev, desc->num_icc_hws, sizeof(*icd), GFP_KERNEL); + if (!icd) + return -ENOMEM; + + for (i = 0; i < desc->num_icc_hws; i++) { + icd[i].master_id = desc->icc_hws[i].master_id; + icd[i].slave_id = desc->icc_hws[i].slave_id; + hws = &desc->clks[desc->icc_hws[i].clk_id]->hw; + icd[i].clk = devm_clk_hw_get_clk(dev, hws, "icc"); + if (!icd[i].clk) + return dev_err_probe(dev, -ENOENT, + "(%d) clock entry is null\n", i); + icd[i].name = clk_hw_get_name(hws); + } + + return devm_icc_clk_register(dev, desc->icc_first_node_id, + desc->num_icc_hws, icd); +} + int qcom_cc_really_probe(struct platform_device *pdev, const struct qcom_cc_desc *desc, struct regmap *regmap) { @@ -303,7 +336,7 @@ int qcom_cc_really_probe(struct platform_device *pdev, if (ret) return ret; - return 0; + return qcom_cc_icc_register(dev, desc); } EXPORT_SYMBOL_GPL(qcom_cc_really_probe); diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h index 9c8f7b798d9f..ea96b2ca3cac 100644 --- a/drivers/clk/qcom/common.h +++ b/drivers/clk/qcom/common.h @@ -19,6 +19,12 @@ struct clk_hw; #define PLL_VOTE_FSM_ENA BIT(20) #define PLL_VOTE_FSM_RESET BIT(21) +struct qcom_icc_hws_data { + int master_id; + int slave_id; + int clk_id; +}; + struct qcom_cc_desc { const struct regmap_config *config; struct clk_regmap **clks; @@ -29,6 +35,9 @@ struct qcom_cc_desc { size_t num_gdscs; struct clk_hw **clk_hws; size_t num_clk_hws; + struct qcom_icc_hws_data *icc_hws; + size_t num_icc_hws; + unsigned int icc_first_node_id; }; /**
Unlike MSM platforms that manage NoC related clocks and scaling from RPM, IPQ SoCs dont involve RPM in managing NoC related clocks and there is no NoC scaling. However, there is a requirement to enable some NoC interface clocks for accessing the peripheral controllers present on these NoCs. Though exposing these as normal clocks would work, having a minimalistic interconnect driver to handle these clocks would make it consistent with other Qualcomm platforms resulting in common code paths. This is similar to msm8996-cbf's usage of icc-clk framework. Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> --- v9: Remove HWS_DATA macro v8: Explicitly set master and slave ids v7: Restore clk_get v6: first_id -> icc_first_node_id Remove clock get so that the peripheral that uses the clock can do the clock get v5: Split changes in common.c to separate patch Fix error handling Use devm_icc_clk_register instead of icc_clk_register v4: Use clk_hw instead of indices Do icc register in qcom_cc_probe() call stream Add icc clock info to qcom_cc_desc structure v3: Use indexed identifiers here to avoid confusion Fix error messages and move to common.c v2: Move DTS to separate patch Update commit log Auto select CONFIG_INTERCONNECT & CONFIG_INTERCONNECT_CLK to fix build error --- drivers/clk/qcom/common.c | 35 ++++++++++++++++++++++++++++++++++- drivers/clk/qcom/common.h | 9 +++++++++ 2 files changed, 43 insertions(+), 1 deletion(-)