On Thu, Oct 15, 2015 at 08:15:06AM -0700, Drew Richardson wrote:
> On Thu, Oct 15, 2015 at 02:21:12PM +0100, Will Deacon wrote:
> > On Tue, Oct 13, 2015 at 08:36:45AM -0700, Drew Richardson wrote:
> > > Add additional information about the ARM architected hardware events
> > > to make counters self describing. This makes the hardware PMUs easier
> > > to use as perf list contains possible events instead of users having
> > > to refer to documentation like the ARM TRMs.
> > >
> > > Signed-off-by: Drew Richardson <drew.richard...@arm.com>
> > > ---
> > > arch/arm/kernel/perf_event_v7.c | 121
> > > ++++++++++++++++++++++++++++++++++++++++
> > > drivers/perf/arm_pmu.c | 1 +
> > > 2 files changed, 122 insertions(+)
> >
> > [...]
> >
> > > diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
> > > index 2365a32a595e..e933d2dd71c0 100644
> > > --- a/drivers/perf/arm_pmu.c
> > > +++ b/drivers/perf/arm_pmu.c
> > > @@ -548,6 +548,7 @@ static void armpmu_init(struct arm_pmu *armpmu)
> > > .stop = armpmu_stop,
> > > .read = armpmu_read,
> > > .filter_match = armpmu_filter_match,
> > > + .attr_groups = armpmu->pmu.attr_groups,
> >
> > I don't understand this hunk. What's it doing?
>
> I'm not 100% clear either on what it's doing. But without this line
> the attr_groups don't get passed on and I don't see them on my TC2. I
> debugged the issue down to this but it may not be the proper way to
> solve the problem.
Oh yuck, it's because we call armpmu_init after cpu_pmu_init and the former
uses struct initialisation and ends up zeroing anything set previously.
We should probably tidy all this up:
* Remove armpmu_register and call perf_pmu_register directly from
arm_pmu_device_probe instead
* Call armpmu_init immediately prior to arm_cpu_init
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
