lkml.org 
[lkml]   [2018]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] arm: bcm2835: Add the PMU to the devicetree.
On Thu, 17 May 2018, Peter Zijlstra wrote:

> On Thu, May 17, 2018 at 06:55:26PM +0200, Stefan Wahren wrote:
> > > Vince Weaver <vincent.weaver@maine.edu> hat am 17. Mai 2018 um 18:34 geschrieben:
> > > On Thu, 17 May 2018, Stefan Wahren wrote:
> > > > > Eric Anholt <eric@anholt.net> hat am 17. Mai 2018 um 15:17 geschrieben:
>
> > > > > The a53 and a7 counters seem to match up, so we advertise a7 so that
> > > > > arm32 can probe.
> > >
> > > so how closely did you look at the a53/a7 differences? I see some major
> > > differences, especially with the CPU_CYCLES event (0xff vs 0x11).
> > >
> > > The proper fix here might be to add a cortex-a53 PMU entry to the armv7
> > > code rather than trying to treat it as a cortex-a7.
> >
> > we like to use the PMU of BCM2837 SoC (4x A53 cores) under arm32 and arm64.
> >
> > What is the right way (tm) to the define the DT compatibles?
> > Does the arm32 PMU driver need patching for proper A53 support?
>
> I'm completely clueless on all of this; Mark might have ideas.

Spending more time looking at it the only obvious differences are the
previously mentioned CYCLES difference, as well as the cortex-a7 has
18 events in the perf_cache_map but cortex-a53 only has 3. Plus probably
support for the various other features of the armv8v3 pmu that the a7
knows nothing about.

Is it hard to get lines in the DT changed once they are there? If we go
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?

Vince

\
 
 \ /
  Last update: 2018-05-17 20:27    [W:0.039 / U:0.424 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site