On 26-02-04 13:36:57, Konrad Dybcio wrote:

On 2/2/26 9:53 PM, Abel Vesa wrote:

quoted

On 26-01-30 22:40:32, Abel Vesa wrote:

quoted

On 26-01-30 10:43:44, Konrad Dybcio wrote:

quoted

On 1/28/26 3:10 PM, Abel Vesa wrote:

quoted

On 26-01-28 11:34:49, Konrad Dybcio wrote:

quoted

On 1/27/26 4:03 PM, Abel Vesa wrote:

quoted

Add the TCSR clock controller that provides the refclks on Eliza
platform for PCIe, USB and UFS subsystems.

Co-developed-by: Taniya Das <redacted>
Signed-off-by: Taniya Das <redacted>
Signed-off-by: Abel Vesa <redacted>
---

[...]

quoted

+++ b/drivers/clk/qcom/tcsrcc-eliza.c

@@ -0,0 +1,144 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 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,eliza-tcsr.h>
+
+#include "clk-branch.h"
+#include "clk-regmap.h"
+#include "common.h"
+
+enum {
+	DT_BI_TCXO_PAD,
+};
+
+static struct clk_branch tcsr_pcie_0_clkref_en = {
+	.halt_reg = 0x0,

These regs certainly aren't at +0x0 to what we normally expect to
be the start of the TCSR node

They are if we add the TCSR node with reg range starting at 0x1fbf000.

"if we take the wrong base, the wrong offset is right" ;)

The docs for Eliza don't have the nice separation like on e.g. Hamoa,
but 0x01fc0000 is what we generally agreed upon to be "tcsr".

The registers that first appear in that region are the same as on Hamoa,
and so is the address, so let's continue that tradition

Actually, the 0x1fbf000 is the right base address.

Actually, I think it's 0x1fb_2000 ;)

As discussed off-list, using 0x1fb_2000 would include regs that Kaanapali for example
doesn't. So will use the 0x1fc_0000.

quoted

TCSR mutex starts at 0x1f40000, and everything between 0x1fb2000 and 0xfbf000
doesn't really look like they belong in a clock controller.

Correct, and that's because TCSR is not a clock controller.

Correct, but as agreed off-list, for consistency reasons w.r.t. other SoCs,
it should not include that gap.

Thanks,
Abel