Message ID | 6dbd695863346bda1e5d2133643ffade6227bd9a.1582300927.git.robin.murphy@arm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | arm64 CPU DT binding updates | expand |
On Fri, Feb 21, 2020 at 04:04:58PM +0000, Robin Murphy wrote: > Add support for matching the new PMUs. For now, this just wires them up > as generic PMUv3 such that people writing DTs for new SoCs can do the > right thing, and at least have architectural and raw events be usable. > We can come back and fill in event maps for sysfs and/or perf tools at > a later date. > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> Thanks for this, it looks fine to me: Acked-by: Mark Rutland <mark.rutland@arm.com> Mark. > --- > arch/arm64/kernel/perf_event.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c > index e40b65645c86..28ce582e049e 100644 > --- a/arch/arm64/kernel/perf_event.c > +++ b/arch/arm64/kernel/perf_event.c > @@ -1105,11 +1105,19 @@ static int armv8_vulcan_pmu_init(struct arm_pmu *cpu_pmu) > > static const struct of_device_id armv8_pmu_of_device_ids[] = { > {.compatible = "arm,armv8-pmuv3", .data = armv8_pmuv3_init}, > + {.compatible = "arm,cortex-a34-pmu", .data = armv8_pmuv3_init}, > {.compatible = "arm,cortex-a35-pmu", .data = armv8_a35_pmu_init}, > {.compatible = "arm,cortex-a53-pmu", .data = armv8_a53_pmu_init}, > + {.compatible = "arm,cortex-a55-pmu", .data = armv8_pmuv3_init}, > {.compatible = "arm,cortex-a57-pmu", .data = armv8_a57_pmu_init}, > + {.compatible = "arm,cortex-a65-pmu", .data = armv8_pmuv3_init}, > {.compatible = "arm,cortex-a72-pmu", .data = armv8_a72_pmu_init}, > {.compatible = "arm,cortex-a73-pmu", .data = armv8_a73_pmu_init}, > + {.compatible = "arm,cortex-a75-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,cortex-a76-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,cortex-a77-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,neoverse-e1-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,neoverse-n1-pmu", .data = armv8_pmuv3_init}, > {.compatible = "cavium,thunder-pmu", .data = armv8_thunder_pmu_init}, > {.compatible = "brcm,vulcan-pmu", .data = armv8_vulcan_pmu_init}, > {}, > -- > 2.23.0.dirty >
On Fri, 21 Feb 2020 16:04:58 +0000 Robin Murphy <robin.murphy@arm.com> wrote: Hi, > Add support for matching the new PMUs. For now, this just wires them up > as generic PMUv3 such that people writing DTs for new SoCs can do the > right thing, and at least have architectural and raw events be usable. > We can come back and fill in event maps for sysfs and/or perf tools at > a later date. as mentioned already in a reply to another patch: Is that really the right way? Isn't that calling for the intended usage of a compatible fall-back string? So that a machine can just ship DTBs with for instance: "arm,neoverse-n1-pmu", "arm,armv8-pmuv3"; and that would magically work with all older and newer kernels already, without any patch? As it stands right now (with a single compatible), only newer kernels could use the PMU on those SoCs (ignoring tedious backports not reaching every user). All that would be needed for that is to officially allow two compatible strings in the binding. Cheers, Andre. P.S. Still thinking about dropping those compatible strings at all and using the MIDR somehow, because then also ACPI users would benefit from core specific events. > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > --- > arch/arm64/kernel/perf_event.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c > index e40b65645c86..28ce582e049e 100644 > --- a/arch/arm64/kernel/perf_event.c > +++ b/arch/arm64/kernel/perf_event.c > @@ -1105,11 +1105,19 @@ static int armv8_vulcan_pmu_init(struct arm_pmu *cpu_pmu) > > static const struct of_device_id armv8_pmu_of_device_ids[] = { > {.compatible = "arm,armv8-pmuv3", .data = armv8_pmuv3_init}, > + {.compatible = "arm,cortex-a34-pmu", .data = armv8_pmuv3_init}, > {.compatible = "arm,cortex-a35-pmu", .data = armv8_a35_pmu_init}, > {.compatible = "arm,cortex-a53-pmu", .data = armv8_a53_pmu_init}, > + {.compatible = "arm,cortex-a55-pmu", .data = armv8_pmuv3_init}, > {.compatible = "arm,cortex-a57-pmu", .data = armv8_a57_pmu_init}, > + {.compatible = "arm,cortex-a65-pmu", .data = armv8_pmuv3_init}, > {.compatible = "arm,cortex-a72-pmu", .data = armv8_a72_pmu_init}, > {.compatible = "arm,cortex-a73-pmu", .data = armv8_a73_pmu_init}, > + {.compatible = "arm,cortex-a75-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,cortex-a76-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,cortex-a77-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,neoverse-e1-pmu", .data = armv8_pmuv3_init}, > + {.compatible = "arm,neoverse-n1-pmu", .data = armv8_pmuv3_init}, > {.compatible = "cavium,thunder-pmu", .data = armv8_thunder_pmu_init}, > {.compatible = "brcm,vulcan-pmu", .data = armv8_vulcan_pmu_init}, > {},
On Fri, Feb 21, 2020 at 05:15:59PM +0000, Mark Rutland wrote: > On Fri, Feb 21, 2020 at 04:04:58PM +0000, Robin Murphy wrote: > > Add support for matching the new PMUs. For now, this just wires them up > > as generic PMUv3 such that people writing DTs for new SoCs can do the > > right thing, and at least have architectural and raw events be usable. > > We can come back and fill in event maps for sysfs and/or perf tools at > > a later date. > > > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > > Thanks for this, it looks fine to me: > > Acked-by: Mark Rutland <mark.rutland@arm.com> Argh, this isn't quite right, sorry. :/ > > --- > > arch/arm64/kernel/perf_event.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c > > index e40b65645c86..28ce582e049e 100644 > > --- a/arch/arm64/kernel/perf_event.c > > +++ b/arch/arm64/kernel/perf_event.c > > @@ -1105,11 +1105,19 @@ static int armv8_vulcan_pmu_init(struct arm_pmu *cpu_pmu) > > > > static const struct of_device_id armv8_pmu_of_device_ids[] = { > > {.compatible = "arm,armv8-pmuv3", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,cortex-a34-pmu", .data = armv8_pmuv3_init}, Unfortunately, these need their own .data so that they can be given appropriate names under sysfs. We're stuck doing that forever for DT, though at least we learned for ACPI... Mark. > > {.compatible = "arm,cortex-a35-pmu", .data = armv8_a35_pmu_init}, > > {.compatible = "arm,cortex-a53-pmu", .data = armv8_a53_pmu_init}, > > + {.compatible = "arm,cortex-a55-pmu", .data = armv8_pmuv3_init}, > > {.compatible = "arm,cortex-a57-pmu", .data = armv8_a57_pmu_init}, > > + {.compatible = "arm,cortex-a65-pmu", .data = armv8_pmuv3_init}, > > {.compatible = "arm,cortex-a72-pmu", .data = armv8_a72_pmu_init}, > > {.compatible = "arm,cortex-a73-pmu", .data = armv8_a73_pmu_init}, > > + {.compatible = "arm,cortex-a75-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,cortex-a76-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,cortex-a77-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,neoverse-e1-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,neoverse-n1-pmu", .data = armv8_pmuv3_init}, > > {.compatible = "cavium,thunder-pmu", .data = armv8_thunder_pmu_init}, > > {.compatible = "brcm,vulcan-pmu", .data = armv8_vulcan_pmu_init}, > > {}, > > -- > > 2.23.0.dirty > >
On Fri, Feb 21, 2020 at 05:38:47PM +0000, Andre Przywara wrote: > On Fri, 21 Feb 2020 16:04:58 +0000 > Robin Murphy <robin.murphy@arm.com> wrote: > > Hi, > > > Add support for matching the new PMUs. For now, this just wires them up > > as generic PMUv3 such that people writing DTs for new SoCs can do the > > right thing, and at least have architectural and raw events be usable. > > We can come back and fill in event maps for sysfs and/or perf tools at > > a later date. > > as mentioned already in a reply to another patch: > > Is that really the right way? Isn't that calling for the intended usage of a compatible fall-back string? > So that a machine can just ship DTBs with for instance: > "arm,neoverse-n1-pmu", "arm,armv8-pmuv3"; > and that would magically work with all older and newer kernels already, without any patch? > > As it stands right now (with a single compatible), only newer kernels could use the PMU on those SoCs (ignoring tedious backports not reaching every user). > > All that would be needed for that is to officially allow two compatible strings in the binding. > > Cheers, > Andre. > > P.S. Still thinking about dropping those compatible strings at all and using the MIDR somehow, because then also ACPI users would benefit from core specific events. For ACPI we've said that the way forward is the userspace mappings, so that's already solved (and to a much greater degree than we could do within the kernel). The names for DT are an unfortunate legacy thing that we simply have to carry on with going forward in for the UAPI under sysfs. I don't want to go mapping MIDRs to names, and open other worm cans. Thanksm Mark. > > > Signed-off-by: Robin Murphy <robin.murphy@arm.com> > > --- > > arch/arm64/kernel/perf_event.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c > > index e40b65645c86..28ce582e049e 100644 > > --- a/arch/arm64/kernel/perf_event.c > > +++ b/arch/arm64/kernel/perf_event.c > > @@ -1105,11 +1105,19 @@ static int armv8_vulcan_pmu_init(struct arm_pmu *cpu_pmu) > > > > static const struct of_device_id armv8_pmu_of_device_ids[] = { > > {.compatible = "arm,armv8-pmuv3", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,cortex-a34-pmu", .data = armv8_pmuv3_init}, > > {.compatible = "arm,cortex-a35-pmu", .data = armv8_a35_pmu_init}, > > {.compatible = "arm,cortex-a53-pmu", .data = armv8_a53_pmu_init}, > > + {.compatible = "arm,cortex-a55-pmu", .data = armv8_pmuv3_init}, > > {.compatible = "arm,cortex-a57-pmu", .data = armv8_a57_pmu_init}, > > + {.compatible = "arm,cortex-a65-pmu", .data = armv8_pmuv3_init}, > > {.compatible = "arm,cortex-a72-pmu", .data = armv8_a72_pmu_init}, > > {.compatible = "arm,cortex-a73-pmu", .data = armv8_a73_pmu_init}, > > + {.compatible = "arm,cortex-a75-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,cortex-a76-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,cortex-a77-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,neoverse-e1-pmu", .data = armv8_pmuv3_init}, > > + {.compatible = "arm,neoverse-n1-pmu", .data = armv8_pmuv3_init}, > > {.compatible = "cavium,thunder-pmu", .data = armv8_thunder_pmu_init}, > > {.compatible = "brcm,vulcan-pmu", .data = armv8_vulcan_pmu_init}, > > {}, >
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c index e40b65645c86..28ce582e049e 100644 --- a/arch/arm64/kernel/perf_event.c +++ b/arch/arm64/kernel/perf_event.c @@ -1105,11 +1105,19 @@ static int armv8_vulcan_pmu_init(struct arm_pmu *cpu_pmu) static const struct of_device_id armv8_pmu_of_device_ids[] = { {.compatible = "arm,armv8-pmuv3", .data = armv8_pmuv3_init}, + {.compatible = "arm,cortex-a34-pmu", .data = armv8_pmuv3_init}, {.compatible = "arm,cortex-a35-pmu", .data = armv8_a35_pmu_init}, {.compatible = "arm,cortex-a53-pmu", .data = armv8_a53_pmu_init}, + {.compatible = "arm,cortex-a55-pmu", .data = armv8_pmuv3_init}, {.compatible = "arm,cortex-a57-pmu", .data = armv8_a57_pmu_init}, + {.compatible = "arm,cortex-a65-pmu", .data = armv8_pmuv3_init}, {.compatible = "arm,cortex-a72-pmu", .data = armv8_a72_pmu_init}, {.compatible = "arm,cortex-a73-pmu", .data = armv8_a73_pmu_init}, + {.compatible = "arm,cortex-a75-pmu", .data = armv8_pmuv3_init}, + {.compatible = "arm,cortex-a76-pmu", .data = armv8_pmuv3_init}, + {.compatible = "arm,cortex-a77-pmu", .data = armv8_pmuv3_init}, + {.compatible = "arm,neoverse-e1-pmu", .data = armv8_pmuv3_init}, + {.compatible = "arm,neoverse-n1-pmu", .data = armv8_pmuv3_init}, {.compatible = "cavium,thunder-pmu", .data = armv8_thunder_pmu_init}, {.compatible = "brcm,vulcan-pmu", .data = armv8_vulcan_pmu_init}, {},
Add support for matching the new PMUs. For now, this just wires them up as generic PMUv3 such that people writing DTs for new SoCs can do the right thing, and at least have architectural and raw events be usable. We can come back and fill in event maps for sysfs and/or perf tools at a later date. Signed-off-by: Robin Murphy <robin.murphy@arm.com> --- arch/arm64/kernel/perf_event.c | 8 ++++++++ 1 file changed, 8 insertions(+)