[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2bf7790-7387-4eb6-8e1e-e555a20a717b@quicinc.com>
Date: Mon, 18 Nov 2024 11:30:58 -0800
From: Melody Olvera <quic_molvera@...cinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
CC: Bjorn Andersson <andersson@...nel.org>,
Michael Turquette
<mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, Rob Herring
<robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley
<conor+dt@...nel.org>,
Taniya Das <quic_tdas@...cinc.com>,
Trilok Soni
<quic_tsoni@...cinc.com>,
Satya Durga Srinivasu Prabhala
<quic_satyap@...cinc.com>,
<linux-arm-msm@...r.kernel.org>, <linux-clk@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 5/7] clk: qcom: Add support for GCC clock controller on
SM8750
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@...cinc.com>
>>
>> Add support for GCC Clock Controller for SM8750 platform.
>>
>> Signed-off-by: Taniya Das <quic_tdas@...cinc.com>
>> Signed-off-by: Melody Olvera <quic_molvera@...cinc.com>
>> ---
>> 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.
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.
Thanks,
Melody
>> +};
>> +
Powered by blists - more mailing lists