On Tue, Jun 06, 2023 at 02:30:52PM +0100, Mark Rutland wrote:

quoted

quoted

Uh, *which* CPU device? Do we have a container device for all CPUs?

drivers/base/cpu.c:per_cpu(cpu_sys_devices, cpu) for whatever the core
pmu is for that cpu ?

... but the struct pmu covers several CPUs, so I don't have a single 'cpu', no?

If I have a system where cpu{0,1,2} are Cortex-A53 and cpu{3,4} are Cortex-A57,
I have two struct pmu instances, each associated with several CPUs. When I
probe each of those I determine a cpumask for each.

Bah :/ Clearly I overlooked the disparity there.

quoted

quoted

quoted

quoted

My overall favorite is an l2 cache related PMU that is spun up in
arch/arm/kernel/irq.c init_IRQ()

That's an artifact of the L2 cache controller driver getting initialized there;
ideally we'd have a device for the L2 cache itself (which presumably should
hang off an aggregate CPU device).

/sys/devices/system/cpu/cpuN/cache/indexM

has a struct device somewhere in
drivers/base/cacheinfo.c:ci_index_dev or somesuch.

I guess, but I don't think the L2 cache controller (the PL310) is actually tied
to that today.

All it would do is make fancy links in sysfs I think, who cares ;-)

quoted

quoted

quoted

Yeah, we're going to have a ton of them as well. Some of them are PCI
devices and have a clear parent, others, not so much :/

In a number of places the only thing we have is the PMU driver, and we don't
have a driver (or device) for the HW block it's a part of. Largely that's
interconnect PMUs; we could create container devices there.

Dont they have a PCI device? But yeah, some are going to be a wee bit
challenging.

The system might not even have PCI, so it's arguable that they should just hang
off an MMIO bus (which is effectively what the platofrm bus is).

You and your dodgy platforms :-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel