Quoting Srinivasa Rao Mandadapu (2023-01-31 01:29:16)
On 1/31/2023 6:34 AM, Stephen Boyd wrote:Thanks!
Thanks for your Time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2023-01-26 02:14:24)Okay. Will add register ranges in description.
Merge lpasscc clocks into lpass_aon clk_regmap structure as theyCan you describe the register ranges that are overlapping?
are using same register space.
Add conditional check for doing lpasscc clock registration only
if regname specified in device tree node.
In existing implementation, lpasscc clocks and lpass_aon clocks are
being registered exclusively and overlapping if both of them are
to be used.
This is required to avoid such overlapping and to register
lpasscc clocks and lpass_aon clocks simultaneously.
Sure, another patch to rename lpasscc to clock-controller would beHere's what I see in DT right now:Okay. As it's been coming previous patches, didn't change the name.
lpasscc: lpasscc@3000000 {
compatible = "qcom,sc7280-lpasscc";
reg = <0 0x03000000 0 0x40>,
<0 0x03c04000 0 0x4>;
...
};
lpass_audiocc: clock-controller@3300000 {
compatible = "qcom,sc7280-lpassaudiocc";
reg = <0 0x03300000 0 0x30000>,
<0 0x032a9000 0 0x1000>;
...
};
lpass_aon: clock-controller@3380000 {
compatible = "qcom,sc7280-lpassaoncc";
reg = <0 0x03380000 0 0x30000>;
...
};
lpass_core: clock-controller@3900000 {
compatible = "qcom,sc7280-lpasscorecc";
reg = <0 0x03900000 0 0x50000>;
...
};
Presumably lpascc is really supposed to be a node named
'clock-controller' and is the node that is overlapping with lpass_aon?
May be we need to do it as separate patch.
appreciated.
Yes. It's overlapping with lpass_aon ( <0 0x03380000 0 0x30000>).Is that a new register range for lpasscc? Why do we have that node at
CC clocks range is <0 0x03389000 0 0x24>;
all? Can we add different properties to the existing lpass_audiocc,
lpass_aon, or lpass_core nodes to indicate what clks should or shouldn't
be registered or provided to the kernel?
Use qcom_cc_probe_by_index()?As qcom_cc_probe() function is mapping the zero index reg property, andFixes: 4ab43d171181 ("clk: qcom: Add lpass clock controller driver for SC7280")We shouldn't need to check for reg-name property. Instead, the index
Signed-off-by: Srinivasa Rao Mandadapu <quic_srivasam@xxxxxxxxxxx>
Tested-by: Mohammad Rafi Shaik <quic_mohs@xxxxxxxxxxx>
---
drivers/clk/qcom/lpassaudiocc-sc7280.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/qcom/lpassaudiocc-sc7280.c b/drivers/clk/qcom/lpassaudiocc-sc7280.c
index 1339f92..8e2f433 100644
--- a/drivers/clk/qcom/lpassaudiocc-sc7280.c
+++ b/drivers/clk/qcom/lpassaudiocc-sc7280.c
@@ -826,10 +829,12 @@ static int lpass_aon_cc_sc7280_probe(struct platform_device *pdev)
return ret;
if (of_property_read_bool(pdev->dev.of_node, "qcom,adsp-pil-mode")) {
- lpass_audio_cc_sc7280_regmap_config.name = "cc";
- desc = &lpass_cc_sc7280_desc;
- ret = qcom_cc_probe(pdev, desc);
- goto exit;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cc");
should be the only thing that matters.
in next implementation qcom_cc_really_probe() is also probing zero index
reg property,
unable to map the same region twice.
Hence all I want here is to skip this cc clock probing by keeping someI'm not sure what you mean here about ABI break, but hopefully just
check.
If we remove, it may cause ABI break.
using qcom_cc_probe_by_index() works!