public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v13 01/20] ARM64: Move PMU register related defines to asm/perf_event.h
Date: Thu, 25 Feb 2016 10:48:18 +0000	[thread overview]
Message-ID: <20160225104818.GB12784@arm.com> (raw)
In-Reply-To: <56CE6098.8070001@huawei.com>

On Thu, Feb 25, 2016 at 10:02:00AM +0800, Shannon Zhao wrote:
> On 2016/2/25 1:52, Will Deacon wrote:
> > On Wed, Feb 24, 2016 at 01:08:21PM +0800, Shannon Zhao wrote:
> >> From: Shannon Zhao <shannon.zhao@linaro•org>
> >>
> >> To use the ARMv8 PMU related register defines from the KVM code, we move
> >> the relevant definitions to asm/perf_event.h header file and rename them
> >> with prefix ARMV8_PMU_.
> >>
> >> Signed-off-by: Anup Patel <anup.patel@linaro•org>
> >> Signed-off-by: Shannon Zhao <shannon.zhao@linaro•org>
> >> Acked-by: Marc Zyngier <marc.zyngier@arm•com>
> >> Reviewed-by: Andrew Jones <drjones@redhat•com>
> >> ---
> >>  arch/arm64/include/asm/perf_event.h | 35 +++++++++++++++++++
> >>  arch/arm64/kernel/perf_event.c      | 68 ++++++++++---------------------------
> >>  2 files changed, 52 insertions(+), 51 deletions(-)
> > 
> > Looks fine to me, but we're going to get some truly horrible conflicts
> > in -next.
> > 
> > I'm open to suggestions on the best way to handle this, but one way
> > would be:
> > 
> >   1. Duplicate all the #defines privately in KVM (queue via kvm tree)
> This way seems not proper I think.
> 
> >   2. Rebase this patch onto my perf/updates branch [1] (queue via me)
> While to this series, it really relies on the perf_event.h to compile
> and test, so maybe for KVM-ARM and KVM maintainers it's not proper.
> 
> >   3. Patch at -rc1 dropping the #defines from (1) and moving to the new
> >      perf_event.h stuff
> > 
> I vote for this way. Since the patch in [1] is small and nothing else
> relies on them, I think it would be simple to rebase them onto this series.

That was supposed to be a sequence of actions... :/

> > Thoughts?
> > 
> Anyway, there are only 3 lines which have conflicts. I'm not sure
> whether we could handle this when we merge them.

I think we're looking at different conflicts. I resolved it (see below),
but I'd really rather this didn't happen at the point where perf/updates
hits kvm-arm (i.e. torvalds).

Will

--->8

diff --cc arch/arm64/kernel/perf_event.c
index 1cc61fc321d9,212c9fc44141..000000000000
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@@ -776,11 -684,8 +741,12 @@@ static void armv8pmu_reset(void *info
                armv8pmu_disable_intens(idx);
        }
  
 -      /* Initialize & Reset PMNC: C and P bits. */
 -      armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C);
 +      /*
 +       * Initialize & Reset PMNC. Request overflow interrupt for
 +       * 64 bit cycle counter but cheat in armv8pmu_write_counter().
 +       */
-       armv8pmu_pmcr_write(ARMV8_PMCR_P | ARMV8_PMCR_C | ARMV8_PMCR_LC);
++      armv8pmu_pmcr_write(ARMV8_PMU_PMCR_P | ARMV8_PMU_PMCR_C |
++                          ARMV8_PMU_PMCR_LC);
  }
  
  static int armv8_pmuv3_map_event(struct perf_event *event)
@@@ -801,16 -706,9 +767,16 @@@ static int armv8_a57_map_event(struct p
  {
        return armpmu_map_event(event, &armv8_a57_perf_map,
                                &armv8_a57_perf_cache_map,
-                               ARMV8_EVTYPE_EVENT);
+                               ARMV8_PMU_EVTYPE_EVENT);
  }
  
 +static int armv8_thunder_map_event(struct perf_event *event)
 +{
 +      return armpmu_map_event(event, &armv8_thunder_perf_map,
 +                              &armv8_thunder_perf_cache_map,
-                               ARMV8_EVTYPE_EVENT);
++                              ARMV8_PMU_EVTYPE_EVENT);
 +}
 +
  static void armv8pmu_read_num_pmnc_events(void *info)
  {
        int *nb_cnt = info;
diff --git a/arch/arm64/include/asm/perf_event.h b/arch/arm64/include/asm/perf_event.h
index 5c77ef8bf5b5..152ad9cb9bb0 100644
--- a/arch/arm64/include/asm/perf_event.h
+++ b/arch/arm64/include/asm/perf_event.h
@@ -29,6 +29,7 @@
 #define ARMV8_PMU_PMCR_D       (1 << 3) /* CCNT counts every 64th cpu cycle */
 #define ARMV8_PMU_PMCR_X       (1 << 4) /* Export to ETM */
 #define ARMV8_PMU_PMCR_DP      (1 << 5) /* Disable CCNT if non-invasive debug*/
+#define ARMV8_PMU_PMCR_LC      (1 << 6) /* Overflow on 64 bit cycle counter */
 #define        ARMV8_PMU_PMCR_N_SHIFT  11       /* Number of counters supported */
 #define        ARMV8_PMU_PMCR_N_MASK   0x1f
 #define        ARMV8_PMU_PMCR_MASK     0x3f     /* Mask for writable bits */
@@ -42,8 +43,8 @@
 /*
  * PMXEVTYPER: Event selection reg
  */
-#define        ARMV8_PMU_EVTYPE_MASK   0xc80003ff      /* Mask for writable bits */
-#define        ARMV8_PMU_EVTYPE_EVENT  0x3ff           /* Mask for EVENT bits */
+#define        ARMV8_PMU_EVTYPE_MASK   0xc800ffff      /* Mask for writable bits */
+#define        ARMV8_PMU_EVTYPE_EVENT  0xffff          /* Mask for EVENT bits */
 
 /*
  * Event filters for PMUv3

  reply	other threads:[~2016-02-25 10:48 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  5:08 [PATCH v13 00/20] KVM: ARM64: Add guest PMU support Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 01/20] ARM64: Move PMU register related defines to asm/perf_event.h Shannon Zhao
2016-02-24 17:52   ` Will Deacon
2016-02-25  2:02     ` Shannon Zhao
2016-02-25 10:48       ` Will Deacon [this message]
2016-02-29 13:07       ` Marc Zyngier
2016-02-29 13:59         ` Marc Zyngier
2016-02-29 15:41           ` Will Deacon
2016-02-29 15:53             ` Marc Zyngier
2016-02-29 15:43         ` Will Deacon
2016-02-29 18:50         ` Shannon Zhao
2016-02-29 19:03           ` Marc Zyngier
2016-02-24  5:08 ` [PATCH v13 02/20] KVM: ARM64: Define PMU data structure for each vcpu Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 03/20] KVM: ARM64: Add access handler for PMCR register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 04/20] KVM: ARM64: Add access handler for PMSELR register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 05/20] KVM: ARM64: Add access handler for PMCEID0 and PMCEID1 register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 06/20] KVM: ARM64: Add access handler for event counter register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 07/20] KVM: ARM64: Add access handler for PMCNTENSET and PMCNTENCLR register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 08/20] KVM: ARM64: PMU: Add perf event map and introduce perf event creating function Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 09/20] KVM: ARM64: Add access handler for event type register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 10/20] KVM: ARM64: Add access handler for PMINTENSET and PMINTENCLR register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 11/20] KVM: ARM64: Add access handler for PMOVSSET and PMOVSCLR register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 12/20] KVM: ARM64: Add access handler for PMSWINC register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 13/20] KVM: ARM64: Add helper to handle PMCR register bits Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 14/20] KVM: ARM64: Add access handler for PMUSERENR register Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 15/20] KVM: ARM64: Add PMU overflow interrupt routing Shannon Zhao
2016-02-24 12:27   ` Christoffer Dall
2016-02-24 13:19     ` Marc Zyngier
2016-02-24 13:26       ` Shannon Zhao
2016-02-24 13:42         ` Marc Zyngier
2016-02-24 14:33   ` [PATCH v14 " Shannon Zhao
2016-02-26  8:52     ` Christoffer Dall
2016-02-26 11:29     ` [PATCH v15 " Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 16/20] KVM: ARM64: Reset PMU state when resetting vcpu Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 17/20] KVM: ARM64: Free perf event of PMU when destroying vcpu Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 18/20] KVM: ARM64: Add a new feature bit for PMUv3 Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 19/20] KVM: ARM: Introduce per-vcpu kvm device controls Shannon Zhao
2016-02-24  5:08 ` [PATCH v13 20/20] KVM: ARM64: Add a new vcpu device control group for PMUv3 Shannon Zhao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160225104818.GB12784@arm.com \
    --to=will.deacon@arm$(echo .)com \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox