Re: [PATCH] arm: bcm2835: Add the PMU to the devicetree.

[Marc Zyngier <marc.zyngier@arm.com>]

On 17/05/18 20:59, Florian Fainelli wrote:
> On 05/17/2018 12:31 PM, Vince Weaver wrote:
>> On Thu, 17 May 2018, Vince Weaver wrote:
>>
>>> On Thu, 17 May 2018, Peter Zijlstra wrote:
>>> with cortex-a7 now, would it be possible to later drop that if proper 
>>> cortex-a53 support is added to the armv7 pmu driver?  Or would that lead 
>>> to all kinds of back-compatability mess?
>>
>> For what it's worth, the pi-foundation kernel bcm2710 device tree file 
>> does:
>>
>> 		arm-pmu {
>> #ifdef RPI364
>> 			compatible = "arm,armv8-pmuv3", "arm,cortex-a7-pmu";

Hahaha. Funny that. Not. That's really silly. The DT *must* describe the
HW, and having contradictory information is not helping. This is going
to lead to all kind of miscounted events (to take the above example) A7
and A53 are significantly different, and thus will count events
differently....


>> #else
>> 			compatible = "arm,cortex-a7-pmu";
>> #endif
>> 			interrupt-parent = <&local_intc>;
>> 			interrupts = <9>;
>> 		};
>>
>>
>> Which is probably where I was getting the arm,armv8-pmuv3 from in my 
>> original patch.
> 
> I thought somehow that Marc Z. had unified
> arch/arm/kernel/perf_event_v7.c and arch/arm64/kernel/perf_event.c into
> a common driver entry point under drivers/perf/arm_pmu.c but I don't see
> it and after about 15 minutes looking at it, it does not look as trivial
> as I though to separate out those files so the ARMv8 PMU description can
> be moved into a generic location for instance.

I have a pretty simple series[1] which I used to profile 32bit guests on
an arm64 KVM host. Nobody really cared about it because running a 32bit
kernel on 64bit HW is a bit odd, to say the least, and I'm probably the
only one actually running 32bit VMs.

> FWIW, Broadcom STB chips, even when 64-bit capable or often used with an
> 32-bit ARM kernel, so having the ARMv8 PMUs work under a 32-bit ARM
> kernel would be great. The downstream solution we have sued thus far is
> to find the closest compatible string to represent those, which is not
> great...
Ah, so you're *really* doing that? I'm not going to ask why, I'm scared
of the answer... ;-)

Anyway, I can repost that series if that will prevent people from having
that kind of silly hacks.

Thanks,

	M.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm/pmuv3-32bit
-- 
Jazz is not dead. It just smells funny...