Re: [PATCH] clocksource/drivers/arm_arch_timer: Workaround bcm2712 broken EL2 virtual timer

[Marc Zyngier <maz@kernel.org>]

On Thu, 23 Jul 2026 11:22:54 +0100,
Jon Hunter <jonathanh@nvidia.com> wrote:
> 
> 
> On 23/07/2026 10:58, Marc Zyngier wrote:
> 
> ...
> 
> >>>> I have posted something similar for Tegra [0], but because this is not
> >>>> expected to work, I wanted to avoid the warnings here. We test for
> >>> 
> >>> "not expected to work"? In which parallel universe is that a thing?
> >> 
> >> FWIU, at least for Tegra194, we have a CPU and GIC pairing where the
> >> CPU supports this but the GIC does not.
> > 
> > Oh please, you know better than this.
> >
> > It isn't the GIC that defines the number of supported PPIs, it is the
> > *integrator*. I.e. you. The GIC (GIC400 in this example) has full
> > support for 16 PPIs per CPU.
> 
> Hmmm, I am looking at this spec [0] and it says ...
> 
> "The GIC-400 implements the interrupt types:
>   16 Software Generated Interrupts (SGIs).
>   6 external Private Peripheral Interrupts (PPIs) for each processor.
>   1 internal PPI for each processor."
> 
> The table in [1] shows interrupts for non-sec, sec, virt and
> hypervisor timers, but I don't see a hyp-virt.

This documentation was never updated past 2012, which predates ARMv8.1
(go complain to ARM). But the IP does support it:

[    0.000000] Machine model: Khadas VIM3L
[...]
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] Root IRQ handler: gic_handle_irq
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.000000] arch_timer: cp15 timer running at 24.00MHz (hyp-virt).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns

GIC400, A55 cores. Produced by one of the worse SoC vendor on this
side of the galaxy.

And the signal you are looking for is the one labelled as "Legacy FIQ
signal" (PPI12, aka INTID 28). The labels are purely indicative of
what you *could* connect to it, not a requirement.

Anyway, this is beside the point. Even if the IP didn't support it,
you shouldn't end-up with a design that explicitly contradict the
architecture, because that's the contract SW relies on.

	M.

-- 
Without deviation from the norm, progress is not possible.