* [PATCH 2/4] clk: en7523: add support for dedicated PCIe PERSTOUT reset
From: Christian Marangi @ 2026-06-25 21:57 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Ryder Lee, Michael Turquette,
Stephen Boyd, Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260625215741.3253212-1-ansuelsmth@gmail.com>
Add support for resetting the PCIe lines with the PERSTOUT reset. These
special reset are controlled by the PCIC register and are specific to each
of the 3 PCIe lines.
Notice that reset logic is inverted for these bit where 0 is assert and 1
deassert. This is intenrally handled in the reset function.
PCI enable/disable are updated to drop PERSTOUT bits in favor dedicated
reset handling.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
drivers/clk/clk-en7523.c | 27 ++++++++++++++++++---------
1 file changed, 18 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/clk-en7523.c b/drivers/clk/clk-en7523.c
index 1ab0e2eca5d3..a33cf2e1b76f 100644
--- a/drivers/clk/clk-en7523.c
+++ b/drivers/clk/clk-en7523.c
@@ -338,6 +338,7 @@ static const struct en_clk_desc en7581_base_clks[] = {
static const u16 en7581_rst_ofs[] = {
REG_RST_CTRL2,
REG_RST_CTRL1,
+ REG_NP_SCU_PCIC,
};
static const u16 en751221_rst_ofs[] = {
@@ -450,6 +451,11 @@ static const u16 en7581_rst_map[] = {
[EN7581_CPU_TIMER_RST] = RST_NR_PER_BANK + 28,
[EN7581_PCIE_HB_RST] = RST_NR_PER_BANK + 29,
[EN7581_XPON_MAC_RST] = RST_NR_PER_BANK + 31,
+
+ /* RST_PCIC */
+ [EN7581_PCIC_PERSTOUT0_RST] = 2 * RST_NR_PER_BANK + 29,
+ [EN7581_PCIC_PERSTOUT1_RST] = 2 * RST_NR_PER_BANK + 26,
+ [EN7581_PCIC_PERSTOUT2_RST] = 2 * RST_NR_PER_BANK + 16,
};
static const u16 en751221_rst_map[] = {
@@ -635,9 +641,7 @@ static int en7581_pci_enable(struct clk_hw *hw)
void __iomem *np_base = cg->base;
u32 val, mask;
- mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
- REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
- REG_PCI_CONTROL_PERSTOUT;
+ mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
val = readl(np_base + REG_PCI_CONTROL);
writel(val | mask, np_base + REG_PCI_CONTROL);
@@ -650,9 +654,7 @@ static void en7581_pci_disable(struct clk_hw *hw)
void __iomem *np_base = cg->base;
u32 val, mask;
- mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1 |
- REG_PCI_CONTROL_PERSTOUT1 | REG_PCI_CONTROL_PERSTOUT2 |
- REG_PCI_CONTROL_PERSTOUT;
+ mask = REG_PCI_CONTROL_REFCLK_EN0 | REG_PCI_CONTROL_REFCLK_EN1;
val = readl(np_base + REG_PCI_CONTROL);
writel(val & ~mask, np_base + REG_PCI_CONTROL);
usleep_range(1000, 2000);
@@ -754,14 +756,21 @@ static int en7523_reset_update(struct reset_controller_dev *rcdev,
unsigned long id, bool assert)
{
struct en_rst_data *rst_data = container_of(rcdev, struct en_rst_data, rcdev);
- void __iomem *addr = rst_data->base + rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ u32 offset = rst_data->bank_ofs[id / RST_NR_PER_BANK];
+ void __iomem *addr = rst_data->base + offset;
+ bool inverted = false;
u32 val;
+ /* For PCIC reset logic is inverted, 0:assert 1:deassert*/
+ if (offset == REG_NP_SCU_PCIC)
+ inverted = true;
+
val = readl(addr);
+ val &= ~BIT(id % RST_NR_PER_BANK);
if (assert)
- val |= BIT(id % RST_NR_PER_BANK);
+ val |= inverted ? 0 : BIT(id % RST_NR_PER_BANK);
else
- val &= ~BIT(id % RST_NR_PER_BANK);
+ val |= inverted ? BIT(id % RST_NR_PER_BANK) : 0;
writel(val, addr);
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: clock: airoha: Add additional reset for PCIe PERSTOUT
From: Christian Marangi @ 2026-06-25 21:57 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Ryder Lee, Michael Turquette,
Stephen Boyd, Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
In-Reply-To: <20260625215741.3253212-1-ansuelsmth@gmail.com>
Add additional reset to control PCIe PERSTOUT reset line for each of the 3
PCIe lines.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
include/dt-bindings/reset/airoha,en7581-reset.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/dt-bindings/reset/airoha,en7581-reset.h b/include/dt-bindings/reset/airoha,en7581-reset.h
index 6544a1790b83..25e75534daa9 100644
--- a/include/dt-bindings/reset/airoha,en7581-reset.h
+++ b/include/dt-bindings/reset/airoha,en7581-reset.h
@@ -62,5 +62,9 @@
#define EN7581_CPU_TIMER_RST 50
#define EN7581_PCIE_HB_RST 51
#define EN7581_XPON_MAC_RST 52
+/* RST_PCIC */
+#define EN7581_PCIC_PERSTOUT0_RST 53
+#define EN7581_PCIC_PERSTOUT1_RST 54
+#define EN7581_PCIC_PERSTOUT2_RST 55
#endif /* __DT_BINDINGS_RESET_CONTROLLER_AIROHA_EN7581_H_ */
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] PCI: mediatek-gen3: Add 2-lanes mode support + clock
From: Christian Marangi @ 2026-06-25 21:57 UTC (permalink / raw)
To: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas,
Krzysztof Kozlowski, Conor Dooley, Ryder Lee, Michael Turquette,
Stephen Boyd, Brian Masney, Philipp Zabel, Matthias Brugger,
AngeloGioacchino Del Regno, Christian Marangi, Jianjun Wang,
linux-pci, devicetree, linux-kernel, linux-mediatek, linux-clk,
linux-arm-kernel
This small series introduce support for 2-lanes mode for Airoha AN7581
SoC. This is needed for correctly functionality of Eagle WiFi Card
normally attached to this SoC that require a 2-line PCIe card to
correctly work (and give the proper performance)
The first 2 patch address a limitation of the PCIe implementation
where the PERSTOUT reset were indirectly asserted and deasserted
all at the same time (for all the 3 PCIe card) with PCIe
enable and disable.
The 2 patch address this and introduce correct reset to control
reset line for the relevant PCIe line.
The last 2 patch add additional logic and support to assert
and deassert the PERSTOUT and also apply the required configuration
for 2-lanes mode.
2-lanes mode is implemented in DT by adding the required property
and by defining the "num-lanes" to 2.
Christian Marangi (4):
dt-bindings: clock: airoha: Add additional reset for PCIe PERSTOUT
clk: en7523: add support for dedicated PCIe PERSTOUT reset
dt-bindings: PCI: mediatek-gen3: Split Airoha schema and document
2-lanes
PCI: mediatek-gen3: Add 2-lanes mode support for Airoha AN7581
.../bindings/pci/airoha,en7581-pcie.yaml | 251 ++++++++++++++++++
.../bindings/pci/mediatek-pcie-gen3.yaml | 77 +-----
drivers/clk/clk-en7523.c | 27 +-
drivers/pci/controller/pcie-mediatek-gen3.c | 98 +++++--
.../dt-bindings/reset/airoha,en7581-reset.h | 4 +
5 files changed, 358 insertions(+), 99 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/airoha,en7581-pcie.yaml
--
2.53.0
^ permalink raw reply
* Re: [GIT PULL] clk changes for the merge window
From: pr-tracker-bot @ 2026-06-25 19:57 UTC (permalink / raw)
To: Stephen Boyd
Cc: Linus Torvalds, Michael Turquette, Brian Masney, linux-clk,
linux-kernel
In-Reply-To: <20260625151438.8471-1-sboyd@kernel.org>
The pull request you sent on Thu, 25 Jun 2026 08:14:37 -0700:
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8c04c1292dca29a57ea82c6a44348be49749fc22
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: patchwork-bot+netdevbpf @ 2026-06-25 16:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: andersson, mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt,
jie.luo, andrew+netdev, davem, edumazet, kuba, pabeni,
quic_leiwei, quic_suruchia, quic_pavir, linux-kernel,
linux-arm-msm, linux-clk, devicetree, netdev
In-Reply-To: <20260623073307.36483-2-krzysztof.kozlowski@oss.qualcomm.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 23 Jun 2026 09:33:08 +0200 you wrote:
> Emails to the maintainer of Qualcomm PPE Ethernet driver (Luo Jie
> <quic_luoj@quicinc.com>) bounce permanently (full mailbox), because the
> "quicinc.com" addresses were deprecated for public work. All Qualcomm
> contributors are aware of that and were asked to fix their addresses.
>
> Driver is not supported - in terms of how netdev understands supported
> commitment - if maintainer does not care to receive the patches for its
> code, so demote it to "maintained" to reflect true status.
>
> [...]
Here is the summary with links:
- [net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
https://git.kernel.org/netdev/net/c/efd7fb21bad8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [GIT PULL] clk changes for the merge window
From: Brian Masney @ 2026-06-25 15:46 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Linus Torvalds, Michael Turquette, linux-clk, linux-kernel
In-Reply-To: <20260625151438.8471-1-sboyd@kernel.org>
Hey Stephen,
On Thu, Jun 25, 2026 at 08:14:37AM -0700, Stephen Boyd wrote:
> The following changes since commit 2abdc3dcf9780d070e55a99fdf8f93440c798b84:
>
> dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile APE6 (2026-05-15 11:26:26 +0200)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-for-linus
>
> for you to fetch changes up to 92010229c4b38897f1319d260162d2f96925ed17:
>
> Merge branches 'clk-microchip' and 'clk-qcom' into clk-next (2026-06-25 07:55:47 -0700)
>
> ----------------------------------------------------------------
> This is all clk driver updates. Mostly new SoC support for
> various Qualcomm chips and Canaan K230. Otherwise there's
> non-critical fixes and updates to clk data such as adding missing
> clks to existing drivers or marking clks critical. Nothing looks
> especially exciting.
>
> ----------------------------------------------------------------
Would it be possible to also include Benoît's support for the Mobileye EyeQ7H
SoC? He has a pull ready:
https://lore.kernel.org/linux-clk/h_BA0KRKTGSANQ5Y4eqo6A@bootlin.com/
This also wasn't picked up during the last merge window. We push vendors to
upstream their code, and they point to situations like this when they tell
us it's too hard to upstream their code.
It looks like this was mostly pulls from the subsystems under clk. There's
also a bunch of patch sets that I reviewed this development cycle that I feel
should have been picked up. I'll send you a pull for that.
Brian
^ permalink raw reply
* [GIT PULL] clk changes for the merge window
From: Stephen Boyd @ 2026-06-25 15:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael Turquette, Brian Masney, linux-clk, linux-kernel
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 21831 bytes --]
The following changes since commit 2abdc3dcf9780d070e55a99fdf8f93440c798b84:
dt-bindings: clock: renesas,cpg-clocks: Document ZT/ZTR trace clock on R-Mobile APE6 (2026-05-15 11:26:26 +0200)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-for-linus
for you to fetch changes up to 92010229c4b38897f1319d260162d2f96925ed17:
Merge branches 'clk-microchip' and 'clk-qcom' into clk-next (2026-06-25 07:55:47 -0700)
----------------------------------------------------------------
This is all clk driver updates. Mostly new SoC support for
various Qualcomm chips and Canaan K230. Otherwise there's
non-critical fixes and updates to clk data such as adding missing
clks to existing drivers or marking clks critical. Nothing looks
especially exciting.
----------------------------------------------------------------
Adrian Ng Ho Yin (1):
clk: socfpga: agilex: implement l3_main_free_clk
Alexander Koskovich (1):
clk: qcom: clk-rpmh: Make all VRMs optional
Alexander Stein (1):
clk: bulk: Use dev_err_probe() helper in of_clk_bulk_get()
Alexey Klimov (1):
clk: samsung: exynos850: mark APM I3C clocks as critical
Bartosz Golaszewski (2):
dt-bindings: clock: qcom: add the definition for the USB2 PHY reset
clk: qcom: nord: negcc: add support for the USB2 PHY reset
Biju Das (17):
clk: renesas: rzg2l: Drop always-false check in rzg3s_cpg_pll_clk_recalc_rate()
clk: renesas: rzg2l: Add support for enabling PLLs
clk: renesas: r8a08g046: Add support for PLL6
clk: renesas: r9a08g046: Add GBETH clocks and resets
clk: renesas: r9a08g046: Add GPIO clocks/resets
clk: renesas: r9a08g046: Add CA55 core clocks
clk: renesas: r9a08g046: Add WDT clocks and reset
clk: renesas: r9a08g046: Add SCIF{1..5} clocks and resets
clk: renesas: r9a08g046: Add I2C clocks and resets
clk: renesas: r9a08g046: Add IA55_PCLK to critical module clocks
clk: renesas: r9a08g046: Add RSCI clocks and resets
clk: renesas: r9a08g046: Add SSIF-2 clocks and resets
clk: renesas: r9a08g046: Add RSPI clocks and resets
clk: renesas: rzg2l: Simplify SAM PLL configuration macro
clk: renesas: rzg3s/rzg3l: Simplify PLL configuration macro
clk: renesas: rzg2l: Rename RZG3L-prefixed PLL macros to CPG-prefixed ones
clk: renesas: r9a08g045: Drop unused pm_domain header file
Biswapriyo Nath (1):
dt-bindings: clock: qcom,sm6125-dispcc: reference qcom,gcc.yaml
Bjorn Andersson (2):
Merge branch '20260507-ipq9650_boot_to_shell-v3-1-62742b49c991@oss.qualcomm.com' into clk-for-7.2
Merge branch '20260106-qcom_ipq5332_cmnpll-v2-2-f9f7e4efbd79@oss.qualcomm.com' into clk-for-7.2
Conor Dooley (2):
clk: microchip: rename clk-core to clk-pic32
clk: microchip: mpfs-ccc: fix peripheral driver registration failures after oob fix
Cosmin Tanislav (1):
clk: renesas: r9a09g077: Add MTU3 module clock
Daniel Golle (3):
clk: mediatek: add MUX_CLR_SET macro
clk: mediatek: mt8192: use MUX_CLR_SET
clk: mediatek: mt7988: use MUX_CLR_SET for gate-less muxes
Daniele Briguglio (5):
dt-bindings: clock: rockchip,rk3588-cru: add I2S MCLK output to IO clock IDs
clk: rockchip: allow grf_type_sys lookup in aux_grf_table
clk: rockchip: add helper to register auxiliary GRFs
soc: rockchip: rk3588: add SYS_GRF SOC_CON6 register offset
clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
Denzeel Oliva (1):
clk: samsung: exynos990: Fix PERIC0/1 USI clock types
Duje Mihanović (3):
dt-bindings: clock: marvell,pxa1908: Add #reset-cells
clk: mmp: pxa1908-apbc: Add reset cells
clk: mmp: pxa1908-apbcp: Add reset cells
Durai Manickam KR (1):
clk: at91: sama7d65: add peripheral clock for I3C
Geert Uytterhoeven (6):
Merge tag 'renesas-r8a7740-dt-binding-defs-tag1' into renesas-clk-for-v7.2
Merge tag 'clk-renesas-rzg3e-plldsi-tag' into renesas-clk-for-v7.2
clk: renesas: rzg2l: Consolidate DEF_MUX() and DEF_MUX_FLAGS()
clk: renesas: rzg2l: Refactor rzg3l_cpg_pll_clk_endisable()
clk: renesas: cpg-mssr: Add number of clock cells check
Merge tag 'renesas-r8a73a4-dt-binding-defs-tag1' into renesas-clk-for-v7.2
Heiko Stuebner (1):
Merge branch 'v7.2-shared/socids' into v7.2-clk/next
J. Neuschäfer (1):
clk: hisilicon: Improve deallocation in error path
Jagadeesh Kona (5):
dt-bindings: clock: qcom: Add X1P42100 video clock controller
dt-bindings: clock: qcom: Add X1P42100 camera clock controller
clk: qcom: videocc-x1p42100: Add support for video clock controller
clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks
clk: qcom: camcc-x1p42100: Add support for camera clock controller
Jian Hu (2):
dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
dt-bindings: clock: amlogic: t7: Add missing mpll3 parent clock
Jing Yangyang (1):
clk: keystone: sci-clk: fix application of sizeof to pointer
Kathiravan Thirumoorthy (1):
clk: qcom: add Global Clock controller (GCC) driver for IPQ9650 SoC
Konrad Dybcio (1):
clk: qcom: regmap-phy-mux: Rework the implementation
Krzysztof Kozlowski (3):
clk: qcom: dispcc-x1e80100: Fix (possibly) dumping regmap
clk: qcom: Constify qcom_cc_driver_data and list of critical CBCR registers
dt-bindings: clock: qcom,kaanapali-gxclkctl: Correctly use additionalProperties
Lad Prabhakar (2):
clk: renesas: r9a08g045: Drop unused DEF_G3S_MUX macro
clk: renesas: rzg2l: Rename iterator in for_each_mod_clock() to avoid shadowing
Luca Weiss (6):
dt-bindings: clock: qcom: document the Milos GX clock controller
clk: qcom: Add support for GXCLK for Milos
interconnect: Add devm_of_icc_get_by_index() as exported API for users
dt-bindings: clock: qcom,milos-camcc: Document interconnect path
clk: qcom: gdsc: Support enabling interconnect path for power domain
clk: qcom: camcc-milos: Declare icc path dependency for CAMSS_TOP_GDSC
Luo Jie (3):
dt-bindings: clock: qcom: Add CMN PLL support for IPQ5332 SoC
clk: qcom: cmnpll: Account for reference clock divider
clk: qcom: cmnpll: Add IPQ5332 SoC support
Marek Vasut (3):
clk: renesas: r8a7740: Add ZT/ZTR trace clocks
clk: renesas: r8a73a4: Add ZT/ZTR trace clocks
clk: renesas: r8a779g0: Add DSC clock
Michael Walle (1):
clk: keystone: don't cache clock rate
Mihai Sain (3):
clk: at91: sam9x7: Remove gmac peripheral clock with ID 67
clk: at91: sam9x7: Rename macb0_clk to gmac_clk
clk: at91: sam9x7: Fix gmac_gclk clock definition
Nuno Sá (1):
clk: clk-axi-clkgen: Add support versal timings
Phillip Varney (1):
clk: qcom: a53: Corrected frequency multiplier for 1152MHz
Rosen Penev (7):
clk: mvebu: use kzalloc_flex
clk: hisilicon: clkdivider-hi6220: use kzalloc_flex
clk: visconti: pll: use kzalloc_flex
clk: clk-max77686: kzalloc + kcalloc to kzalloc
clk: bcm: iproc-asiu: simplify allocation
clk-lpc18xx-ccu: kzalloc + kcalloc to kzalloc_flex
clk: rockchip: allow COMPILE_TEST builds
Stephen Boyd (16):
Merge tag 'renesas-clk-for-v7.2-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-renesas
Merge tag 'socfpga_clk_update_for_v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into clk-socfpga
Merge tag 'clk-meson-v7.2-1' of ssh://github.com/BayLibre/clk-meson into clk-amlogic
Merge tag 'renesas-clk-for-v7.2-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into clk-renesas
Merge tag 'clk-canaan-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into clk-canaan
Merge tag 'ti-k3-sci-clk-for-v7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into clk-ti
Merge tag 'samsung-clk-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into clk-samsung
Merge tag 'v7.2-rockchip-clk1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into clk-rockchip
Merge tag 'spacemit-clk-for-7.2-1' of ssh://github.com/spacemit-com/linux into clk-spacemit
Merge tag 'clk-microchip-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-microchip
Merge tag 'clk-microchip-fixes-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-microchip
Merge tag 'qcom-clk-for-7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into clk-qcom
Merge branches 'clk-cleanup', 'clk-mediatek', 'clk-marvell' and 'clk-versal' into clk-next
Merge branches 'clk-renesas', 'clk-socfpga', 'clk-amlogic' and 'clk-canaan' into clk-next
Merge branches 'clk-ti', 'clk-samsung', 'clk-rockchip' and 'clk-spacemit' into clk-next
Merge branches 'clk-microchip' and 'clk-qcom' into clk-next
Tommaso Merciai (8):
clk: renesas: rzv2h: Add PLLDSI clk mux support
clk: renesas: r9a09g047: Add CLK_PLLETH_LPCLK support
clk: renesas: r9a09g047: Add CLK_PLLDSI{0,1} clocks
clk: renesas: r9a09g047: Add CLK_PLLDSI{0,1}_DIV7 clocks
clk: renesas: r9a09g047: Add CLK_PLLDSI{0,1}_CSDIV clocks
clk: renesas: r9a09g047: Add support for SMUX2_DSI{0,1}_CLK
clk: renesas: r9a09g047: Add support for DSI clocks and resets
clk: renesas: r9a09g047: Add support for LCDC{0,1} clocks and resets
Vivek Aknurwar (7):
dt-bindings: clock: qcom-rpmhcc: Add RPMHCC bindings for Hawi
dt-bindings: clock: qcom: Add Hawi TCSR clock controller
dt-bindings: clock: qcom: Add Hawi global clock controller
clk: qcom: rpmh: Add support for Hawi RPMH clocks
clk: qcom: Add Hawi TCSR clock controller driver
clk: qcom: clk-alpha-pll: Add support for Taycan EHA_T PLL
clk: qcom: Add support for global clock controller on Hawi
Xukai Wang (2):
dt-bindings: clock: Add Canaan K230 clock controller
clk: canaan: Add clock driver for Canaan K230
Yixun Lan (4):
clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock
clk: spacemit: k3: Fix PCIe clock register offset
dt-bindings: soc: spacemit: k3: Add PCIe DBI clock IDs
clk: spacemit: k3: Add PCIe DBI clock
Yuho Choi (1):
clk: at91: keep securam node alive while mapping it
.../clock/amlogic,t7-peripherals-clkc.yaml | 12 +-
.../bindings/clock/amlogic,t7-pll-clkc.yaml | 2 +-
.../bindings/clock/canaan,k230-clk.yaml | 59 +
.../bindings/clock/marvell,pxa1908.yaml | 34 +-
.../bindings/clock/qcom,dispcc-sm6125.yaml | 17 +-
.../bindings/clock/qcom,hawi-gcc.yaml | 63 +
.../bindings/clock/qcom,ipq9574-cmn-pll.yaml | 1 +
.../clock/qcom,kaanapali-gxclkctl.yaml | 2 +-
.../bindings/clock/qcom,milos-camcc.yaml | 8 +
...xclkctl.yaml => qcom,milos-gxclkctl.yaml} | 22 +-
.../bindings/clock/qcom,rpmhcc.yaml | 1 +
.../bindings/clock/qcom,sm8450-videocc.yaml | 3 +
.../bindings/clock/qcom,sm8550-tcsr.yaml | 2 +
.../bindings/clock/qcom,x1e80100-camcc.yaml | 1 +
drivers/clk/Kconfig | 6 +
drivers/clk/Makefile | 3 +-
drivers/clk/at91/pmc.c | 2 +-
drivers/clk/at91/sam9x7.c | 21 +-
drivers/clk/at91/sama7d65.c | 1 +
drivers/clk/bcm/clk-iproc-asiu.c | 27 +-
drivers/clk/clk-axi-clkgen.c | 5 +-
drivers/clk/clk-bulk.c | 14 +-
drivers/clk/clk-k230.c | 2452 +++++++++++
drivers/clk/clk-max77686.c | 32 +-
drivers/clk/hisilicon/clk.c | 4 +-
drivers/clk/hisilicon/clkdivider-hi6220.c | 26 +-
drivers/clk/keystone/sci-clk.c | 10 +-
drivers/clk/mediatek/clk-mt7988-infracfg.c | 80 +-
drivers/clk/mediatek/clk-mt8192.c | 4 +-
drivers/clk/mediatek/clk-mux.h | 5 +
drivers/clk/microchip/Makefile | 2 +-
drivers/clk/microchip/clk-mpfs-ccc.c | 15 +-
.../microchip/{clk-core.c => clk-pic32.c} | 2 +-
.../microchip/{clk-core.h => clk-pic32.h} | 0
drivers/clk/microchip/clk-pic32mzda.c | 2 +-
drivers/clk/mmp/clk-pxa1908-apbc.c | 58 +-
drivers/clk/mmp/clk-pxa1908-apbcp.c | 31 +-
drivers/clk/mvebu/common.c | 21 +-
drivers/clk/nxp/clk-lpc18xx-ccu.c | 14 +-
drivers/clk/qcom/Kconfig | 48 +
drivers/clk/qcom/Makefile | 7 +-
drivers/clk/qcom/a53-pll.c | 2 +-
drivers/clk/qcom/camcc-milos.c | 7 +
drivers/clk/qcom/camcc-x1e80100.c | 64 +
.../{camcc-x1e80100.c => camcc-x1p42100.c} | 566 +--
drivers/clk/qcom/clk-alpha-pll.h | 6 +
drivers/clk/qcom/clk-regmap-phy-mux.c | 52 +-
drivers/clk/qcom/clk-rpmh.c | 41 +-
drivers/clk/qcom/dispcc-x1e80100.c | 2 +-
drivers/clk/qcom/gcc-hawi.c | 3657 ++++++++++++++++
drivers/clk/qcom/gcc-ipq9650.c | 3445 +++++++++++++++
drivers/clk/qcom/gcc-nord.c | 2 +-
drivers/clk/qcom/gdsc.c | 33 +
drivers/clk/qcom/gdsc.h | 5 +
drivers/clk/qcom/gpucc-sm8750.c | 4 +-
drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
drivers/clk/qcom/ipq-cmn-pll.c | 30 +-
drivers/clk/qcom/negcc-nord.c | 3 +-
drivers/clk/qcom/nwgcc-nord.c | 4 +-
drivers/clk/qcom/segcc-nord.c | 2 +-
drivers/clk/qcom/tcsrcc-hawi.c | 158 +
drivers/clk/qcom/videocc-x1p42100.c | 585 +++
drivers/clk/renesas/clk-r8a73a4.c | 2 +
drivers/clk/renesas/clk-r8a7740.c | 2 +
drivers/clk/renesas/r8a779g0-cpg-mssr.c | 1 +
drivers/clk/renesas/r9a07g043-cpg.c | 2 +-
drivers/clk/renesas/r9a07g044-cpg.c | 2 +-
drivers/clk/renesas/r9a08g045-cpg.c | 13 +-
drivers/clk/renesas/r9a08g046-cpg.c | 355 ++
drivers/clk/renesas/r9a09g011-cpg.c | 7 +-
drivers/clk/renesas/r9a09g047-cpg.c | 84 +
drivers/clk/renesas/r9a09g077-cpg.c | 1 +
drivers/clk/renesas/renesas-cpg-mssr.c | 3 +
drivers/clk/renesas/rzg2l-cpg.c | 88 +-
drivers/clk/renesas/rzg2l-cpg.h | 18 +-
drivers/clk/renesas/rzv2h-cpg.c | 181 +
drivers/clk/renesas/rzv2h-cpg.h | 12 +
drivers/clk/rockchip/Kconfig | 2 +-
.../clock/amlogic,t7-peripherals-clkc.yaml | 12 +-
.../bindings/clock/amlogic,t7-pll-clkc.yaml | 2 +-
.../bindings/clock/canaan,k230-clk.yaml | 59 +
.../bindings/clock/marvell,pxa1908.yaml | 34 +-
.../bindings/clock/qcom,dispcc-sm6125.yaml | 17 +-
.../bindings/clock/qcom,hawi-gcc.yaml | 63 +
.../bindings/clock/qcom,ipq9574-cmn-pll.yaml | 1 +
.../clock/qcom,kaanapali-gxclkctl.yaml | 2 +-
.../bindings/clock/qcom,milos-camcc.yaml | 8 +
...xclkctl.yaml => qcom,milos-gxclkctl.yaml} | 22 +-
.../bindings/clock/qcom,rpmhcc.yaml | 1 +
.../bindings/clock/qcom,sm8450-videocc.yaml | 3 +
.../bindings/clock/qcom,sm8550-tcsr.yaml | 2 +
.../bindings/clock/qcom,x1e80100-camcc.yaml | 1 +
drivers/clk/Kconfig | 6 +
drivers/clk/Makefile | 3 +-
drivers/clk/at91/pmc.c | 2 +-
drivers/clk/at91/sam9x7.c | 21 +-
drivers/clk/at91/sama7d65.c | 1 +
drivers/clk/bcm/clk-iproc-asiu.c | 27 +-
drivers/clk/clk-axi-clkgen.c | 5 +-
drivers/clk/clk-bulk.c | 14 +-
drivers/clk/clk-k230.c | 2452 +++++++++++
drivers/clk/clk-max77686.c | 32 +-
drivers/clk/hisilicon/clk.c | 4 +-
drivers/clk/hisilicon/clkdivider-hi6220.c | 26 +-
drivers/clk/keystone/sci-clk.c | 10 +-
drivers/clk/mediatek/clk-mt7988-infracfg.c | 80 +-
drivers/clk/mediatek/clk-mt8192.c | 4 +-
drivers/clk/mediatek/clk-mux.h | 5 +
drivers/clk/microchip/Makefile | 2 +-
drivers/clk/microchip/clk-mpfs-ccc.c | 15 +-
.../microchip/{clk-core.c => clk-pic32.c} | 2 +-
.../microchip/{clk-core.h => clk-pic32.h} | 0
drivers/clk/microchip/clk-pic32mzda.c | 2 +-
drivers/clk/mmp/clk-pxa1908-apbc.c | 58 +-
drivers/clk/mmp/clk-pxa1908-apbcp.c | 31 +-
drivers/clk/mvebu/common.c | 21 +-
drivers/clk/nxp/clk-lpc18xx-ccu.c | 14 +-
drivers/clk/qcom/Kconfig | 48 +
drivers/clk/qcom/Makefile | 7 +-
drivers/clk/qcom/a53-pll.c | 2 +-
drivers/clk/qcom/camcc-milos.c | 7 +
drivers/clk/qcom/camcc-x1e80100.c | 64 +
.../{camcc-x1e80100.c => camcc-x1p42100.c} | 566 +--
drivers/clk/qcom/clk-alpha-pll.h | 6 +
drivers/clk/qcom/clk-regmap-phy-mux.c | 52 +-
drivers/clk/qcom/clk-rpmh.c | 41 +-
drivers/clk/qcom/dispcc-x1e80100.c | 2 +-
drivers/clk/qcom/gcc-hawi.c | 3657 ++++++++++++++++
drivers/clk/qcom/gcc-ipq9650.c | 3445 +++++++++++++++
drivers/clk/qcom/gcc-nord.c | 2 +-
drivers/clk/qcom/gdsc.c | 33 +
drivers/clk/qcom/gdsc.h | 5 +
drivers/clk/qcom/gpucc-sm8750.c | 4 +-
drivers/clk/qcom/gxclkctl-kaanapali.c | 1 +
drivers/clk/qcom/ipq-cmn-pll.c | 30 +-
drivers/clk/qcom/negcc-nord.c | 3 +-
drivers/clk/qcom/nwgcc-nord.c | 4 +-
drivers/clk/qcom/segcc-nord.c | 2 +-
drivers/clk/qcom/tcsrcc-hawi.c | 158 +
drivers/clk/qcom/videocc-x1p42100.c | 585 +++
drivers/clk/renesas/clk-r8a73a4.c | 2 +
drivers/clk/renesas/clk-r8a7740.c | 2 +
drivers/clk/renesas/r8a779g0-cpg-mssr.c | 1 +
drivers/clk/renesas/r9a07g043-cpg.c | 2 +-
drivers/clk/renesas/r9a07g044-cpg.c | 2 +-
drivers/clk/renesas/r9a08g045-cpg.c | 13 +-
drivers/clk/renesas/r9a08g046-cpg.c | 355 ++
drivers/clk/renesas/r9a09g011-cpg.c | 7 +-
drivers/clk/renesas/r9a09g047-cpg.c | 84 +
drivers/clk/renesas/r9a09g077-cpg.c | 1 +
drivers/clk/renesas/renesas-cpg-mssr.c | 3 +
drivers/clk/renesas/rzg2l-cpg.c | 88 +-
drivers/clk/renesas/rzg2l-cpg.h | 18 +-
drivers/clk/renesas/rzv2h-cpg.c | 181 +
drivers/clk/renesas/rzv2h-cpg.h | 12 +
drivers/clk/rockchip/Kconfig | 2 +-
drivers/clk/rockchip/clk-rk3588.c | 16 +
drivers/clk/rockchip/clk.c | 25 +-
drivers/clk/rockchip/clk.h | 3 +
drivers/clk/samsung/clk-exynos850.c | 5 +-
drivers/clk/samsung/clk-exynos990.c | 307 +-
drivers/clk/socfpga/clk-agilex.c | 2 +
drivers/clk/spacemit/ccu-k3.c | 30 +-
drivers/clk/visconti/pll.c | 17 +-
drivers/interconnect/core.c | 20 +
include/dt-bindings/clock/canaan,k230-clk.h | 220 +
include/dt-bindings/clock/qcom,hawi-gcc.h | 253 ++
include/dt-bindings/clock/qcom,hawi-tcsrcc.h | 16 +
.../dt-bindings/clock/qcom,ipq5332-cmn-pll.h | 19 +
include/dt-bindings/clock/qcom,nord-negcc.h | 1 +
include/dt-bindings/clock/qcom,rpmh.h | 2 +
.../dt-bindings/clock/qcom,x1e80100-camcc.h | 3 +
.../clock/qcom,x1p42100-videocc.h | 48 +
.../dt-bindings/clock/rockchip,rk3588-cru.h | 4 +
.../dt-bindings/clock/spacemit,k3-clocks.h | 5 +
include/linux/adi-axi-common.h | 2 +
include/linux/clk/renesas.h | 20 +
include/linux/interconnect.h | 6 +
include/soc/rockchip/rk3588_grf.h | 2 +
include/soc/spacemit/k3-syscon.h | 4 +-
102 files changed, 12691 insertions(+), 900 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/canaan,k230-clk.yaml
create mode 100644 Documentation/devicetree/bindings/clock/qcom,hawi-gcc.yaml
copy Documentation/devicetree/bindings/clock/{qcom,kaanapali-gxclkctl.yaml => qcom,milos-gxclkctl.yaml} (73%)
create mode 100644 drivers/clk/clk-k230.c
rename drivers/clk/microchip/{clk-core.c => clk-pic32.c} (99%)
rename drivers/clk/microchip/{clk-core.h => clk-pic32.h} (100%)
copy drivers/clk/qcom/{camcc-x1e80100.c => camcc-x1p42100.c} (82%)
create mode 100644 drivers/clk/qcom/gcc-hawi.c
create mode 100644 drivers/clk/qcom/gcc-ipq9650.c
create mode 100644 drivers/clk/qcom/tcsrcc-hawi.c
create mode 100644 drivers/clk/qcom/videocc-x1p42100.c
create mode 100644 include/dt-bindings/clock/canaan,k230-clk.h
create mode 100644 include/dt-bindings/clock/qcom,hawi-gcc.h
create mode 100644 include/dt-bindings/clock/qcom,hawi-tcsrcc.h
create mode 100644 include/dt-bindings/clock/qcom,ipq5332-cmn-pll.h
create mode 100644 include/dt-bindings/clock/qcom,x1p42100-videocc.h
--
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: qcom: common: introduce qcom_cc_sync_state()
From: Brian Masney @ 2026-06-25 13:25 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Saravana Kannan, Abel Vesa, Maxime Ripard, Michael Turquette,
Stephen Boyd, Russell King, Bjorn Andersson, Hans de Goede,
Dmitry Baryshkov, linux-clk, linux-kernel, linux-arm-msm,
Jens Glathe
In-Reply-To: <b790c13d-0a4e-48c9-b8e1-743481c5e6b6@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 02:19:21PM +0200, Konrad Dybcio wrote:
> On 6/25/26 1:38 PM, Brian Masney wrote:
> > My next version of this series that I haven't posted yet allows chaining
> > the sync_state callbacks at the driver core level. It doesn't require
> > any of the QC clk driver changes, and will allow us to play nicely with
> > the pmdomain subsystem, and any others the move to sync_state in the
> > future.
> >
> > I think I see the confusion between us the last few rounds of review. In
> > this series, I added qcom_cc_sync_state() and converted 6 drivers over to
> > use it. (I excluded clk-cbf-8996.c since it is separate.) Only the 6
> > drivers today that called icc_sync_state() now call qcom_cc_sync_state() ->
> > icc_sync_state(). So from my vantage point it is the same overall
> > functionality.
> >
> > I didn't look at this from the perspective of qcom_cc_sync_state() would
> > be common infrastructure, and a newly added driver in the future that may
> > not interact with the ICC framework may use this. Is this correct?
>
> Aaah right, my mistake. I assumed that adding that binding
> qcom_cc_sync_state to all qcom clock drivers was the next step.
OK cool... I'm glad we figured this out. Email can be tough sometime! :)
Brian
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: qcom: common: introduce qcom_cc_sync_state()
From: Konrad Dybcio @ 2026-06-25 12:19 UTC (permalink / raw)
To: Brian Masney
Cc: Saravana Kannan, Abel Vesa, Maxime Ripard, Michael Turquette,
Stephen Boyd, Russell King, Bjorn Andersson, Hans de Goede,
Dmitry Baryshkov, linux-clk, linux-kernel, linux-arm-msm,
Jens Glathe
In-Reply-To: <aj0TQuaPWmSlLwIw@redhat.com>
On 6/25/26 1:38 PM, Brian Masney wrote:
> Hi Konrad,
>
> On Thu, Jun 25, 2026 at 11:44:12AM +0200, Konrad Dybcio wrote:
>> On 6/16/26 11:09 PM, Brian Masney wrote:
>>> Several qcom clk providers currently have a sync_state helper set to
>>> icc_sync_state(). With an upcoming change to the clk framework, if
>>> sync_state is not defined for the device, then the clk framework sets it
>>> to clk_sync_state().
>>>
>>> Clk providers that require their own sync_state will need to call the
>>> framework level clk_sync_state(). Let's introduce a new common helper
>>> qcom_cc_sync_state() that calls icc_sync_state() and clk_sync_state().
>>>
>>> Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
>>> Signed-off-by: Brian Masney <bmasney@redhat.com>
>>> ---
>>> drivers/clk/qcom/common.c | 9 +++++++++
>>> drivers/clk/qcom/common.h | 1 +
>>> 2 files changed, 10 insertions(+)
>>>
>>> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
>>> index eec369d2173b..31382c49c948 100644
>>> --- a/drivers/clk/qcom/common.c
>>> +++ b/drivers/clk/qcom/common.c
>>> @@ -3,12 +3,14 @@
>>> * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
>>> */
>>>
>>> +#include <linux/clk.h>
>>> #include <linux/export.h>
>>> #include <linux/module.h>
>>> #include <linux/regmap.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/clk-provider.h>
>>> #include <linux/interconnect-clk.h>
>>> +#include <linux/interconnect-provider.h>
>>> #include <linux/pm_runtime.h>
>>> #include <linux/reset-controller.h>
>>> #include <linux/of.h>
>>> @@ -464,5 +466,12 @@ int qcom_cc_probe_by_index(struct platform_device *pdev, int index,
>>> }
>>> EXPORT_SYMBOL_GPL(qcom_cc_probe_by_index);
>>>
>>> +void qcom_cc_sync_state(struct device *dev)
>>> +{
>>> + icc_sync_state(dev);
>>
>> As mentioned before, we really need to test for (qcom_cc_desc)->icc_hws
>> here
>>
>> If icc_sync_state() is called without an interconnect provider
>> being registered, the framework state gets messed up:
>>
>> --- drivers/interconnect/core.c
>> void icc_sync_state(struct device *dev)
>> {
>> struct icc_provider *p;
>> struct icc_node *n;
>> static int count; // function-static variable
>>
>> count++; // called for every clock controller in this revision
>>
>> if (count < providers_count) // kaboom
>> return;
>>
>> // actual sync_state never happens anymore
>>
>> Presumably one would pass this through drvdata, but be careful as
>> some drivers use it for other purposes today
>
> My next version of this series that I haven't posted yet allows chaining
> the sync_state callbacks at the driver core level. It doesn't require
> any of the QC clk driver changes, and will allow us to play nicely with
> the pmdomain subsystem, and any others the move to sync_state in the
> future.
>
> I think I see the confusion between us the last few rounds of review. In
> this series, I added qcom_cc_sync_state() and converted 6 drivers over to
> use it. (I excluded clk-cbf-8996.c since it is separate.) Only the 6
> drivers today that called icc_sync_state() now call qcom_cc_sync_state() ->
> icc_sync_state(). So from my vantage point it is the same overall
> functionality.
>
> I didn't look at this from the perspective of qcom_cc_sync_state() would
> be common infrastructure, and a newly added driver in the future that may
> not interact with the ICC framework may use this. Is this correct?
Aaah right, my mistake. I assumed that adding that binding
qcom_cc_sync_state to all qcom clock drivers was the next step.
Konrad
^ permalink raw reply
* Re: [PATCH] clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK
From: Konrad Dybcio @ 2026-06-25 12:11 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, linux-arm-msm, linux-clk,
linux-kernel
In-Reply-To: <20260623115644.392477-2-krzysztof.kozlowski@oss.qualcomm.com>
On 6/23/26 1:56 PM, Krzysztof Kozlowski wrote:
> Eliza EVK (eliza-cqs-evk.dts) does not have display enabled, however its
> Display Clock Controller is enabled and references parent clocks from
> DSI PHYs, which causes clock reparenting issues during probe (init) and
> warning on Eliza EVK:
>
> disp_cc_mdss_mdp_clk_src: rcg didn't update its configuration.
> WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xd4/0xe4, CPU#1: udevd/273
> ...
> update_config (drivers/clk/qcom/clk-rcg2.c:136 (discriminator 2)) (P)
> clk_rcg2_shared_disable (drivers/clk/qcom/clk-rcg2.c:1471)
> clk_rcg2_shared_init (drivers/clk/qcom/clk-rcg2.c:1540)
> __clk_register (drivers/clk/clk.c:3959 drivers/clk/clk.c:4368)
> devm_clk_hw_register (drivers/clk/clk.c:4448 (discriminator 1) drivers/clk/clk.c:4672 (discriminator 1))
> devm_clk_register_regmap (drivers/clk/qcom/clk-regmap.c:104)
> qcom_cc_really_probe (drivers/clk/qcom/common.c:418)
> qcom_cc_probe (drivers/clk/qcom/common.c:445)
> disp_cc_eliza_probe (dispcc-eliza.c:?) dispcc_eliza
> platform_probe (drivers/base/platform.c:1432)
>
> Fixes: 0e66f10942b5 ("clk: qcom: dispcc-eliza: Add Eliza display clock controller support")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 6/6] clk: qcom: gpucc: Add Nord graphics clock controller support
From: Konrad Dybcio @ 2026-06-25 12:09 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Shawn Guo, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-6-860c84539804@oss.qualcomm.com>
On 6/23/26 12:54 PM, Taniya Das wrote:
> Add support for the GPU clock controllers (GPUCC) on the Qualcomm
> Nord platform.
>
> The platform includes two GPU clock controller instances,GPUCC
> and GPU2CC. Register support for both controllers, which provide
> clocks required for the graphics subsystem.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 11 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gpu2cc-nord.c | 546 +++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/gpucc-nord.c | 593 +++++++++++++++++++++++++++++++++++++++++
GPU_2_CC and GPU_CC seem to have a different set of clocks and
resets. If that's not physically the case, please align the
lists. Otherwise, please use a separate bindings header for each
one
Konrad
^ permalink raw reply
* Re: [PATCH 4/6] clk: qcom: Add Nord display clock controller support
From: Konrad Dybcio @ 2026-06-25 12:06 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Shawn Guo, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-4-860c84539804@oss.qualcomm.com>
On 6/23/26 12:54 PM, Taniya Das wrote:
> Add support for the display clock controllers (DISPCC) on the
> Qualcomm Nord platform.
>
> The platform includes two display clock controller instances,
> display0 and display1. Register support for both controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
[...]
> +enum {
> + DT_BI_TCXO,
> + DT_BI_TCXO_AO,
This one can probably be removed, both files
I think the rest looks good
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: qcom: common: introduce qcom_cc_sync_state()
From: Brian Masney @ 2026-06-25 11:38 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Saravana Kannan, Abel Vesa, Maxime Ripard, Michael Turquette,
Stephen Boyd, Russell King, Bjorn Andersson, Hans de Goede,
Dmitry Baryshkov, linux-clk, linux-kernel, linux-arm-msm,
Jens Glathe
In-Reply-To: <21bbffb7-ce99-4c38-a5cc-6a3f3c7f48eb@oss.qualcomm.com>
Hi Konrad,
On Thu, Jun 25, 2026 at 11:44:12AM +0200, Konrad Dybcio wrote:
> On 6/16/26 11:09 PM, Brian Masney wrote:
> > Several qcom clk providers currently have a sync_state helper set to
> > icc_sync_state(). With an upcoming change to the clk framework, if
> > sync_state is not defined for the device, then the clk framework sets it
> > to clk_sync_state().
> >
> > Clk providers that require their own sync_state will need to call the
> > framework level clk_sync_state(). Let's introduce a new common helper
> > qcom_cc_sync_state() that calls icc_sync_state() and clk_sync_state().
> >
> > Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> > Signed-off-by: Brian Masney <bmasney@redhat.com>
> > ---
> > drivers/clk/qcom/common.c | 9 +++++++++
> > drivers/clk/qcom/common.h | 1 +
> > 2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> > index eec369d2173b..31382c49c948 100644
> > --- a/drivers/clk/qcom/common.c
> > +++ b/drivers/clk/qcom/common.c
> > @@ -3,12 +3,14 @@
> > * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> > */
> >
> > +#include <linux/clk.h>
> > #include <linux/export.h>
> > #include <linux/module.h>
> > #include <linux/regmap.h>
> > #include <linux/platform_device.h>
> > #include <linux/clk-provider.h>
> > #include <linux/interconnect-clk.h>
> > +#include <linux/interconnect-provider.h>
> > #include <linux/pm_runtime.h>
> > #include <linux/reset-controller.h>
> > #include <linux/of.h>
> > @@ -464,5 +466,12 @@ int qcom_cc_probe_by_index(struct platform_device *pdev, int index,
> > }
> > EXPORT_SYMBOL_GPL(qcom_cc_probe_by_index);
> >
> > +void qcom_cc_sync_state(struct device *dev)
> > +{
> > + icc_sync_state(dev);
>
> As mentioned before, we really need to test for (qcom_cc_desc)->icc_hws
> here
>
> If icc_sync_state() is called without an interconnect provider
> being registered, the framework state gets messed up:
>
> --- drivers/interconnect/core.c
> void icc_sync_state(struct device *dev)
> {
> struct icc_provider *p;
> struct icc_node *n;
> static int count; // function-static variable
>
> count++; // called for every clock controller in this revision
>
> if (count < providers_count) // kaboom
> return;
>
> // actual sync_state never happens anymore
>
> Presumably one would pass this through drvdata, but be careful as
> some drivers use it for other purposes today
My next version of this series that I haven't posted yet allows chaining
the sync_state callbacks at the driver core level. It doesn't require
any of the QC clk driver changes, and will allow us to play nicely with
the pmdomain subsystem, and any others the move to sync_state in the
future.
I think I see the confusion between us the last few rounds of review. In
this series, I added qcom_cc_sync_state() and converted 6 drivers over to
use it. (I excluded clk-cbf-8996.c since it is separate.) Only the 6
drivers today that called icc_sync_state() now call qcom_cc_sync_state() ->
icc_sync_state(). So from my vantage point it is the same overall
functionality.
I didn't look at this from the perspective of qcom_cc_sync_state() would
be common infrastructure, and a newly added driver in the future that may
not interact with the ICC framework may use this. Is this correct?
I asked earlier if this was an existing bug, and the response was no.
Once I fix my x13s today, and able to verify my v3 sync_state still
works as expected, I'll post the new version.
Brian
^ permalink raw reply
* Re: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Philipp Zabel @ 2026-06-25 10:22 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], mturquette@baylibre.com,
sboyd@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Edgar Lee [李承諭],
afaerber@suse.com, Jyan Chou [周芷安],
bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <f3b747e20110424c8a434cbd271edb87@realtek.com>
On Do, 2026-06-25 at 10:05 +0000, Yu-Chun Lin [林祐君] wrote:
> Hi Philipp,
>
> > On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > > From: Cheng-Yu Lee <cylee12@realtek.com>
> > >
> > > Add support for the ISO (Isolation) domain reset controller on the
> > > Realtek
> > > RTD1625 SoC.
> > >
> > > The reset controller shares the same register space with the ISO clock
> > > controller. To handle this shared register space, the reset driver is
> > > implemented as an auxiliary driver. It will be instantiated and probed
> > > via the auxiliary bus by the RTD1625-ISO clock controller driver.
> > >
> > > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > > ---
> > > Changes in v9:
> > > - Extract reset-related code from the previous clock driver patch
> > > (formerly patch 9 in v8).
> > > ---
> > > drivers/reset/realtek/Makefile | 2 +-
> > > drivers/reset/realtek/reset-rtd1625-iso.c | 99
> > > +++++++++++++++++++++++
> > > 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644
> > > drivers/reset/realtek/reset-rtd1625-iso.c
> > >
> > > diff --git a/drivers/reset/realtek/Makefile
> > > b/drivers/reset/realtek/Makefile index c3f605ffb11c..9007c9d5683b
> > > 100644
> > > --- a/drivers/reset/realtek/Makefile
> > > +++ b/drivers/reset/realtek/Makefile
> > > @@ -1,3 +1,3 @@
> > > # SPDX-License-Identifier: GPL-2.0-only
> > > obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> > > -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > > +reset-rtd1625-iso.o
> >
> > Is there any benefit to these two being separate modules?
> > I suggest you merge them into one: reset-rtd1625.o
> >
>
> If I merge them into a single 'reset-rtd1625' module,
> both the 'crt' and 'iso' clock drivers would trigger the probe
> process for the same reset driver name, which would lead to a
> duplicate driver registration error.
What do you mean by duplicate driver registration error?
There would only be one auxiliary_driver, with support for all three
auxiliary_device_id's.
regards
Philipp
^ permalink raw reply
* RE: [PATCH v9 04/12] reset: realtek: Add RTD1625-ISO reset controller driver
From: Yu-Chun Lin [林祐君] @ 2026-06-25 10:05 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <9db83aa615f43ff6eac090626b43915fcd593a25.camel@pengutronix.de>
Hi Philipp,
> On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add support for the ISO (Isolation) domain reset controller on the
> > Realtek
> > RTD1625 SoC.
> >
> > The reset controller shares the same register space with the ISO clock
> > controller. To handle this shared register space, the reset driver is
> > implemented as an auxiliary driver. It will be instantiated and probed
> > via the auxiliary bus by the RTD1625-ISO clock controller driver.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v9:
> > - Extract reset-related code from the previous clock driver patch
> > (formerly patch 9 in v8).
> > ---
> > drivers/reset/realtek/Makefile | 2 +-
> > drivers/reset/realtek/reset-rtd1625-iso.c | 99
> > +++++++++++++++++++++++
> > 2 files changed, 100 insertions(+), 1 deletion(-) create mode 100644
> > drivers/reset/realtek/reset-rtd1625-iso.c
> >
> > diff --git a/drivers/reset/realtek/Makefile
> > b/drivers/reset/realtek/Makefile index c3f605ffb11c..9007c9d5683b
> > 100644
> > --- a/drivers/reset/realtek/Makefile
> > +++ b/drivers/reset/realtek/Makefile
> > @@ -1,3 +1,3 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > obj-$(CONFIG_RESET_RTK_COMMON) += reset-rtk-common.o
> > -obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > +obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > +reset-rtd1625-iso.o
>
> Is there any benefit to these two being separate modules?
> I suggest you merge them into one: reset-rtd1625.o
>
If I merge them into a single 'reset-rtd1625' module,
both the 'crt' and 'iso' clock drivers would trigger the probe
process for the same reset driver name, which would lead to a
duplicate driver registration error.
Therefore, I would prefer to keep them separate.
> > diff --git a/drivers/reset/realtek/reset-rtd1625-iso.c
> > b/drivers/reset/realtek/reset-rtd1625-iso.c
> > new file mode 100644
> > index 000000000000..78eaabb408f0
> > --- /dev/null
> > +++ b/drivers/reset/realtek/reset-rtd1625-iso.c
> > @@ -0,0 +1,99 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2026 Realtek Semiconductor Corporation */
> > +
> > +#include <dt-bindings/reset/realtek,rtd1625.h>
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/device.h>
> > +#include <linux/errno.h>
> > +#include <linux/of.h>
> > +#include <linux/slab.h>
> > +#include "reset-rtk-common.h"
> > +
> > +#define RTD1625_ISO_RSTN_MAX 29
> > +#define RTD1625_ISO_S_RSTN_MAX 5
>
> These are not necessary, just use ARRAY_SIZE() for nr_resets.
>
Ack.
> > +
[...]
> > +
> > +static int rtd1625_iso_reset_probe(struct auxiliary_device *adev,
> > + const struct auxiliary_device_id *id)
> > +{
> > + struct device *dev = &adev->dev;
> > + struct device *parent = dev->parent;
> > + struct rtk_reset_data *data;
> > +
> > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + if (of_device_is_compatible(parent->of_node,
> "realtek,rtd1625-iso-s-clk")) {
> > + data->descs = rtd1625_iso_s_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_S_RSTN_MAX;
> > + } else {
> > + data->descs = rtd1625_iso_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_RSTN_MAX;
> > + }
>
> No need to parse OF compatible again. Store these in a struct, point
> auxiliary_device_id::driver_data to it, and use that here.
>
> regards
> Philipp
Agreed, I will do it in v10. Thanks.
Best Regards,
Yu-Chun
^ permalink raw reply
* RE: [PATCH v9 02/12] reset: Add Realtek basic reset support
From: Yu-Chun Lin [林祐君] @ 2026-06-25 10:02 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], bmasney@redhat.com
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <eb03894ae2765a426457238157e474087ea0aaa6.camel@pengutronix.de>
Hi Philipp,
> On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + const struct rtk_reset_desc *desc;
> > + u32 mask, val;
> > +
> > + desc = rtk_reset_get_desc(data, idx);
> > + mask = desc->write_en ? (0x3U << desc->bit) : BIT(desc->bit);
> > + val = mask;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val);
>
> You can use regmap_set_bits() here.
>
Ack.
> > +}
> > +
> > +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + const struct rtk_reset_desc *desc;
> > + u32 val;
>
> unsigned int val;
>
Ack.
> > + int ret;
> > +
> > + desc = rtk_reset_get_desc(data, idx);
> > + ret = regmap_read(data->regmap, desc->ofs, &val);
> > + if (ret)
> > + return ret;
> > +
> > + return !((val >> desc->bit) & 1); }
> > +
> > +static const struct reset_control_ops rtk_reset_ops = {
> > + .assert = rtk_reset_assert,
> > + .deassert = rtk_reset_deassert,
> > + .status = rtk_reset_status,
> > +};
> > +
> > +/* The caller must initialize data->descs, data->rcdev.nr_resets and
> > + * data->rcdev.owner before calling rtk_reset_controller_add().
> > + */
> > +int rtk_reset_controller_add(struct device *dev,
> > + struct rtk_reset_data *data) {
> > + data->regmap = dev_get_platdata(dev);
> > + data->rcdev.ops = &rtk_reset_ops;
> > + data->rcdev.dev = dev;
> > + data->rcdev.of_node = dev->parent->of_node;
>
> This split rcdev initialization is more hassle than it is worth.
> Please just export rtk_reset_ops and duplicate the regmap/ops/dev/of_node
> assignment in the probe functions.
>
> Alternatively, consolidate the probe function and export it from here.
>
Thanks for your suggestion. I will go with your first approach in v10.
Best Regards,
Yu-Chun
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH v2 3/5] clk: qcom: convert from icc_sync_state() to qcom_cc_sync_state()
From: Konrad Dybcio @ 2026-06-25 9:44 UTC (permalink / raw)
To: Brian Masney, Saravana Kannan, Abel Vesa, Maxime Ripard,
Michael Turquette, Stephen Boyd, Russell King, Bjorn Andersson,
Hans de Goede, Dmitry Baryshkov
Cc: linux-clk, linux-kernel, linux-arm-msm, Jens Glathe
In-Reply-To: <20260616-clk-sync-state-v2-3-15f82c64d95c@redhat.com>
On 6/16/26 11:09 PM, Brian Masney wrote:
> Convert all of the qcom clk drivers that use qcom_cc_*() from
> icc_sync_state() to qcom_cc_sync_state().
>
> Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: qcom: common: introduce qcom_cc_sync_state()
From: Konrad Dybcio @ 2026-06-25 9:44 UTC (permalink / raw)
To: Brian Masney, Saravana Kannan, Abel Vesa, Maxime Ripard,
Michael Turquette, Stephen Boyd, Russell King, Bjorn Andersson,
Hans de Goede, Dmitry Baryshkov
Cc: linux-clk, linux-kernel, linux-arm-msm, Jens Glathe
In-Reply-To: <20260616-clk-sync-state-v2-2-15f82c64d95c@redhat.com>
On 6/16/26 11:09 PM, Brian Masney wrote:
> Several qcom clk providers currently have a sync_state helper set to
> icc_sync_state(). With an upcoming change to the clk framework, if
> sync_state is not defined for the device, then the clk framework sets it
> to clk_sync_state().
>
> Clk providers that require their own sync_state will need to call the
> framework level clk_sync_state(). Let's introduce a new common helper
> qcom_cc_sync_state() that calls icc_sync_state() and clk_sync_state().
>
> Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> drivers/clk/qcom/common.c | 9 +++++++++
> drivers/clk/qcom/common.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
> index eec369d2173b..31382c49c948 100644
> --- a/drivers/clk/qcom/common.c
> +++ b/drivers/clk/qcom/common.c
> @@ -3,12 +3,14 @@
> * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
> */
>
> +#include <linux/clk.h>
> #include <linux/export.h>
> #include <linux/module.h>
> #include <linux/regmap.h>
> #include <linux/platform_device.h>
> #include <linux/clk-provider.h>
> #include <linux/interconnect-clk.h>
> +#include <linux/interconnect-provider.h>
> #include <linux/pm_runtime.h>
> #include <linux/reset-controller.h>
> #include <linux/of.h>
> @@ -464,5 +466,12 @@ int qcom_cc_probe_by_index(struct platform_device *pdev, int index,
> }
> EXPORT_SYMBOL_GPL(qcom_cc_probe_by_index);
>
> +void qcom_cc_sync_state(struct device *dev)
> +{
> + icc_sync_state(dev);
As mentioned before, we really need to test for (qcom_cc_desc)->icc_hws
here
If icc_sync_state() is called without an interconnect provider
being registered, the framework state gets messed up:
--- drivers/interconnect/core.c
void icc_sync_state(struct device *dev)
{
struct icc_provider *p;
struct icc_node *n;
static int count; // function-static variable
count++; // called for every clock controller in this revision
if (count < providers_count) // kaboom
return;
// actual sync_state never happens anymore
Presumably one would pass this through drvdata, but be careful as
some drivers use it for other purposes today
Konrad
^ permalink raw reply
* Re: [PATCH v2 4/5] clk: qcom: cbf-8996: add clk_sync_state() call
From: Konrad Dybcio @ 2026-06-25 9:38 UTC (permalink / raw)
To: Brian Masney, Saravana Kannan, Abel Vesa, Maxime Ripard,
Michael Turquette, Stephen Boyd, Russell King, Bjorn Andersson,
Hans de Goede, Dmitry Baryshkov
Cc: linux-clk, linux-kernel, linux-arm-msm
In-Reply-To: <20260616-clk-sync-state-v2-4-15f82c64d95c@redhat.com>
On 6/16/26 11:09 PM, Brian Masney wrote:
> This driver doesn't use qcom_cc_probe() in qcom/common.c, so it
> shouldn't use the newly introduced qcom_cc_sync_state(). Let's go ahead
> and add a driver-specific sync state call.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 13/13] arm64: dts: qcom: shikra: Add support for DISPCC/GPUCC nodes
From: Konrad Dybcio @ 2026-06-25 8:44 UTC (permalink / raw)
To: Imran Shaik, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Loic Poulain, Brian Masney
Cc: Ajit Pandey, Taniya Das, Jagadeesh Kona, linux-arm-msm, linux-clk,
devicetree, linux-kernel
In-Reply-To: <20260604-shikra-dispcc-gpucc-v4-13-8204f1029311@oss.qualcomm.com>
On 6/4/26 7:26 AM, Imran Shaik wrote:
> Add support for Display clock controller and GPU clock controller nodes
> on Qualcomm Shikra SoCs.
>
> Signed-off-by: Imran Shaik <imran.shaik@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/shikra.dtsi | 41 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 41 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/shikra.dtsi b/arch/arm64/boot/dts/qcom/shikra.dtsi
> index a4334d99c1f35ee851ca8266ec37d4a200a07ee5..1ccb0f1419aaa34d32f3c3eaabdb8727a497b501 100644
> --- a/arch/arm64/boot/dts/qcom/shikra.dtsi
> +++ b/arch/arm64/boot/dts/qcom/shikra.dtsi
> @@ -3,6 +3,8 @@
> * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> */
>
> +#include <dt-bindings/clock/qcom,dispcc-qcm2290.h>
> +#include <dt-bindings/clock/qcom,qcm2290-gpucc.h>
> #include <dt-bindings/clock/qcom,rpmcc.h>
> #include <dt-bindings/clock/qcom,shikra-gcc.h>
> #include <dt-bindings/interconnect/qcom,icc.h>
> @@ -640,6 +642,45 @@ &clk_virt SLAVE_QUP_CORE_0 RPM_ALWAYS_TAG>,
> };
> };
>
> + gpucc: clock-controller@5990000 {
> + compatible = "qcom,shikra-gpucc";
> + reg = <0x0 0x05990000 0x0 0x9000>;
> + clocks = <&gcc GCC_GPU_CFG_AHB_CLK>,
> + <&rpmcc RPM_SMD_XO_CLK_SRC>,
> + <&gcc GCC_GPU_GPLL0_CLK_SRC>,
> + <&gcc GCC_GPU_GPLL0_DIV_CLK_SRC>;
> + power-domains = <&rpmpd RPMPD_VDDCX>;
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + };
> +
> + dispcc: clock-controller@5f00000 {
> + compatible = "qcom,shikra-dispcc", "qcom,qcm2290-dispcc";
> + reg = <0x0 0x05f00000 0x0 0x20000>;
> + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
> + <&rpmcc RPM_SMD_XO_A_CLK_SRC>,
> + <&gcc GCC_DISP_GPLL0_CLK_SRC>,
> + <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>,
> + <0>,
> + <0>,
> + <0>,
> + <0>,
> + <&sleep_clk>;
> + clock-names = "bi_tcxo",
> + "bi_tcxo_ao",
Is the AO clock going to be any useful? Taniya recently dropped it
from some other submission after assessing it wasn't
> + "gcc_disp_gpll0_clk_src",
> + "gcc_disp_gpll0_div_clk_src",
> + "dsi0_phy_pll_out_byteclk",
> + "dsi0_phy_pll_out_dsiclk",
> + "dsi1_phy_pll_out_byteclk",
> + "dsi1_phy_pll_out_dsiclk",
> + "sleep_clk";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
DISP_CC also needs to source power from somewhere!
Konrad
^ permalink raw reply
* [PATCH v2 1/1 RESEND v2] clk: tegra: support 48MHz clock for pll_p_out1
From: Svyatoslav Ryhel @ 2026-06-25 8:30 UTC (permalink / raw)
To: Prashant Gaikwad, Michael Turquette, Stephen Boyd, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel
Cc: linux-clk, linux-tegra, linux-kernel
In-Reply-To: <20260625083052.65405-1-clamor95@gmail.com>
From: Dmitry Osipenko <digetx@gmail.com>
UEFI on Surface2 sets pll_p_out1 to 48MHz which is not supported by kernel
and causes BUG() early on. Add 48MHz clock support for pll_p_out1.
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/clk/tegra/clk-pll.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/tegra/clk-pll.c b/drivers/clk/tegra/clk-pll.c
index d86003b6d94f..adfb74f111ef 100644
--- a/drivers/clk/tegra/clk-pll.c
+++ b/drivers/clk/tegra/clk-pll.c
@@ -575,6 +575,7 @@ static int _calc_rate(struct clk_hw *hw, struct tegra_clk_pll_freq_table *cfg,
break;
case 9600000:
case 28800000:
+ case 48000000:
/*
* PLL_P_OUT1 rate is not listed in PLLA table
*/
--
2.51.0
^ permalink raw reply related
* [PATCH v2 0/1 RESEND v2] clk: tegra: support 48MHz clock for pll_p_out1
From: Svyatoslav Ryhel @ 2026-06-25 8:30 UTC (permalink / raw)
To: Prashant Gaikwad, Michael Turquette, Stephen Boyd, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel
Cc: linux-clk, linux-tegra, linux-kernel
UEFI on Surface2 sets pll_p_out1 to 48MHz which is not supported
by kernel and causes BUG() early on. Fix this by adding 48MHz
clock support for pll_p_out1 along with 48MHz support for pll_a,
main pll_p_out1 descendant.
---
Changes in v2:
- aligned with downstream 3.4 kernel for tegra114 logic
---
Dmitry Osipenko (1):
clk: tegra: support 48MHz clock for pll_p_out1
drivers/clk/tegra/clk-pll.c | 1 +
1 file changed, 1 insertion(+)
--
2.51.0
^ permalink raw reply
* [PATCH v1 1/1 RESEND v3] clk: tegra: set up proper EMC clock implementation for Tegra114
From: Svyatoslav Ryhel @ 2026-06-25 8:19 UTC (permalink / raw)
To: Prashant Gaikwad, Michael Turquette, Stephen Boyd, Thierry Reding,
Thierry Reding, Jonathan Hunter, Mikko Perttunen,
Svyatoslav Ryhel
Cc: linux-clk, linux-tegra, linux-kernel
In-Reply-To: <20260625081906.39254-1-clamor95@gmail.com>
Remove current emc and emc_mux clocks and replace them with the proper EMC
clock implementation for correct EMC driver support.
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
---
drivers/clk/tegra/clk-tegra114.c | 39 ++++++++++++++++++++------------
1 file changed, 25 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/tegra/clk-tegra114.c b/drivers/clk/tegra/clk-tegra114.c
index 8bde72aa5e68..853ef707654a 100644
--- a/drivers/clk/tegra/clk-tegra114.c
+++ b/drivers/clk/tegra/clk-tegra114.c
@@ -622,10 +622,6 @@ static const char *mux_plld_out0_plld2_out0[] = {
};
#define mux_plld_out0_plld2_out0_idx NULL
-static const char *mux_pllmcp_clkm[] = {
- "pll_m_out0", "pll_c_out0", "pll_p_out0", "clk_m", "pll_m_ud",
-};
-
static const struct clk_div_table pll_re_div_table[] = {
{ .val = 0, .div = 1 },
{ .val = 1, .div = 2 },
@@ -672,7 +668,6 @@ static struct tegra_clk tegra114_clks[tegra_clk_max] __initdata = {
[tegra_clk_csi] = { .dt_id = TEGRA114_CLK_CSI, .present = true },
[tegra_clk_i2c2] = { .dt_id = TEGRA114_CLK_I2C2, .present = true },
[tegra_clk_uartc] = { .dt_id = TEGRA114_CLK_UARTC, .present = true },
- [tegra_clk_emc] = { .dt_id = TEGRA114_CLK_EMC, .present = true },
[tegra_clk_usb2] = { .dt_id = TEGRA114_CLK_USB2, .present = true },
[tegra_clk_usb3] = { .dt_id = TEGRA114_CLK_USB3, .present = true },
[tegra_clk_vde_8] = { .dt_id = TEGRA114_CLK_VDE, .present = true },
@@ -1048,14 +1043,7 @@ static __init void tegra114_periph_clk_init(void __iomem *clk_base,
0, 82, periph_clk_enb_refcnt);
clks[TEGRA114_CLK_DSIB] = clk;
- /* emc mux */
- clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
- ARRAY_SIZE(mux_pllmcp_clkm),
- CLK_SET_RATE_NO_REPARENT,
- clk_base + CLK_SOURCE_EMC,
- 29, 3, 0, &emc_lock);
-
- clk = tegra_clk_register_mc("mc", "emc_mux", clk_base + CLK_SOURCE_EMC,
+ clk = tegra_clk_register_mc("mc", "emc", clk_base + CLK_SOURCE_EMC,
&emc_lock);
clks[TEGRA114_CLK_MC] = clk;
@@ -1321,6 +1309,26 @@ static int tegra114_reset_deassert(unsigned long id)
return 0;
}
+static struct clk *tegra114_clk_src_onecell_get(struct of_phandle_args *clkspec,
+ void *data)
+{
+ struct clk_hw *hw;
+ struct clk *clk;
+
+ clk = of_clk_src_onecell_get(clkspec, data);
+ if (IS_ERR(clk))
+ return clk;
+
+ hw = __clk_get_hw(clk);
+
+ if (clkspec->args[0] == TEGRA114_CLK_EMC) {
+ if (!tegra124_clk_emc_driver_available(hw))
+ return ERR_PTR(-EPROBE_DEFER);
+ }
+
+ return clk;
+}
+
static void __init tegra114_clock_init(struct device_node *np)
{
struct device_node *node;
@@ -1368,7 +1376,10 @@ static void __init tegra114_clock_init(struct device_node *np)
tegra_init_special_resets(1, tegra114_reset_assert,
tegra114_reset_deassert);
- tegra_add_of_provider(np, of_clk_src_onecell_get);
+ tegra_add_of_provider(np, tegra114_clk_src_onecell_get);
+ clks[TEGRA114_CLK_EMC] = tegra124_clk_register_emc(clk_base, np,
+ &emc_lock);
+
tegra_register_devclks(devclks, ARRAY_SIZE(devclks));
tegra_clk_apply_init_table = tegra114_clock_apply_init_table;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 0/1 RESEND v3] clk: tegra: set up proper EMC clock implementation for Tegra114
From: Svyatoslav Ryhel @ 2026-06-25 8:19 UTC (permalink / raw)
To: Prashant Gaikwad, Michael Turquette, Stephen Boyd, Thierry Reding,
Thierry Reding, Jonathan Hunter, Mikko Perttunen,
Svyatoslav Ryhel
Cc: linux-clk, linux-tegra, linux-kernel
Remove current emc and emc_mux clocks and replace them with the proper EMC
clock implementation for correct EMC driver support.
Part of previous patchset: https://lore.kernel.org/lkml/20251125120559.158860-1-clamor95@gmail.com/
Svyatoslav Ryhel (1):
clk: tegra: set up proper EMC clock implementation for Tegra114
drivers/clk/tegra/clk-tegra114.c | 39 ++++++++++++++++++++------------
1 file changed, 25 insertions(+), 14 deletions(-)
--
2.51.0
^ permalink raw reply
* Re: [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver
From: Philipp Zabel @ 2026-06-25 8:17 UTC (permalink / raw)
To: Stefan Dösinger, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Brian Masney
Cc: linux-clk, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <7_XKp5ZWTJeJfxJieymOJA@gmail.com>
On Mi, 2026-06-24 at 23:00 +0300, Stefan Dösinger wrote:
> Hi Philipp,
>
> Am Donnerstag, 18. Juni 2026, 12:24:26 Ostafrikanische Zeit schrieb Philipp
> Zabel:
>
> > > + [ZX297520V3_UART0_RESET] = { .reg = 0x78, .mask = BIT(6) |
> BIT(7)
> > > },
> > Is this a single reset line controlled by two bits (do you know what
> > they are)? Or might these actually be two different reset controls that
> > are just always set together?
>
> I suppose I could expose both bits as separate reset controls in the binding.
> The lower bit is usually the one that actually resets the device, while the
> higher one works similarly to PCLK - it disconnects the device from the bus,
> if asserted. Depending on the device it may or may not leave any residual
> effect behind after deassert.
So it's not a separate reset.
Whether bus isolation should be controlled together with the reset or
not could be argued, but exposing this as a separate reset control via
the reset API would not be correct.
> The stumbling block is the dwc2 USB driver. It only takes one reset, so I'd
> have to add another one (or abuse the dwc2-ecc reset) and presumably add a PHY
> driver for the 3rd reset or add a dwc2-phy reset.
This on the other hand sounds like there is a separate PHY reset line?
If so, I think that should be modeled as a separate control.
regards
Philipp
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox