ARM: perf: Support i.MX53
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/4] ARM: perf: Support i.MX53
Quoted 7 lines · Martin Fuzzey
Quoted 2 lines · Will Deacon
Instead, how about we add a new property on the PMU node that says it requires secure access, then we use that to configuer SDER in the perf code.
Ok but how would the new property be used?
Do you just mean making the code that sets the SUNIDEN bit conditional on this property?
We'd add a property to the PMU, so it would look something like:
pmu {
compatible = "arm,cortex-a8-pmu";
interrupts = < ... >;
secure-reg-access;
};Then we can match that last property in the driver and only configure the SDER if it's present.
Quoted 2 lines
So a DT for a board booting in secure mode would have the property set and one booting in non secure mode would not?
Yes. It's also slightly more general in that you can set the property for any PMU that requires SDER configuration. In practice, that probable means `booted in secure mode' but you never know what people build.
Quoted 1 line
But is it the DT's business to know how the kernel has been booted?
I don't have an alternative other than only supporting perf in non-secure mode.
Quoted 1 line
What happens in non secure mode?
Exactly the same as what happens now; the property would be absent so existing behaviour would be preserved.
Quoted 3 lines
I presume the kernel won't touch SDER in that case (so avoiding an exception) but the counters will only work if code outside the kernel (bootloader, secure monitor?) has already set things up correctly?
Right. Secure software could restrict non-secure debug visibility, but that's not something Linux can do anything about.
Quoted 3 lines
Wouldn't it be possible to detect if the kernel is in secure mode and use that instead of a DT property?
Does the kernel have that information?
No, you can't reliably detect that in the architecture.
Quoted 7 lines
Quoted 2 lines
Then you can do your SoC-specific magic as part of the runtime PM hooks we already have (it looks like enabled/disabling a clock really).
This is orthogonal to the above right?
Indeed, I've tried that and it works without any extra hooks.
But what happens if we don't have
CONFIG_PM_RUNTIME?
Then you don't get perf unless you configure things correctly in your firmware. This is just like configuring clocks.
Will