On Tue, Oct 13, 2026 at 07:53:20AM +0200, Michal Simek wrote:
On 10/12/26 18:28, Leo Yan wrote:
On Mon, Oct 12, 2026 at 02:35:37PM +0200, Michal Simek wrote:
On 10/2/26 17:07, Leo Yan wrote:
Static replicators have no programmable registers and need no APB programming clock.
The Zynq clock controller registers dbg_trc and dbg_apb and calls clk_prepare_enable() for each gate the bootloader left on.
That's one bootloader behavior. If there is another bootloader that clocks can be simply disabled. I don't think there is any reason to depends on bootloader behavior. If there are clocks which has to be ON I can't see any reason not to drive them.
My reference to zynq_clk_setup() was to explain that this patch leaves the existing management of dbg_trc and dbg_apb unchanged.
The CoreSight drivers do not request clocks named "dbg_trc" or "dbg_apb".
And this is the point. DT binding is not describing what Linux driver handles. Binding describes HW itself.
I agreed that "Binding describes HW itself".
The question is which hardware clock connections the DT properties describe. Arm DDI 0314H, Table B-1 [1], lists ATCLK for the replicator, and ATCLK and PCLKDBG for the trace funnel. The static modules have no APB programming interface.
And for proper functionality these 2 clocks need to be handled.
Please point to the Zynq TRM section or clock diagram showing how dbg_trc and dbg_apb supply the replicator and funnel.
That Linux driver is not doing it that's different issue.
My understanding is the CoreSight drivers have already followed spec to support clocks.
[1] https://support.arm.com/documentation/ddi0314/h/CoreSight-Components-and-Clo...