On 2/1/2023 1:56 AM, Stephen Boyd wrote:
Thanks for your time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2023-01-31 01:29:16)
On 1/31/2023 6:34 AM, Stephen Boyd wrote:
Thanks for your Time Stephen!!!
Quoting Srinivasa Rao Mandadapu (2023-01-26 02:14:24)
Merge lpasscc clocks into lpass_aon clk_regmap structure as they
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.
Can you describe the register ranges that are overlapping?
Okay. Will add register ranges in description.
Thanks!
Here's what I see in DT right now:
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?
Okay. As it's been coming previous patches, didn't change the name.
May be we need to do it as separate patch.
Sure, another patch to rename lpasscc to clock-controller would be
appreciated.
Yes. It's overlapping with lpass_aon ( <0 0x03380000 0 0x30000>).
CC clocks range is <0 0x03389000 0 0x24>;
Is that a new register range for lpasscc? Why do we have that node at
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?
It's not new register range. They are actually AHBM and AHBS clock
registers within lpass_aon regmap range.
Here what I meant lpasscc clocks are not of lpasscc node. I am sorry to
make you confused.
As the reg-name used as "CC", mentioning it as lpasscc clocks. I will
rephrase commit message and re-post.
Previously these two clocks are registered separately. Now we are
merging them into lpass_aon clk reg space.
Fixes: 4ab43d171181 ("clk: qcom: Add lpass clock controller driver for SC7280")
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");
We shouldn't need to check for reg-name property. Instead, the index
should be the only thing that matters.
As qcom_cc_probe() function is mapping the zero index reg property, and
in next implementation qcom_cc_really_probe() is also probing zero index
reg property,
unable to map the same region twice.
Use qcom_cc_probe_by_index()?
With this, if we mention some index and if it's not present in DT, it
will return error.
Is it okay if error is ignored and proceed?
Hence all I want here is to skip this cc clock probing by keeping some
check.
If we remove, it may cause ABI break.
I'm not sure what you mean here about ABI break, but hopefully just
using qcom_cc_probe_by_index() works!
