From: Andre Przywara <andre.przywara@arm.com>
To: Junhui Liu <junhui.liu@pigmoral.tech>, wens@kernel.org
Cc: Stephen Boyd <sboyd@kernel.org>,
Brian Masney <bmasney+clk@redhat.com>,
Jerome Brunet <jbrunet+clk@baylibre.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Samuel Holland <samuel@sholland.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>,
Richard Cochran <richardcochran@gmail.com>,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, netdev@vger.kernel.org,
Jerome Brunet <jbrunet@baylibre.com>,
Enzo Adriano <enzo.adriano.code@gmail.com>
Subject: Re: [PATCH v5 7/8] clk: sunxi-ng: a733: Add bus clock gates
Date: Mon, 5 Oct 2026 11:17:00 +0200 [thread overview]
Message-ID: <4ac4c90f-887e-4545-9c26-9706bdaa1a79@arm.com> (raw)
In-Reply-To: <DLWMN3TYBP9F.3N62QFP7QEE9U@pigmoral.tech>
Hi,
On 10/5/26 06:41, Junhui Liu wrote:
> Hi Chen-Yu,
>
> On Sun Oct 4, 2026 at 7:03 PM CST, Chen-Yu Tsai wrote:
>> On Tue, Sep 29, 2026 at 7:28 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
>>>
>>> Add the bus clock gates that control access to the devices' register
>>> interface on the Allwinner A733 SoC. These clocks are typically
>>> single-bit controls in the BGR registers, covering UARTs, SPI, I2C, and
>>> various multimedia engines. It also includes bus gates for system
>>> components like the IOMMU and MSI-lite interfaces.
>>>
>>> Also mark the ahb-store, mbus-store and ahb-cpus clocks as critical.
>>> Disabling either store gate breaks access to boot/storage devices such
>>> as MMC and SPI NOR, while gating ahb-cpus hangs any access to the CPUS
>>> power domain registers when unused clocks are disabled.
>>>
>>> Tested-by: Jerome Brunet <jbrunet@baylibre.com>
>>> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>>> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
>>> ---
>>> drivers/clk/sunxi-ng/ccu-sun60i-a733.c | 492 ++++++++++++++++++++++++++++++++-
>>> 1 file changed, 491 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
>>> index 1b2d4d36ec4c..b077e5d2f32c 100644
>>> --- a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
>>> +++ b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
>>> @@ -4,6 +4,10 @@
>>> * Copyright (C) 2026 Junhui Liu <junhui.liu@pigmoral.tech>
>>> * Based on the A523 CCU driver:
>>> * Copyright (C) 2023-2024 Arm Ltd.
>>> + *
>>> + * TODO: The real parents of some bus gates, including its-pcie0-aclk,
>>> + * msi-lite, npu, ufs, sgpio, lpc and i2spcm, are not documented in the
>>> + * manual. For now, follow the vendor BSP, which keeps them on hosc.
>>> */
>>
>> [...]
>>
>>> @@ -510,9 +522,118 @@ static SUNXI_CCU_M_DATA_WITH_MUX_GATE_FEAT(mbus_clk, "mbus", mbus_parents, 0x588
>>> BIT(31), /* gate */
>>> CLK_IS_CRITICAL,
>>> CCU_FEATURE_UPDATE_BIT);
>>> +static const struct clk_hw *mbus_hws[] = { &mbus_clk.common.hw };
>>> +
>>> +static SUNXI_CCU_GATE_HWS(mbus_iommu0_sys_clk, "mbus-iommu0-sys", mbus_hws, 0x58c, BIT(0), 0);
>>> +static SUNXI_CCU_GATE_HWS(apb_iommu0_sys_clk, "apb-iommu0-sys", apb0_hws, 0x58c, BIT(1), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_iommu0_sys_clk, "ahb-iommu0-sys", ahb_hws, 0x58c, BIT(2), 0);
>>> +
>>> +static SUNXI_CCU_GATE_DATA(bus_msi_lite0_clk, "bus-msi-lite0", hosc, 0x594, BIT(0), 0);
>>> +static SUNXI_CCU_GATE_DATA(bus_msi_lite1_clk, "bus-msi-lite1", hosc, 0x59c, BIT(0), 0);
>>> +static SUNXI_CCU_GATE_DATA(bus_msi_lite2_clk, "bus-msi-lite2", hosc, 0x5a4, BIT(0), 0);
>>> +
>>> +static SUNXI_CCU_GATE_HWS(mbus_iommu1_sys_clk, "mbus-iommu1-sys", mbus_hws, 0x5b4, BIT(0), 0);
>>> +static SUNXI_CCU_GATE_HWS(apb_iommu1_sys_clk, "apb-iommu1-sys", apb0_hws, 0x5b4, BIT(1), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_iommu1_sys_clk, "ahb-iommu1-sys", ahb_hws, 0x5b4, BIT(2), 0);
>>
>>> +static SUNXI_CCU_GATE_HWS(ahb_ve_dec_clk, "ahb-ve-dec", ahb_hws,
>>> + 0x5c0, BIT(0), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_ve_enc_clk, "ahb-ve-enc", ahb_hws,
>>> + 0x5c0, BIT(1), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_vid_in_clk, "ahb-vid-in", ahb_hws,
>>> + 0x5c0, BIT(2), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_vid_cout0_clk, "ahb-vid-cout0", ahb_hws,
>>> + 0x5c0, BIT(3), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_vid_cout1_clk, "ahb-vid-cout1", ahb_hws,
>>> + 0x5c0, BIT(4), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_de_clk, "ahb-de", ahb_hws,
>>> + 0x5c0, BIT(5), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_npu_clk, "ahb-npu", ahb_hws,
>>> + 0x5c0, BIT(6), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_gpu0_clk, "ahb-gpu0", ahb_hws,
>>> + 0x5c0, BIT(7), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_serdes_clk, "ahb-serdes", ahb_hws,
>>> + 0x5c0, BIT(8), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_usb_sys_clk, "ahb-usb-sys", ahb_hws,
>>> + 0x5c0, BIT(9), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_msi_lite0_clk, "ahb-msi-lite0", ahb_hws,
>>> + 0x5c0, BIT(16), 0);
>>> +static SUNXI_CCU_GATE_HWS(ahb_store_clk, "ahb-store", ahb_hws,
>>> + 0x5c0, BIT(24), CLK_IS_CRITICAL);
>>> +static SUNXI_CCU_GATE_HWS(ahb_cpus_clk, "ahb-cpus", ahb_hws,
>>> + 0x5c0, BIT(28), CLK_IS_CRITICAL);
>>
>> I suspect these refer to a AHB-AHB bridge for the various subsystems shown
>> in the memory map. That would explain why when the "ahb-store" clock is
>> gated, the storage bits stop working.
>>
>> If that's the case, we should describe it as the parent of each storage
>> peripheral bus gate's parent. Same would go for the other types. I haven't
>> checked what the BSP does though.
>
> As Norman mentioned in his reply, the vendor BSP also does not model
> this hierarchy and instead models these gates as independent clocks
> parented to the oscillator. The manual does not describe the hierarchy
> either, so I don't think we have enough information to model it
> differently at this point.
Well, I wouldn't use the BSP as a good example on how to model the clock
tree, they have been very misguided in the past.
What the BSP does is to add just more input/gate MBUS clocks for each
device, which is something I think we should avoid.
To that regard using them as parent clocks for the existing gates, as
Chen-Yu suggested, sounds like a good idea: We keep a single clock for
the devices, but still can turn both clocks off (I think, not tested).
Cheers,
Andre
> I will add comments explaining why ahb_store_clk, mbus_store_clk, and
> ahb_cpus_clk are marked critical.
>
>>
>>> +static SUNXI_CCU_GATE_HWS(mbus_iommu0_clk, "mbus-iommu0", mbus_hws,
>>> + 0x5e0, BIT(0), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_iommu1_clk, "mbus-iommu1", mbus_hws,
>>> + 0x5e0, BIT(1), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_desys_clk, "mbus-desys", mbus_hws,
>>> + 0x5e0, BIT(11), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_ve_enc0_gate_clk, "mbus-ve-enc0-gate", mbus_hws,
>>> + 0x5e0, BIT(12), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_ve_dec0_gate_clk, "mbus-ve-dec0-gate", mbus_hws,
>>> + 0x5e0, BIT(14), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_gpu0_clk, "mbus-gpu0", mbus_hws,
>>> + 0x5e0, BIT(16), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_npu_clk, "mbus-npu", mbus_hws,
>>> + 0x5e0, BIT(18), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_vid_in_clk, "mbus-vid-in", mbus_hws,
>>> + 0x5e0, BIT(24), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_serdes_clk, "mbus-serdes", mbus_hws,
>>> + 0x5e0, BIT(28), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_msi_lite0_clk, "mbus-msi-lite0", mbus_hws,
>>> + 0x5e0, BIT(29), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_store_clk, "mbus-store", mbus_hws,
>>> + 0x5e0, BIT(30), CLK_IS_CRITICAL);
>>
>> Same thing for the MBUS clocks.
>>
>>> +static SUNXI_CCU_GATE_HWS(mbus_msi_lite2_clk, "mbus-msi-lite2", mbus_hws,
>>> + 0x5e0, BIT(31), 0);
>>> +
>>> +static SUNXI_CCU_GATE_HWS(mbus_dma0_clk, "mbus-dma0", mbus_hws,
>>> + 0x5e4, BIT(0), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_ve_enc0_clk, "mbus-ve-enc0", mbus_hws,
>>> + 0x5e4, BIT(1), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_ce_clk, "mbus-ce", mbus_hws,
>>> + 0x5e4, BIT(2), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_dma1_clk, "mbus-dma1", mbus_hws,
>>> + 0x5e4, BIT(3), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_nand_clk, "mbus-nand", mbus_hws,
>>> + 0x5e4, BIT(5), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_csi_clk, "mbus-csi", mbus_hws,
>>> + 0x5e4, BIT(8), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_isp_clk, "mbus-isp", mbus_hws,
>>> + 0x5e4, BIT(9), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_gmac0_clk, "mbus-gmac0", mbus_hws,
>>> + 0x5e4, BIT(11), 0);
>>> +/* Undocumented, taken from the vendor kernel. */
>>> +static SUNXI_CCU_GATE_HWS(mbus_gmac1_clk, "mbus-gmac1", mbus_hws,
>>> + 0x5e4, BIT(12), 0);
>>> +static SUNXI_CCU_GATE_HWS(mbus_ve_dec0_clk, "mbus-ve-dec0", mbus_hws,
>>> + 0x5e4, BIT(18), 0);
>>
>> [...]
>>
>> The remaining definitions look correct (minus the vendor BSP ones which I
>> couldn't check at this time).
>>
>> I didn't check the clock list additions.
>>
>> Consider this
>>
>> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
>>
>
> Thanks!
>
>>
>> We can change the AHB / MBUS clock parents later if we do figure it out.
>>
>>
>> ChenYu
>
next prev parent reply other threads:[~2026-10-05 9:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 17:26 [PATCH v5 0/8] clk: sunxi-ng: Add support for Allwinner A733 CCU and PRCM Junhui Liu
2026-09-29 17:26 ` [PATCH v5 1/8] dt-bindings: clk: sun60i-a733-ccu: Add Allwinner A733 support Junhui Liu
2026-09-29 17:26 ` [PATCH v5 2/8] clk: sunxi-ng: sdm: Add dual patterns support Junhui Liu
2026-09-29 17:26 ` [PATCH v5 3/8] clk: sunxi-ng: a733: Add PRCM CCU Junhui Liu
2026-10-03 14:00 ` Chen-Yu Tsai
2026-10-03 14:57 ` Junhui Liu
2026-10-03 16:51 ` Norman Herms
2026-10-03 14:57 ` Norman Herms
2026-10-05 18:30 ` Vinicius Pedrosa
2026-09-29 17:26 ` [PATCH v5 4/8] clk: sunxi-ng: a733: Add PLL clocks support Junhui Liu
2026-10-04 10:08 ` Chen-Yu Tsai
2026-09-29 17:26 ` [PATCH v5 5/8] clk: sunxi-ng: a733: Add bus " Junhui Liu
2026-10-04 10:20 ` Chen-Yu Tsai
2026-09-29 17:26 ` [PATCH v5 6/8] clk: sunxi-ng: a733: Add mod " Junhui Liu
2026-09-29 17:26 ` [PATCH v5 7/8] clk: sunxi-ng: a733: Add bus clock gates Junhui Liu
2026-10-04 11:03 ` Chen-Yu Tsai
2026-10-04 11:14 ` AW: " Norman Herms
2026-10-05 4:41 ` Junhui Liu
2026-10-05 9:17 ` Andre Przywara [this message]
2026-09-29 17:26 ` [PATCH v5 8/8] clk: sunxi-ng: a733: Add reset lines Junhui Liu
2026-10-04 11:04 ` Chen-Yu Tsai
2026-10-03 12:52 ` [PATCH v5 0/8] clk: sunxi-ng: Add support for Allwinner A733 CCU and PRCM Junhui Liu
2026-10-03 13:37 ` Chen-Yu Tsai
2026-10-03 13:51 ` Norman Herms
2026-10-03 14:35 ` Junhui Liu
2026-10-03 15:05 ` Norman Herms
2026-10-03 15:23 ` Junhui Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ac4c90f-887e-4545-9c26-9706bdaa1a79@arm.com \
--to=andre.przywara@arm.com \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=bmasney+clk@redhat.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=enzo.adriano.code@gmail.com \
--cc=jbrunet+clk@baylibre.com \
--cc=jbrunet@baylibre.com \
--cc=jernej.skrabec@gmail.com \
--cc=junhui.liu@pigmoral.tech \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=netdev@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=richardcochran@gmail.com \
--cc=robh@kernel.org \
--cc=samuel@sholland.org \
--cc=sboyd@kernel.org \
--cc=wens@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®