Re: [PATCH v2 5/7] clk: qcom: Add support for GCC clock controller on SM8750

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 11/18/2024 5:59 PM, Dmitry Baryshkov wrote:
On Mon, Nov 18, 2024 at 11:30:58AM -0800, Melody Olvera wrote:

On 11/15/2024 7:34 AM, Dmitry Baryshkov wrote:
On Mon, Nov 11, 2024 at 04:28:05PM -0800, Melody Olvera wrote:
From: Taniya Das <quic_tdas@xxxxxxxxxxx>

Add support for GCC Clock Controller for SM8750 platform.

Signed-off-by: Taniya Das <quic_tdas@xxxxxxxxxxx>
Signed-off-by: Melody Olvera <quic_molvera@xxxxxxxxxxx>
---
   drivers/clk/qcom/Kconfig      |    9 +
   drivers/clk/qcom/Makefile     |    1 +
   drivers/clk/qcom/gcc-sm8750.c | 3274 +++++++++++++++++++++++++++++++++
   3 files changed, 3284 insertions(+)
   create mode 100644 drivers/clk/qcom/gcc-sm8750.c

diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index ef89d686cbc4..26bfb607235b 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -1130,6 +1130,15 @@ config SM_GCC_8650
   	  Say Y if you want to use peripheral devices such as UART,
   	  SPI, I2C, USB, SD/UFS, PCIe etc.
+config SM_GCC_8750
+	tristate "SM8750 Global Clock Controller"
+	depends on ARM64 || COMPILE_TEST
+	select QCOM_GDSC
+	help
+	  Support for the global clock controller on SM8750 devices.
+	  Say Y if you want to use peripheral devices such as UART,
+	  SPI, I2C, USB, SD/UFS, PCIe etc.
+
   config SM_GPUCC_4450
   	tristate "SM4450 Graphics Clock Controller"
   	depends on ARM64 || COMPILE_TEST
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index b09dbdc210eb..1875018d1100 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -143,6 +143,7 @@ obj-$(CONFIG_SM_GCC_8350) += gcc-sm8350.o
   obj-$(CONFIG_SM_GCC_8450) += gcc-sm8450.o
   obj-$(CONFIG_SM_GCC_8550) += gcc-sm8550.o
   obj-$(CONFIG_SM_GCC_8650) += gcc-sm8650.o
+obj-$(CONFIG_SM_GCC_8750) += gcc-sm8750.o
   obj-$(CONFIG_SM_GPUCC_4450) += gpucc-sm4450.o
   obj-$(CONFIG_SM_GPUCC_6115) += gpucc-sm6115.o
   obj-$(CONFIG_SM_GPUCC_6125) += gpucc-sm6125.o
diff --git a/drivers/clk/qcom/gcc-sm8750.c b/drivers/clk/qcom/gcc-sm8750.c
new file mode 100644
index 000000000000..faaefa42a039
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sm8750.c
@@ -0,0 +1,3274 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Copyright (c) 2024, Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+#include <dt-bindings/clock/qcom,sm8750-gcc.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 "clk-regmap-phy-mux.h"
+#include "common.h"
+#include "gdsc.h"
+#include "reset.h"
+
+enum {
+	DT_BI_TCXO,
+	DT_BI_TCXO_AO,
+	DT_PCIE_0_PIPE_CLK,
+	DT_SLEEP_CLK,
+	DT_UFS_PHY_RX_SYMBOL_0_CLK,
+	DT_UFS_PHY_RX_SYMBOL_1_CLK,
+	DT_UFS_PHY_TX_SYMBOL_0_CLK,
+	DT_USB3_PHY_WRAPPER_GCC_USB30_PIPE_CLK,
This doesn't match Documentation/devicetree/bindings/clock/qcom,sm8650-gcc.yaml
Hmmm I see what seems to have happened here. You're correct; this doesn't
match the bindings
in sm8650-gcc. The v1 patchset had a new bindings file which matched the
sm8650 bindings, but also
didn't match the driver; however we only seemed to catch that the two
bindings matched and not the
fact that they didn't match the drivers.
I don't see v1. Please bring bindings back.

Will do.


In terms of remedy I see two options. I'm fairly certain the driver here is
correct, so we can either
add the sm8750 bindings file back and remove the two lines about the PCIE 1
clocks or adjust the
sm8650 binding to encompass both sm8650 and sm8750. It's unclear to me how
precedented the latter
is; certainly having a single bindings file encompass both chips is
feasible, but I think I'm currently
leaning towards bringing back the original bindings file as that seems more
precedented. Lmk
your thoughts.
How are you thinking to change SM8650 bindings without breaking the ABI
/ backwards compatibility?


Giant if-then (read: poorly).

Thanks,
Melody




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux