Re: [PATCH v2] Added perf functionality to mmdc driver

[Mark Rutland]

On Tue, Aug 16, 2016 at 08:40:08PM +, Zhengyu Shen wrote:
> > > > > + hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > > > > + HRTIMER_MODE_REL_PINNED);
> > > >
> > > > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do
> > > > you have similar HW issues?
> > > >
> > > > Is there no overflow interrupt?
> > >
> > > When overflow occurs, a register bit is set to one. There is no
> > > overflow interrupt which is why the timer is needed.
> > 
> > I see. Please have add comment in the driver explaining this, so that this 
> > is
> > obvious.
> > 
> > Does the counter itself wrap and continue counting, or does it saturate?
> > 
> > How have you tuned your polling period so as to avoid missing events in the
> > case of an overflow?
> > 
> > Thanks,
> > Mark.
> The counter wraps around once every ten seconds for total-cycles (which is 
> the 
> Fastest increasing counter). Polling is done every one second just to be safe.

Ok. It would be worth noting this with a comment next to either the
hrtimer handler or registration thereof.

I assume that on overflow the counter wraps rather than saturating?

Thanks,
Mark.

Re: [PATCH v2] Added perf functionality to mmdc driver

[Mark Rutland]

On Tue, Aug 16, 2016 at 08:40:08PM +, Zhengyu Shen wrote:
> > > > > + hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > > > > + HRTIMER_MODE_REL_PINNED);
> > > >
> > > > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do
> > > > you have similar HW issues?
> > > >
> > > > Is there no overflow interrupt?
> > >
> > > When overflow occurs, a register bit is set to one. There is no
> > > overflow interrupt which is why the timer is needed.
> > 
> > I see. Please have add comment in the driver explaining this, so that this 
> > is
> > obvious.
> > 
> > Does the counter itself wrap and continue counting, or does it saturate?
> > 
> > How have you tuned your polling period so as to avoid missing events in the
> > case of an overflow?
> > 
> > Thanks,
> > Mark.
> The counter wraps around once every ten seconds for total-cycles (which is 
> the 
> Fastest increasing counter). Polling is done every one second just to be safe.

Ok. It would be worth noting this with a comment next to either the
hrtimer handler or registration thereof.

I assume that on overflow the counter wraps rather than saturating?

Thanks,
Mark.

RE: [PATCH v2] Added perf functionality to mmdc driver

[Zhengyu Shen]

> > > > +   hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > > > +   HRTIMER_MODE_REL_PINNED);
> > >
> > > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do
> > > you have similar HW issues?
> > >
> > > Is there no overflow interrupt?
> >
> > When overflow occurs, a register bit is set to one. There is no
> > overflow interrupt which is why the timer is needed.
> 
> I see. Please have add comment in the driver explaining this, so that this is
> obvious.
> 
> Does the counter itself wrap and continue counting, or does it saturate?
> 
> How have you tuned your polling period so as to avoid missing events in the
> case of an overflow?
> 
> Thanks,
> Mark.
The counter wraps around once every ten seconds for total-cycles (which is the 
Fastest increasing counter). Polling is done every one second just to be safe.

RE: [PATCH v2] Added perf functionality to mmdc driver

[Zhengyu Shen]

> > > > +   hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > > > +   HRTIMER_MODE_REL_PINNED);
> > >
> > > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do
> > > you have similar HW issues?
> > >
> > > Is there no overflow interrupt?
> >
> > When overflow occurs, a register bit is set to one. There is no
> > overflow interrupt which is why the timer is needed.
> 
> I see. Please have add comment in the driver explaining this, so that this is
> obvious.
> 
> Does the counter itself wrap and continue counting, or does it saturate?
> 
> How have you tuned your polling period so as to avoid missing events in the
> case of an overflow?
> 
> Thanks,
> Mark.
The counter wraps around once every ten seconds for total-cycles (which is the 
Fastest increasing counter). Polling is done every one second just to be safe.

RE: [PATCH v2] Added perf functionality to mmdc driver

[Zhengyu Shen]

> > Added cpumask and migration handling support to driver
> > Validated event during event_init
> > Added code to properly stop counters
> > Used perf_invalid_context instead of perf_sw_context
> > Added hrtimer to poll for overflow
> > Added better description
> > Added support for multiple mmdcs
> 
> As I commented on v1 w.r.t. the above, I would appreciate being Cc'd on
> future versions of this patch.

Sorry about that, I'll be sure to CC you in the future. 

> > +static void mmdc_event_start(struct perf_event *event, int flags) {
> > +   struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> > +   void __iomem *mmdc_base, *reg;
> > +
> > +   local64_set(>count, 0);
> > +   mmdc_base = pmu_mmdc->mmdc_base;
> > +   reg = mmdc_base + MMDC_MADPCR0;
> > +   hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > +   HRTIMER_MODE_REL_PINNED);
> 
> Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do you
> have similar HW issues?
> 
> Is there no overflow interrupt?

When overflow occurs, a register bit is set to one. There is no overflow
interrupt which is why the timer is needed. 

Thanks a lot for the feedback!

RE: [PATCH v2] Added perf functionality to mmdc driver

[Zhengyu Shen]

> > Added cpumask and migration handling support to driver
> > Validated event during event_init
> > Added code to properly stop counters
> > Used perf_invalid_context instead of perf_sw_context
> > Added hrtimer to poll for overflow
> > Added better description
> > Added support for multiple mmdcs
> 
> As I commented on v1 w.r.t. the above, I would appreciate being Cc'd on
> future versions of this patch.

Sorry about that, I'll be sure to CC you in the future. 

> > +static void mmdc_event_start(struct perf_event *event, int flags) {
> > +   struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> > +   void __iomem *mmdc_base, *reg;
> > +
> > +   local64_set(>count, 0);
> > +   mmdc_base = pmu_mmdc->mmdc_base;
> > +   reg = mmdc_base + MMDC_MADPCR0;
> > +   hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > +   HRTIMER_MODE_REL_PINNED);
> 
> Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do you
> have similar HW issues?
> 
> Is there no overflow interrupt?

When overflow occurs, a register bit is set to one. There is no overflow
interrupt which is why the timer is needed. 

Thanks a lot for the feedback!

Re: [PATCH v2] Added perf functionality to mmdc driver

[Mark Rutland]

On Tue, Aug 16, 2016 at 02:40:43PM +, Zhengyu Shen wrote:
> > >   Added cpumask and migration handling support to driver
> > >   Validated event during event_init
> > >   Added code to properly stop counters
> > >   Used perf_invalid_context instead of perf_sw_context
> > >   Added hrtimer to poll for overflow
> > >   Added better description
> > >   Added support for multiple mmdcs
> > 
> > As I commented on v1 w.r.t. the above, I would appreciate being Cc'd on
> > future versions of this patch.
> 
> Sorry about that, I'll be sure to CC you in the future. 
> 
> > > +static void mmdc_event_start(struct perf_event *event, int flags) {
> > > + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> > > + void __iomem *mmdc_base, *reg;
> > > +
> > > + local64_set(>count, 0);
> > > + mmdc_base = pmu_mmdc->mmdc_base;
> > > + reg = mmdc_base + MMDC_MADPCR0;
> > > + hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > > + HRTIMER_MODE_REL_PINNED);
> > 
> > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do you
> > have similar HW issues?
> > 
> > Is there no overflow interrupt?
> 
> When overflow occurs, a register bit is set to one. There is no overflow
> interrupt which is why the timer is needed. 

I see. Please have add comment in the driver explaining this, so that this is
obvious.

Does the counter itself wrap and continue counting, or does it saturate?

How have you tuned your polling period so as to avoid missing events in the
case of an overflow?

Thanks,
Mark.

Re: [PATCH v2] Added perf functionality to mmdc driver

[Mark Rutland]

On Tue, Aug 16, 2016 at 02:40:43PM +, Zhengyu Shen wrote:
> > >   Added cpumask and migration handling support to driver
> > >   Validated event during event_init
> > >   Added code to properly stop counters
> > >   Used perf_invalid_context instead of perf_sw_context
> > >   Added hrtimer to poll for overflow
> > >   Added better description
> > >   Added support for multiple mmdcs
> > 
> > As I commented on v1 w.r.t. the above, I would appreciate being Cc'd on
> > future versions of this patch.
> 
> Sorry about that, I'll be sure to CC you in the future. 
> 
> > > +static void mmdc_event_start(struct perf_event *event, int flags) {
> > > + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> > > + void __iomem *mmdc_base, *reg;
> > > +
> > > + local64_set(>count, 0);
> > > + mmdc_base = pmu_mmdc->mmdc_base;
> > > + reg = mmdc_base + MMDC_MADPCR0;
> > > + hrtimer_start(_mmdc->hrtimer, mmdc_timer_period(),
> > > + HRTIMER_MODE_REL_PINNED);
> > 
> > Why is a hrtimer necessary? Is this just copy-pasted from CCN, or do you
> > have similar HW issues?
> > 
> > Is there no overflow interrupt?
> 
> When overflow occurs, a register bit is set to one. There is no overflow
> interrupt which is why the timer is needed. 

I see. Please have add comment in the driver explaining this, so that this is
obvious.

Does the counter itself wrap and continue counting, or does it saturate?

How have you tuned your polling period so as to avoid missing events in the
case of an overflow?

Thanks,
Mark.

Re: [PATCH v2] Added perf functionality to mmdc driver

[Peter Zijlstra]

On Mon, Aug 15, 2016 at 05:50:50PM +0100, Mark Rutland wrote:
> For the Nth time, I'm going to say that really, we should have the core check
> this (or expose helpers to do so). It's somewhat ridiculous that evry driver
> has to blacklist everything it doesn't support, rather than whitelisting the
> few things that it does.

I'll look at patches ;-)

Re: [PATCH v2] Added perf functionality to mmdc driver

[Peter Zijlstra]

On Mon, Aug 15, 2016 at 05:50:50PM +0100, Mark Rutland wrote:
> For the Nth time, I'm going to say that really, we should have the core check
> this (or expose helpers to do so). It's somewhat ridiculous that evry driver
> has to blacklist everything it doesn't support, rather than whitelisting the
> few things that it does.

I'll look at patches ;-)

Re: [PATCH v2] Added perf functionality to mmdc driver

[Mark Rutland]

Hi,

On Mon, Aug 15, 2016 at 05:30:35PM -0500, Zhengyu Shen wrote:
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64 and
> LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high 
> performance,
> and optimized. MMDC is present on i.MX6 Quad and i.MX6 QuadPlus devices, but
> this driver only supports i.MX6 Quad at the moment. MMDC provides registers
> for performance counters which read via this driver to help debug memory
> throughput and similar issues.
> 
> $ perf stat -a -e 
> mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/
>  dd if=/dev/zero of=/dev/null bs=1M count=5000
> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
> 
>  898021787  mmdc/busy-cycles/
>   14819600  mmdc/read-accesses/
> 471.30 MB   mmdc/read-bytes/
> 2815419216  mmdc/total-cycles/
>   13367354  mmdc/write-accesses/
> 427.76 MB   mmdc/write-bytes/
> 
>5.334757334 seconds time elapsed
> 
> Signed-off-by: Zhengyu Shen 
> ---
> change from v1 to v2:
>   Added cpumask and migration handling support to driver
>   Validated event during event_init
>   Added code to properly stop counters
>   Used perf_invalid_context instead of perf_sw_context
>   Added hrtimer to poll for overflow 
>   Added better description
>   Added support for multiple mmdcs

As I commented on v1 w.r.t. the above, I would appreciate being Cc'd on future
versions of this patch.

> +static u32 mmdc_read_counter(struct mmdc_pmu *pmu_mmdc, int cfg, u64 
> prev_val)
> +{
> + u32 val;
> + void __iomem *mmdc_base, *reg;
> + mmdc_base = pmu_mmdc->mmdc_base;
> +
> + switch (cfg)
> + {
> + case TOTAL_CYCLES:
> + reg = mmdc_base + MMDC_MADPSR0;
> + break;
> + case BUSY_CYCLES:
> + reg = mmdc_base + MMDC_MADPSR1;
> + break;
> + case READ_ACCESSES:
> + reg = mmdc_base + MMDC_MADPSR2;
> + break;
> + case WRITE_ACCESSES:
> + reg = mmdc_base + MMDC_MADPSR3;
> + break;
> + case READ_BYTES:
> + reg = mmdc_base + MMDC_MADPSR4;
> + break;
> + case WRITE_BYTES:
> + reg = mmdc_base + MMDC_MADPSR5;
> + break;
> + default:
> + return -1;

This is probably worth a WARN_ONCE, given this should never happen if things
are working correctly.

> +static int mmdc_cpu_notifier(struct notifier_block *nb,
> +unsigned long action, void *hcpu)
> +{
> + struct mmdc_pmu *pmu_mmdc = container_of(nb, struct mmdc_pmu, cpu_nb);
> + unsigned int cpu = (long)hcpu; /* for (long) see kernel/cpu.c */
> + unsigned int target;
> +
> + switch (action & ~CPU_TASKS_FROZEN) {
> + case CPU_DOWN_PREPARE:
> + if (!cpumask_test_and_clear_cpu(cpu, _mmdc->cpu))
> + break;
> + target = cpumask_any_but(cpu_online_mask, cpu);
> + if (target >= nr_cpu_ids)
> + break;
> + perf_pmu_migrate_context(_mmdc->pmu, cpu, target);
> + cpumask_set_cpu(target, _mmdc->cpu);
> + default:
> + break;
> +}
> +
> + return NOTIFY_OK;
> +}

CPU notifiers are being ripped out of the kernel with the new hotplug state
machine stuff. See [1] for examples.

> +static int mmdc_event_init(struct perf_event *event)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + if (event->attr.type != event->pmu->type)
> + return -ENOENT;
> +
> + if (event->cpu < 0) {
> + dev_warn(pmu_mmdc->dev, "Can't provide per-task data!\n");
> + return -EOPNOTSUPP;
> + }
> +
> + if (event->attr.exclude_user   ||
> + event->attr.exclude_kernel ||
> + event->attr.exclude_hv ||
> + event->attr.exclude_idle   ||
> + event->attr.exclude_host)
> + return -EINVAL;

Likewise for exclude_guest here.

You also need to reject sampling events.

You also need to sanity-check grouping.

For the Nth time, I'm going to say that really, we should have the core check
this (or expose helpers to do so). It's somewhat ridiculous that evry driver
has to blacklist everything it doesn't support, rather than whitelisting the
few things that it does.

> +
> + mmdc_enable_profiling(event);

This doesn't look right. Until we call add() we shouldn't have to poke HW.
event_init should just verify the veent and set up datastructures as required.

It would be better to count the number of active 

Re: [PATCH v2] Added perf functionality to mmdc driver

[Mark Rutland]

Hi,

On Mon, Aug 15, 2016 at 05:30:35PM -0500, Zhengyu Shen wrote:
> MMDC is a multi-mode DDR controller that supports DDR3/DDR3L x16/x32/x64 and
> LPDDR2 two channel x16/x32 memory types. MMDC is configurable, high 
> performance,
> and optimized. MMDC is present on i.MX6 Quad and i.MX6 QuadPlus devices, but
> this driver only supports i.MX6 Quad at the moment. MMDC provides registers
> for performance counters which read via this driver to help debug memory
> throughput and similar issues.
> 
> $ perf stat -a -e 
> mmdc/busy-cycles/,mmdc/read-accesses/,mmdc/read-bytes/,mmdc/total-cycles/,mmdc/write-accesses/,mmdc/write-bytes/
>  dd if=/dev/zero of=/dev/null bs=1M count=5000
> Performance counter stats for 'dd if=/dev/zero of=/dev/null bs=1M count=5000':
> 
>  898021787  mmdc/busy-cycles/
>   14819600  mmdc/read-accesses/
> 471.30 MB   mmdc/read-bytes/
> 2815419216  mmdc/total-cycles/
>   13367354  mmdc/write-accesses/
> 427.76 MB   mmdc/write-bytes/
> 
>5.334757334 seconds time elapsed
> 
> Signed-off-by: Zhengyu Shen 
> ---
> change from v1 to v2:
>   Added cpumask and migration handling support to driver
>   Validated event during event_init
>   Added code to properly stop counters
>   Used perf_invalid_context instead of perf_sw_context
>   Added hrtimer to poll for overflow 
>   Added better description
>   Added support for multiple mmdcs

As I commented on v1 w.r.t. the above, I would appreciate being Cc'd on future
versions of this patch.

> +static u32 mmdc_read_counter(struct mmdc_pmu *pmu_mmdc, int cfg, u64 
> prev_val)
> +{
> + u32 val;
> + void __iomem *mmdc_base, *reg;
> + mmdc_base = pmu_mmdc->mmdc_base;
> +
> + switch (cfg)
> + {
> + case TOTAL_CYCLES:
> + reg = mmdc_base + MMDC_MADPSR0;
> + break;
> + case BUSY_CYCLES:
> + reg = mmdc_base + MMDC_MADPSR1;
> + break;
> + case READ_ACCESSES:
> + reg = mmdc_base + MMDC_MADPSR2;
> + break;
> + case WRITE_ACCESSES:
> + reg = mmdc_base + MMDC_MADPSR3;
> + break;
> + case READ_BYTES:
> + reg = mmdc_base + MMDC_MADPSR4;
> + break;
> + case WRITE_BYTES:
> + reg = mmdc_base + MMDC_MADPSR5;
> + break;
> + default:
> + return -1;

This is probably worth a WARN_ONCE, given this should never happen if things
are working correctly.

> +static int mmdc_cpu_notifier(struct notifier_block *nb,
> +unsigned long action, void *hcpu)
> +{
> + struct mmdc_pmu *pmu_mmdc = container_of(nb, struct mmdc_pmu, cpu_nb);
> + unsigned int cpu = (long)hcpu; /* for (long) see kernel/cpu.c */
> + unsigned int target;
> +
> + switch (action & ~CPU_TASKS_FROZEN) {
> + case CPU_DOWN_PREPARE:
> + if (!cpumask_test_and_clear_cpu(cpu, _mmdc->cpu))
> + break;
> + target = cpumask_any_but(cpu_online_mask, cpu);
> + if (target >= nr_cpu_ids)
> + break;
> + perf_pmu_migrate_context(_mmdc->pmu, cpu, target);
> + cpumask_set_cpu(target, _mmdc->cpu);
> + default:
> + break;
> +}
> +
> + return NOTIFY_OK;
> +}

CPU notifiers are being ripped out of the kernel with the new hotplug state
machine stuff. See [1] for examples.

> +static int mmdc_event_init(struct perf_event *event)
> +{
> + struct mmdc_pmu *pmu_mmdc = to_mmdc_pmu(event->pmu);
> + if (event->attr.type != event->pmu->type)
> + return -ENOENT;
> +
> + if (event->cpu < 0) {
> + dev_warn(pmu_mmdc->dev, "Can't provide per-task data!\n");
> + return -EOPNOTSUPP;
> + }
> +
> + if (event->attr.exclude_user   ||
> + event->attr.exclude_kernel ||
> + event->attr.exclude_hv ||
> + event->attr.exclude_idle   ||
> + event->attr.exclude_host)
> + return -EINVAL;

Likewise for exclude_guest here.

You also need to reject sampling events.

You also need to sanity-check grouping.

For the Nth time, I'm going to say that really, we should have the core check
this (or expose helpers to do so). It's somewhat ridiculous that evry driver
has to blacklist everything it doesn't support, rather than whitelisting the
few things that it does.

> +
> + mmdc_enable_profiling(event);

This doesn't look right. Until we call add() we shouldn't have to poke HW.
event_init should just verify the veent and set up datastructures as required.

It would be better to count the number of active events and enable/disable 

Re: [PATCH v2] Added perf functionality to mmdc driver

[kbuild test robot]

Hi Zhengyu,

[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.8-rc2 next-20160815]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Zhengyu-Shen/Added-perf-functionality-to-mmdc-driver/20160816-063431
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   arch/arm/mach-imx/mmdc.c: In function 'mmdc_pmu_init':
>> arch/arm/mach-imx/mmdc.c:354:30: error: 'CPU_PRI_PERF' undeclared (first use 
>> in this function)
 pmu_mmdc->cpu_nb.priority = CPU_PRI_PERF + 1;
 ^
   arch/arm/mach-imx/mmdc.c:354:30: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/CPU_PRI_PERF +354 arch/arm/mach-imx/mmdc.c

   348  
   349  mmdc_num = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
   350  
   351  cpumask_set_cpu(smp_processor_id(), _mmdc->cpu);
   352  
   353  pmu_mmdc->cpu_nb.notifier_call = mmdc_cpu_notifier;
 > 354  pmu_mmdc->cpu_nb.priority = CPU_PRI_PERF + 1;
   355  
   356  pmu_mmdc->dev = dev;
   357  return mmdc_num;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH v2] Added perf functionality to mmdc driver

[kbuild test robot]

Hi Zhengyu,

[auto build test ERROR on shawnguo/for-next]
[also build test ERROR on v4.8-rc2 next-20160815]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Zhengyu-Shen/Added-perf-functionality-to-mmdc-driver/20160816-063431
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git 
for-next
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   arch/arm/mach-imx/mmdc.c: In function 'mmdc_pmu_init':
>> arch/arm/mach-imx/mmdc.c:354:30: error: 'CPU_PRI_PERF' undeclared (first use 
>> in this function)
 pmu_mmdc->cpu_nb.priority = CPU_PRI_PERF + 1;
 ^
   arch/arm/mach-imx/mmdc.c:354:30: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/CPU_PRI_PERF +354 arch/arm/mach-imx/mmdc.c

   348  
   349  mmdc_num = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
   350  
   351  cpumask_set_cpu(smp_processor_id(), _mmdc->cpu);
   352  
   353  pmu_mmdc->cpu_nb.notifier_call = mmdc_cpu_notifier;
 > 354  pmu_mmdc->cpu_nb.priority = CPU_PRI_PERF + 1;
   355  
   356  pmu_mmdc->dev = dev;
   357  return mmdc_num;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data