Add a clock driver for the TCSR clock controller found on Glymur, which
provides refclks for PCIE, USB, and UFS.
Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
---
drivers/clk/qcom/Kconfig | 8 ++
drivers/clk/qcom/Makefile | 1 +
drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
3 files changed, 266 insertions(+)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 36d6e6e1e7f0162d53f02f39125f4593517e0dba..ed523cf52a7613e2a518f2a802b9451bb73c43f6 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -19,6 +19,14 @@ menuconfig COMMON_CLK_QCOM
if COMMON_CLK_QCOM
+config CLK_GLYMUR_TCSRCC
+ tristate "GLYMUR TCSR Clock Controller"
+ depends on ARM64 || COMPILE_TEST
+ select QCOM_GDSC
+ help
+ Support for the TCSR clock controller on GLYMUR devices.
+ Say Y if you want to use peripheral devices such as USB/PCIe/EDP.
+
config CLK_X1E80100_CAMCC
tristate "X1E80100 Camera Clock Controller"
depends on ARM64 || COMPILE_TEST
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index ab59434338bb6d6f49b0af94ff0f85cb386a16db..e29f6e646ec69fc956ae4c55350dacab79398c18 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -21,6 +21,7 @@ clk-qcom-$(CONFIG_QCOM_GDSC) += gdsc.o
obj-$(CONFIG_APQ_GCC_8084) += gcc-apq8084.o
obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
obj-$(CONFIG_CLK_GFM_LPASS_SM8250) += lpass-gfm-sm8250.o
+obj-$(CONFIG_CLK_GLYMUR_TCSRCC) += tcsrcc-glymur.o
obj-$(CONFIG_CLK_X1E80100_CAMCC) += camcc-x1e80100.o
obj-$(CONFIG_CLK_X1E80100_DISPCC) += dispcc-x1e80100.o
obj-$(CONFIG_CLK_X1E80100_GCC) += gcc-x1e80100.o
diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
new file mode 100644
index 0000000000000000000000000000000000000000..7debfdc87a552a79bc081f28c34ae18e031ff2e6
--- /dev/null
+++ b/drivers/clk/qcom/tcsrcc-glymur.c
@@ -0,0 +1,257 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2025, Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/clock/qcom,glymur-tcsr.h>
+
+#include "clk-alpha-pll.h"
+#include "clk-branch.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-regmap.h"
+#include "clk-regmap-divider.h"
+#include "clk-regmap-mux.h"
+#include "common.h"
+#include "gdsc.h"
+#include "reset.h"
+
+static struct clk_branch tcsr_edp_clkref_en = {
+ .halt_reg = 0x1c,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x1c,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_edp_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_pcie_1_clkref_en = {
+ .halt_reg = 0x4,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x4,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_pcie_1_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_pcie_2_clkref_en = {
+ .halt_reg = 0x8,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x8,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_pcie_2_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_pcie_3_clkref_en = {
+ .halt_reg = 0x10,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x10,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_pcie_3_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_pcie_4_clkref_en = {
+ .halt_reg = 0x14,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x14,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_pcie_4_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb2_1_clkref_en = {
+ .halt_reg = 0x28,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x28,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb2_1_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb2_2_clkref_en = {
+ .halt_reg = 0x2c,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x2c,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb2_2_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb2_3_clkref_en = {
+ .halt_reg = 0x30,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x30,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb2_3_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb2_4_clkref_en = {
+ .halt_reg = 0x44,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x44,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb2_4_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb3_0_clkref_en = {
+ .halt_reg = 0x20,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x20,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb3_0_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb3_1_clkref_en = {
+ .halt_reg = 0x24,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x24,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb3_1_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb4_1_clkref_en = {
+ .halt_reg = 0x0,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x0,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb4_1_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch tcsr_usb4_2_clkref_en = {
+ .halt_reg = 0x18,
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x18,
+ .enable_mask = BIT(0),
+ .hw.init = &(const struct clk_init_data) {
+ .name = "tcsr_usb4_2_clkref_en",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_regmap *tcsr_cc_glymur_clocks[] = {
+ [TCSR_EDP_CLKREF_EN] = &tcsr_edp_clkref_en.clkr,
+ [TCSR_PCIE_1_CLKREF_EN] = &tcsr_pcie_1_clkref_en.clkr,
+ [TCSR_PCIE_2_CLKREF_EN] = &tcsr_pcie_2_clkref_en.clkr,
+ [TCSR_PCIE_3_CLKREF_EN] = &tcsr_pcie_3_clkref_en.clkr,
+ [TCSR_PCIE_4_CLKREF_EN] = &tcsr_pcie_4_clkref_en.clkr,
+ [TCSR_USB2_1_CLKREF_EN] = &tcsr_usb2_1_clkref_en.clkr,
+ [TCSR_USB2_2_CLKREF_EN] = &tcsr_usb2_2_clkref_en.clkr,
+ [TCSR_USB2_3_CLKREF_EN] = &tcsr_usb2_3_clkref_en.clkr,
+ [TCSR_USB2_4_CLKREF_EN] = &tcsr_usb2_4_clkref_en.clkr,
+ [TCSR_USB3_0_CLKREF_EN] = &tcsr_usb3_0_clkref_en.clkr,
+ [TCSR_USB3_1_CLKREF_EN] = &tcsr_usb3_1_clkref_en.clkr,
+ [TCSR_USB4_1_CLKREF_EN] = &tcsr_usb4_1_clkref_en.clkr,
+ [TCSR_USB4_2_CLKREF_EN] = &tcsr_usb4_2_clkref_en.clkr,
+};
+
+static const struct regmap_config tcsr_cc_glymur_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x44,
+ .fast_io = true,
+};
+
+static const struct qcom_cc_desc tcsr_cc_glymur_desc = {
+ .config = &tcsr_cc_glymur_regmap_config,
+ .clks = tcsr_cc_glymur_clocks,
+ .num_clks = ARRAY_SIZE(tcsr_cc_glymur_clocks),
+};
+
+static const struct of_device_id tcsr_cc_glymur_match_table[] = {
+ { .compatible = "qcom,glymur-tcsr" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, tcsr_cc_glymur_match_table);
+
+static int tcsr_cc_glymur_probe(struct platform_device *pdev)
+{
+ return qcom_cc_probe(pdev, &tcsr_cc_glymur_desc);
+}
+
+static struct platform_driver tcsr_cc_glymur_driver = {
+ .probe = tcsr_cc_glymur_probe,
+ .driver = {
+ .name = "tcsrcc-glymur",
+ .of_match_table = tcsr_cc_glymur_match_table,
+ },
+};
+
+static int __init tcsr_cc_glymur_init(void)
+{
+ return platform_driver_register(&tcsr_cc_glymur_driver);
+}
+subsys_initcall(tcsr_cc_glymur_init);
+
+static void __exit tcsr_cc_glymur_exit(void)
+{
+ platform_driver_unregister(&tcsr_cc_glymur_driver);
+}
+module_exit(tcsr_cc_glymur_exit);
+
+MODULE_DESCRIPTION("QTI TCSRCC GLYMUR Driver");
+MODULE_LICENSE("GPL");
--
2.34.1On 25-07-29 11:12:37, Taniya Das wrote:
> Add a clock driver for the TCSR clock controller found on Glymur, which
> provides refclks for PCIE, USB, and UFS.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 8 ++
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 266 insertions(+)
>
[...]
> +
> +static struct clk_branch tcsr_edp_clkref_en = {
> + .halt_reg = 0x1c,
> + .halt_check = BRANCH_HALT_DELAY,
> + .clkr = {
> + .enable_reg = 0x1c,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "tcsr_edp_clkref_en",
> + .ops = &clk_branch2_ops,
As discussed off-list, these clocks need to have the bi_tcxo as parent.
Otherwise, as far as the CCF is concerned these clocks will have rate 0,
which is obviously not the case.
Bringing this here since there is a disconnect between X Elite and
Glymur w.r.t this now.
On 7/30/2025 4:55 PM, Abel Vesa wrote:
> On 25-07-29 11:12:37, Taniya Das wrote:
>> Add a clock driver for the TCSR clock controller found on Glymur, which
>> provides refclks for PCIE, USB, and UFS.
>>
>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>> ---
>> drivers/clk/qcom/Kconfig | 8 ++
>> drivers/clk/qcom/Makefile | 1 +
>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 266 insertions(+)
>>
>
> [...]
>
>> +
>> +static struct clk_branch tcsr_edp_clkref_en = {
>> + .halt_reg = 0x1c,
>> + .halt_check = BRANCH_HALT_DELAY,
>> + .clkr = {
>> + .enable_reg = 0x1c,
>> + .enable_mask = BIT(0),
>> + .hw.init = &(const struct clk_init_data) {
>> + .name = "tcsr_edp_clkref_en",
>> + .ops = &clk_branch2_ops,
>
> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>
> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
> which is obviously not the case.
>
> Bringing this here since there is a disconnect between X Elite and
> Glymur w.r.t this now.
The ref clocks are not required to be have a parent of bi_tcxo as these
ideally can be left enabled(as a subsystem requirement) even if HLOS
(APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
HLOS/APSS will not allow APSS to collapse.
If any consumers needs the clock rate, the driver should take the
BI_TCXO handle.
--
Thanks,
Taniya Das
On 25-08-01 10:02:15, Taniya Das wrote:
>
>
> On 7/30/2025 4:55 PM, Abel Vesa wrote:
> > On 25-07-29 11:12:37, Taniya Das wrote:
> >> Add a clock driver for the TCSR clock controller found on Glymur, which
> >> provides refclks for PCIE, USB, and UFS.
> >>
> >> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> >> ---
> >> drivers/clk/qcom/Kconfig | 8 ++
> >> drivers/clk/qcom/Makefile | 1 +
> >> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 266 insertions(+)
> >>
> >
> > [...]
> >
> >> +
> >> +static struct clk_branch tcsr_edp_clkref_en = {
> >> + .halt_reg = 0x1c,
> >> + .halt_check = BRANCH_HALT_DELAY,
> >> + .clkr = {
> >> + .enable_reg = 0x1c,
> >> + .enable_mask = BIT(0),
> >> + .hw.init = &(const struct clk_init_data) {
> >> + .name = "tcsr_edp_clkref_en",
> >> + .ops = &clk_branch2_ops,
> >
> > As discussed off-list, these clocks need to have the bi_tcxo as parent.
> >
> > Otherwise, as far as the CCF is concerned these clocks will have rate 0,
> > which is obviously not the case.
> >
> > Bringing this here since there is a disconnect between X Elite and
> > Glymur w.r.t this now.
>
>
> The ref clocks are not required to be have a parent of bi_tcxo as these
> ideally can be left enabled(as a subsystem requirement) even if HLOS
> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
> HLOS/APSS will not allow APSS to collapse.
Is there a scenario where the APSS is collapsed and still the ref clock
needs to stay enabled ? Sorry, this doesn't make sense to me.
>
> If any consumers needs the clock rate, the driver should take the
> BI_TCXO handle.
This kind of breaks the CCF design. If the ref clock is a gate of the
bi_tcxo HW-wise, then not marking it so in CCF is wrong. Passing the
bi_tcxo to the PHYs separately because of this, makes the assumption that
the PHY drivers should know not to disable the bi_tcxo themselves
either.
>
>
> --
> Thanks,
> Taniya Das
>
On 8/1/25 7:31 AM, Abel Vesa wrote:
> On 25-08-01 10:02:15, Taniya Das wrote:
>>
>>
>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>> provides refclks for PCIE, USB, and UFS.
>>>>
>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>> ---
>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>> drivers/clk/qcom/Makefile | 1 +
>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 266 insertions(+)
>>>>
>>>
>>> [...]
>>>
>>>> +
>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>> + .halt_reg = 0x1c,
>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>> + .clkr = {
>>>> + .enable_reg = 0x1c,
>>>> + .enable_mask = BIT(0),
>>>> + .hw.init = &(const struct clk_init_data) {
>>>> + .name = "tcsr_edp_clkref_en",
>>>> + .ops = &clk_branch2_ops,
>>>
>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>
>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>> which is obviously not the case.
>>>
>>> Bringing this here since there is a disconnect between X Elite and
>>> Glymur w.r.t this now.
>>
>>
>> The ref clocks are not required to be have a parent of bi_tcxo as these
>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>> HLOS/APSS will not allow APSS to collapse.
>
> Is there a scenario where the APSS is collapsed and still the ref clock
> needs to stay enabled ? Sorry, this doesn't make sense to me.
MDSS is capable of displaying things from a buffer when the CPU is off,
AFAICU
We can do CXO_AO instead to have it auto-collapse if it's just Linux
requesting it to stay on, I think.
Konrad
On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
> On 8/1/25 7:31 AM, Abel Vesa wrote:
>> On 25-08-01 10:02:15, Taniya Das wrote:
>>>
>>>
>>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>>> provides refclks for PCIE, USB, and UFS.
>>>>>
>>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>>> ---
>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>>> 3 files changed, 266 insertions(+)
>>>>>
>>>>
>>>> [...]
>>>>
>>>>> +
>>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>>> + .halt_reg = 0x1c,
>>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>>> + .clkr = {
>>>>> + .enable_reg = 0x1c,
>>>>> + .enable_mask = BIT(0),
>>>>> + .hw.init = &(const struct clk_init_data) {
>>>>> + .name = "tcsr_edp_clkref_en",
>>>>> + .ops = &clk_branch2_ops,
>>>>
>>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>>
>>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>>> which is obviously not the case.
>>>>
>>>> Bringing this here since there is a disconnect between X Elite and
>>>> Glymur w.r.t this now.
>>>
>>>
>>> The ref clocks are not required to be have a parent of bi_tcxo as these
>>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>>> HLOS/APSS will not allow APSS to collapse.
>>
>> Is there a scenario where the APSS is collapsed and still the ref clock
>> needs to stay enabled ? Sorry, this doesn't make sense to me.
>
> MDSS is capable of displaying things from a buffer when the CPU is off,
> AFAICU
>
> We can do CXO_AO instead to have it auto-collapse if it's just Linux
> requesting it to stay on, I think.
>
Thanks Konrad for adding the display use case.
Abel, we earlier also had some PCIe, USB use cases where we had to leave
the ref clocks ON and APSS could collapse.
--
Thanks,
Taniya Das
On 25-08-04 14:30:00, Taniya Das wrote:
>
>
> On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
> > On 8/1/25 7:31 AM, Abel Vesa wrote:
> >> On 25-08-01 10:02:15, Taniya Das wrote:
> >>>
> >>>
> >>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
> >>>> On 25-07-29 11:12:37, Taniya Das wrote:
> >>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
> >>>>> provides refclks for PCIE, USB, and UFS.
> >>>>>
> >>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> >>>>> ---
> >>>>> drivers/clk/qcom/Kconfig | 8 ++
> >>>>> drivers/clk/qcom/Makefile | 1 +
> >>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
> >>>>> 3 files changed, 266 insertions(+)
> >>>>>
> >>>>
> >>>> [...]
> >>>>
> >>>>> +
> >>>>> +static struct clk_branch tcsr_edp_clkref_en = {
> >>>>> + .halt_reg = 0x1c,
> >>>>> + .halt_check = BRANCH_HALT_DELAY,
> >>>>> + .clkr = {
> >>>>> + .enable_reg = 0x1c,
> >>>>> + .enable_mask = BIT(0),
> >>>>> + .hw.init = &(const struct clk_init_data) {
> >>>>> + .name = "tcsr_edp_clkref_en",
> >>>>> + .ops = &clk_branch2_ops,
> >>>>
> >>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
> >>>>
> >>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
> >>>> which is obviously not the case.
> >>>>
> >>>> Bringing this here since there is a disconnect between X Elite and
> >>>> Glymur w.r.t this now.
> >>>
> >>>
> >>> The ref clocks are not required to be have a parent of bi_tcxo as these
> >>> ideally can be left enabled(as a subsystem requirement) even if HLOS
> >>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
> >>> HLOS/APSS will not allow APSS to collapse.
> >>
> >> Is there a scenario where the APSS is collapsed and still the ref clock
> >> needs to stay enabled ? Sorry, this doesn't make sense to me.
> >
> > MDSS is capable of displaying things from a buffer when the CPU is off,
> > AFAICU
> >
> > We can do CXO_AO instead to have it auto-collapse if it's just Linux
> > requesting it to stay on, I think.
> >
>
> Thanks Konrad for adding the display use case.
OK, that usecase makes sense then.
> Abel, we earlier also had some PCIe, USB use cases where we had to leave
> the ref clocks ON and APSS could collapse.
Then we need to model that in a different way. Leaving those clocks
without parents should not be the option. Maybe the CXO_AO is the best
option then.
>
>
> --
> Thanks,
> Taniya Das
>
On 8/4/25 11:00 AM, Taniya Das wrote:
>
>
> On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
>> On 8/1/25 7:31 AM, Abel Vesa wrote:
>>> On 25-08-01 10:02:15, Taniya Das wrote:
>>>>
>>>>
>>>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>>>> provides refclks for PCIE, USB, and UFS.
>>>>>>
>>>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>>>> ---
>>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>>>> 3 files changed, 266 insertions(+)
>>>>>>
>>>>>
>>>>> [...]
>>>>>
>>>>>> +
>>>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>>>> + .halt_reg = 0x1c,
>>>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>>>> + .clkr = {
>>>>>> + .enable_reg = 0x1c,
>>>>>> + .enable_mask = BIT(0),
>>>>>> + .hw.init = &(const struct clk_init_data) {
>>>>>> + .name = "tcsr_edp_clkref_en",
>>>>>> + .ops = &clk_branch2_ops,
>>>>>
>>>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>>>
>>>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>>>> which is obviously not the case.
>>>>>
>>>>> Bringing this here since there is a disconnect between X Elite and
>>>>> Glymur w.r.t this now.
>>>>
>>>>
>>>> The ref clocks are not required to be have a parent of bi_tcxo as these
>>>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>>>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>>>> HLOS/APSS will not allow APSS to collapse.
>>>
>>> Is there a scenario where the APSS is collapsed and still the ref clock
>>> needs to stay enabled ? Sorry, this doesn't make sense to me.
>>
>> MDSS is capable of displaying things from a buffer when the CPU is off,
>> AFAICU
>>
>> We can do CXO_AO instead to have it auto-collapse if it's just Linux
>> requesting it to stay on, I think.
>>
>
> Thanks Konrad for adding the display use case.
> Abel, we earlier also had some PCIe, USB use cases where we had to leave
> the ref clocks ON and APSS could collapse.
XO votes will prevent CX collapse, not APSS collapse. CX also powers
USB and PCIe so that only makes sense.
I think it's fair to just stick XO as the parent of every refclock
today and think about the what-ifs (such as the mdss case I mentioned
above) later - especially since we have no infra to take full advantage
of it today (non-APSS RSCs etc.)
Konrad
On 8/4/2025 6:40 PM, Konrad Dybcio wrote:
> On 8/4/25 11:00 AM, Taniya Das wrote:
>>
>>
>> On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
>>> On 8/1/25 7:31 AM, Abel Vesa wrote:
>>>> On 25-08-01 10:02:15, Taniya Das wrote:
>>>>>
>>>>>
>>>>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>>>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>>>>> provides refclks for PCIE, USB, and UFS.
>>>>>>>
>>>>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>>>>> 3 files changed, 266 insertions(+)
>>>>>>>
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> +
>>>>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>>>>> + .halt_reg = 0x1c,
>>>>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>>>>> + .clkr = {
>>>>>>> + .enable_reg = 0x1c,
>>>>>>> + .enable_mask = BIT(0),
>>>>>>> + .hw.init = &(const struct clk_init_data) {
>>>>>>> + .name = "tcsr_edp_clkref_en",
>>>>>>> + .ops = &clk_branch2_ops,
>>>>>>
>>>>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>>>>
>>>>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>>>>> which is obviously not the case.
>>>>>>
>>>>>> Bringing this here since there is a disconnect between X Elite and
>>>>>> Glymur w.r.t this now.
>>>>>
>>>>>
>>>>> The ref clocks are not required to be have a parent of bi_tcxo as these
>>>>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>>>>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>>>>> HLOS/APSS will not allow APSS to collapse.
>>>>
>>>> Is there a scenario where the APSS is collapsed and still the ref clock
>>>> needs to stay enabled ? Sorry, this doesn't make sense to me.
>>>
>>> MDSS is capable of displaying things from a buffer when the CPU is off,
>>> AFAICU
>>>
>>> We can do CXO_AO instead to have it auto-collapse if it's just Linux
>>> requesting it to stay on, I think.
>>>
>>
>> Thanks Konrad for adding the display use case.
>> Abel, we earlier also had some PCIe, USB use cases where we had to leave
>> the ref clocks ON and APSS could collapse.
>
> XO votes will prevent CX collapse, not APSS collapse. CX also powers
> USB and PCIe so that only makes sense.
>
> I think it's fair to just stick XO as the parent of every refclock
> today and think about the what-ifs (such as the mdss case I mentioned
> above) later - especially since we have no infra to take full advantage
> of it today (non-APSS RSCs etc.)
>
When ref clock have been part of GCC, then also they didn't have any xo
as the parent, similar design we kept when it was moved to TCSR as well.
--
Thanks,
Taniya Das
On 8/4/25 4:21 PM, Taniya Das wrote:
>
>
> On 8/4/2025 6:40 PM, Konrad Dybcio wrote:
>> On 8/4/25 11:00 AM, Taniya Das wrote:
>>>
>>>
>>> On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
>>>> On 8/1/25 7:31 AM, Abel Vesa wrote:
>>>>> On 25-08-01 10:02:15, Taniya Das wrote:
>>>>>>
>>>>>>
>>>>>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>>>>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>>>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>>>>>> provides refclks for PCIE, USB, and UFS.
>>>>>>>>
>>>>>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>>>>>> 3 files changed, 266 insertions(+)
>>>>>>>>
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> +
>>>>>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>>>>>> + .halt_reg = 0x1c,
>>>>>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>>>>>> + .clkr = {
>>>>>>>> + .enable_reg = 0x1c,
>>>>>>>> + .enable_mask = BIT(0),
>>>>>>>> + .hw.init = &(const struct clk_init_data) {
>>>>>>>> + .name = "tcsr_edp_clkref_en",
>>>>>>>> + .ops = &clk_branch2_ops,
>>>>>>>
>>>>>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>>>>>
>>>>>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>>>>>> which is obviously not the case.
>>>>>>>
>>>>>>> Bringing this here since there is a disconnect between X Elite and
>>>>>>> Glymur w.r.t this now.
>>>>>>
>>>>>>
>>>>>> The ref clocks are not required to be have a parent of bi_tcxo as these
>>>>>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>>>>>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>>>>>> HLOS/APSS will not allow APSS to collapse.
>>>>>
>>>>> Is there a scenario where the APSS is collapsed and still the ref clock
>>>>> needs to stay enabled ? Sorry, this doesn't make sense to me.
>>>>
>>>> MDSS is capable of displaying things from a buffer when the CPU is off,
>>>> AFAICU
>>>>
>>>> We can do CXO_AO instead to have it auto-collapse if it's just Linux
>>>> requesting it to stay on, I think.
>>>>
>>>
>>> Thanks Konrad for adding the display use case.
>>> Abel, we earlier also had some PCIe, USB use cases where we had to leave
>>> the ref clocks ON and APSS could collapse.
>>
>> XO votes will prevent CX collapse, not APSS collapse. CX also powers
>> USB and PCIe so that only makes sense.
>>
>> I think it's fair to just stick XO as the parent of every refclock
>> today and think about the what-ifs (such as the mdss case I mentioned
>> above) later - especially since we have no infra to take full advantage
>> of it today (non-APSS RSCs etc.)
>>
>
> When ref clock have been part of GCC, then also they didn't have any xo
> as the parent, similar design we kept when it was moved to TCSR as well.
Perhaps we've been running on luck (i.e. XO votes being cast through
another device / clock as a second order effect) all this time.. I'd
happily move towards formal correctness.
Konrad
On 8/6/2025 3:34 PM, Konrad Dybcio wrote:
> On 8/4/25 4:21 PM, Taniya Das wrote:
>>
>>
>> On 8/4/2025 6:40 PM, Konrad Dybcio wrote:
>>> On 8/4/25 11:00 AM, Taniya Das wrote:
>>>>
>>>>
>>>> On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
>>>>> On 8/1/25 7:31 AM, Abel Vesa wrote:
>>>>>> On 25-08-01 10:02:15, Taniya Das wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>>>>>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>>>>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>>>>>>> provides refclks for PCIE, USB, and UFS.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>>>>>>> ---
>>>>>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>>>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>>>>>>> 3 files changed, 266 insertions(+)
>>>>>>>>>
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> +
>>>>>>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>>>>>>> + .halt_reg = 0x1c,
>>>>>>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>>>>>>> + .clkr = {
>>>>>>>>> + .enable_reg = 0x1c,
>>>>>>>>> + .enable_mask = BIT(0),
>>>>>>>>> + .hw.init = &(const struct clk_init_data) {
>>>>>>>>> + .name = "tcsr_edp_clkref_en",
>>>>>>>>> + .ops = &clk_branch2_ops,
>>>>>>>>
>>>>>>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>>>>>>
>>>>>>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>>>>>>> which is obviously not the case.
>>>>>>>>
>>>>>>>> Bringing this here since there is a disconnect between X Elite and
>>>>>>>> Glymur w.r.t this now.
>>>>>>>
>>>>>>>
>>>>>>> The ref clocks are not required to be have a parent of bi_tcxo as these
>>>>>>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>>>>>>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>>>>>>> HLOS/APSS will not allow APSS to collapse.
>>>>>>
>>>>>> Is there a scenario where the APSS is collapsed and still the ref clock
>>>>>> needs to stay enabled ? Sorry, this doesn't make sense to me.
>>>>>
>>>>> MDSS is capable of displaying things from a buffer when the CPU is off,
>>>>> AFAICU
>>>>>
>>>>> We can do CXO_AO instead to have it auto-collapse if it's just Linux
>>>>> requesting it to stay on, I think.
>>>>>
>>>>
>>>> Thanks Konrad for adding the display use case.
>>>> Abel, we earlier also had some PCIe, USB use cases where we had to leave
>>>> the ref clocks ON and APSS could collapse.
>>>
>>> XO votes will prevent CX collapse, not APSS collapse. CX also powers
>>> USB and PCIe so that only makes sense.
>>>
>>> I think it's fair to just stick XO as the parent of every refclock
>>> today and think about the what-ifs (such as the mdss case I mentioned
>>> above) later - especially since we have no infra to take full advantage
>>> of it today (non-APSS RSCs etc.)
>>>
>>
>> When ref clock have been part of GCC, then also they didn't have any xo
>> as the parent, similar design we kept when it was moved to TCSR as well.
>
> Perhaps we've been running on luck (i.e. XO votes being cast through
> another device / clock as a second order effect) all this time.. I'd
> happily move towards formal correctness.
>
I would like to stay with no XO linkage to TCSR. Any driver has specific
XO requirement should vote for the rpmhcc XO or XO_AO.
--
Thanks,
Taniya Das
On 8/6/25 12:21 PM, Taniya Das wrote:
>
>
> On 8/6/2025 3:34 PM, Konrad Dybcio wrote:
>> On 8/4/25 4:21 PM, Taniya Das wrote:
>>>
>>>
>>> On 8/4/2025 6:40 PM, Konrad Dybcio wrote:
>>>> On 8/4/25 11:00 AM, Taniya Das wrote:
>>>>>
>>>>>
>>>>> On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
>>>>>> On 8/1/25 7:31 AM, Abel Vesa wrote:
>>>>>>> On 25-08-01 10:02:15, Taniya Das wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>>>>>>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>>>>>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>>>>>>>> provides refclks for PCIE, USB, and UFS.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>>>>>>>> ---
>>>>>>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>>>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>>>>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>>>>>>>> 3 files changed, 266 insertions(+)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> +
>>>>>>>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>>>>>>>> + .halt_reg = 0x1c,
>>>>>>>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>>>>>>>> + .clkr = {
>>>>>>>>>> + .enable_reg = 0x1c,
>>>>>>>>>> + .enable_mask = BIT(0),
>>>>>>>>>> + .hw.init = &(const struct clk_init_data) {
>>>>>>>>>> + .name = "tcsr_edp_clkref_en",
>>>>>>>>>> + .ops = &clk_branch2_ops,
>>>>>>>>>
>>>>>>>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>>>>>>>
>>>>>>>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>>>>>>>> which is obviously not the case.
>>>>>>>>>
>>>>>>>>> Bringing this here since there is a disconnect between X Elite and
>>>>>>>>> Glymur w.r.t this now.
>>>>>>>>
>>>>>>>>
>>>>>>>> The ref clocks are not required to be have a parent of bi_tcxo as these
>>>>>>>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>>>>>>>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>>>>>>>> HLOS/APSS will not allow APSS to collapse.
>>>>>>>
>>>>>>> Is there a scenario where the APSS is collapsed and still the ref clock
>>>>>>> needs to stay enabled ? Sorry, this doesn't make sense to me.
>>>>>>
>>>>>> MDSS is capable of displaying things from a buffer when the CPU is off,
>>>>>> AFAICU
>>>>>>
>>>>>> We can do CXO_AO instead to have it auto-collapse if it's just Linux
>>>>>> requesting it to stay on, I think.
>>>>>>
>>>>>
>>>>> Thanks Konrad for adding the display use case.
>>>>> Abel, we earlier also had some PCIe, USB use cases where we had to leave
>>>>> the ref clocks ON and APSS could collapse.
>>>>
>>>> XO votes will prevent CX collapse, not APSS collapse. CX also powers
>>>> USB and PCIe so that only makes sense.
>>>>
>>>> I think it's fair to just stick XO as the parent of every refclock
>>>> today and think about the what-ifs (such as the mdss case I mentioned
>>>> above) later - especially since we have no infra to take full advantage
>>>> of it today (non-APSS RSCs etc.)
>>>>
>>>
>>> When ref clock have been part of GCC, then also they didn't have any xo
>>> as the parent, similar design we kept when it was moved to TCSR as well.
>>
>> Perhaps we've been running on luck (i.e. XO votes being cast through
>> another device / clock as a second order effect) all this time.. I'd
>> happily move towards formal correctness.
>>
>
> I would like to stay with no XO linkage to TCSR. Any driver has specific
> XO requirement should vote for the rpmhcc XO or XO_AO.
Every driver has an XO requirement, as we happen not to have any
other crystals onboard.. The clock plan says that these refclks
are direct children of XO too
Konrad
On 8/7/2025 6:37 PM, Konrad Dybcio wrote:
> On 8/6/25 12:21 PM, Taniya Das wrote:
>>
>>
>> On 8/6/2025 3:34 PM, Konrad Dybcio wrote:
>>> On 8/4/25 4:21 PM, Taniya Das wrote:
>>>>
>>>>
>>>> On 8/4/2025 6:40 PM, Konrad Dybcio wrote:
>>>>> On 8/4/25 11:00 AM, Taniya Das wrote:
>>>>>>
>>>>>>
>>>>>> On 8/1/2025 5:24 PM, Konrad Dybcio wrote:
>>>>>>> On 8/1/25 7:31 AM, Abel Vesa wrote:
>>>>>>>> On 25-08-01 10:02:15, Taniya Das wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 7/30/2025 4:55 PM, Abel Vesa wrote:
>>>>>>>>>> On 25-07-29 11:12:37, Taniya Das wrote:
>>>>>>>>>>> Add a clock driver for the TCSR clock controller found on Glymur, which
>>>>>>>>>>> provides refclks for PCIE, USB, and UFS.
>>>>>>>>>>>
>>>>>>>>>>> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
>>>>>>>>>>> ---
>>>>>>>>>>> drivers/clk/qcom/Kconfig | 8 ++
>>>>>>>>>>> drivers/clk/qcom/Makefile | 1 +
>>>>>>>>>>> drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++
>>>>>>>>>>> 3 files changed, 266 insertions(+)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>>> +
>>>>>>>>>>> +static struct clk_branch tcsr_edp_clkref_en = {
>>>>>>>>>>> + .halt_reg = 0x1c,
>>>>>>>>>>> + .halt_check = BRANCH_HALT_DELAY,
>>>>>>>>>>> + .clkr = {
>>>>>>>>>>> + .enable_reg = 0x1c,
>>>>>>>>>>> + .enable_mask = BIT(0),
>>>>>>>>>>> + .hw.init = &(const struct clk_init_data) {
>>>>>>>>>>> + .name = "tcsr_edp_clkref_en",
>>>>>>>>>>> + .ops = &clk_branch2_ops,
>>>>>>>>>>
>>>>>>>>>> As discussed off-list, these clocks need to have the bi_tcxo as parent.
>>>>>>>>>>
>>>>>>>>>> Otherwise, as far as the CCF is concerned these clocks will have rate 0,
>>>>>>>>>> which is obviously not the case.
>>>>>>>>>>
>>>>>>>>>> Bringing this here since there is a disconnect between X Elite and
>>>>>>>>>> Glymur w.r.t this now.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The ref clocks are not required to be have a parent of bi_tcxo as these
>>>>>>>>> ideally can be left enabled(as a subsystem requirement) even if HLOS
>>>>>>>>> (APSS) goes to suspend. With the bi_tcxo parent the ARC vote from
>>>>>>>>> HLOS/APSS will not allow APSS to collapse.
>>>>>>>>
>>>>>>>> Is there a scenario where the APSS is collapsed and still the ref clock
>>>>>>>> needs to stay enabled ? Sorry, this doesn't make sense to me.
>>>>>>>
>>>>>>> MDSS is capable of displaying things from a buffer when the CPU is off,
>>>>>>> AFAICU
>>>>>>>
>>>>>>> We can do CXO_AO instead to have it auto-collapse if it's just Linux
>>>>>>> requesting it to stay on, I think.
>>>>>>>
>>>>>>
>>>>>> Thanks Konrad for adding the display use case.
>>>>>> Abel, we earlier also had some PCIe, USB use cases where we had to leave
>>>>>> the ref clocks ON and APSS could collapse.
>>>>>
>>>>> XO votes will prevent CX collapse, not APSS collapse. CX also powers
>>>>> USB and PCIe so that only makes sense.
>>>>>
>>>>> I think it's fair to just stick XO as the parent of every refclock
>>>>> today and think about the what-ifs (such as the mdss case I mentioned
>>>>> above) later - especially since we have no infra to take full advantage
>>>>> of it today (non-APSS RSCs etc.)
>>>>>
>>>>
>>>> When ref clock have been part of GCC, then also they didn't have any xo
>>>> as the parent, similar design we kept when it was moved to TCSR as well.
>>>
>>> Perhaps we've been running on luck (i.e. XO votes being cast through
>>> another device / clock as a second order effect) all this time.. I'd
>>> happily move towards formal correctness.
>>>
>>
>> I would like to stay with no XO linkage to TCSR. Any driver has specific
>> XO requirement should vote for the rpmhcc XO or XO_AO.
>
> Every driver has an XO requirement, as we happen not to have any
> other crystals onboard.. The clock plan says that these refclks
> are direct children of XO too
>
The refclocks are just not the direct XO, there could be other source as
well. But I am okay to add the XO parent if it helps the use case on X
Elite and then following use cases on Glymur. I will add the XO parent
in the next patchset.
--
Thanks,
Taniya Das
On Tue, Jul 29, 2025 at 11:12:37AM +0530, Taniya Das wrote: > Add a clock driver for the TCSR clock controller found on Glymur, which > provides refclks for PCIE, USB, and UFS. > > Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com> > --- > drivers/clk/qcom/Kconfig | 8 ++ > drivers/clk/qcom/Makefile | 1 + > drivers/clk/qcom/tcsrcc-glymur.c | 257 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 266 insertions(+) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> -- With best wishes Dmitry
© 2016 - 2025 Red Hat, Inc.