Hi
Thanks for taking a look at this..
On 09/16/2016 08:29 AM, Will Deacon wrote:
On Wed, Sep 14, 2016 at 05:32:35PM -0500, Jeremy Linton wrote:
On systems with multiple PMU types the PMU to CPU affinity
needs to be detected and set. The CPU to interrupt affinity
should also be set.
(trimming)
continue;
ret = info->init(pmu);
+ /*
+ * if this pmu declaration is unspecified and we have
+ * previously found a PMU on this platform then append
+ * a PMU number to the pmu name. This avoids changing
+ * the names of PMUs that are specific to a class of CPUs.
+ * The assumption is that if we match a specific PMU in the
+ * provided pmu_probe_info then it's unique, and another PMU
+ * in the system will match a different entry rather than
+ * needing the _number to assure its unique.
+ */
+ if ((!info->cpuid) && (duplicate_pmus)) {
Hmm, the duplicate_pmus check looks a little odd here. Doesn't it mean
that you'd end up with things like:
"arm,armv8-pmuv3"
"arm,armv8-pmuv3_1"
which looks needlessly fiddly to parse. Is this intentional?
Well, IIRC, you recommend that format, or maybe I misunderstood. Anyway,
per the comment I'm trying to assure that legacy platform devices don't
accidentally get a "_X" appended to their name and break something.
Further, by itself the name itself doesn't have any meaning/ordering and
could just as well be a random string. So, I don't think anyone is going
to try and parse it except to compare it as a whole something like
"armv8_cortex_a53". Which is why the cpu affinity is required.
Additionally, doing it this way allows a tiny tweak to the pmu table in
the future to re-enable meaningful PMU names. Lastly, its big.little
exclusive, so I would rather apply pain to non-existant big.little
server machines, than uglify the common case.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
