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

[Melody Olvera]

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