On Wed, May 07, 2014 at 10:21:52PM +0100, Vince Weaver wrote:
> On Wed, 7 May 2014, Will Deacon wrote:
>
> > > OK, let me revisit the patches. The last set of generic ones I sent out
> > > actually was broken on ARM and I've been meaning to straighten things out
> > > and send a proper follow u
On Wed, 7 May 2014, Will Deacon wrote:
> > OK, let me revisit the patches. The last set of generic ones I sent out
> > actually was broken on ARM and I've been meaning to straighten things out
> > and send a proper follow up patch set but got distracted by other perf
> > related issues.
>
> A
Hi Vince,
On Mon, Feb 24, 2014 at 03:37:11PM +, Vince Weaver wrote:
> On Mon, 24 Feb 2014, Will Deacon wrote:
> > On Fri, Jan 17, 2014 at 05:45:04AM +, Vince Weaver wrote:
> > > On Thu, 16 Jan 2014, Peter Zijlstra wrote:
> > >
> > > > Yeah I suppose we could do something like that. Maybe
On Mon, 24 Feb 2014, Will Deacon wrote:
> On Fri, Jan 17, 2014 at 05:45:04AM +, Vince Weaver wrote:
> > On Thu, 16 Jan 2014, Peter Zijlstra wrote:
> >
> > > Yeah I suppose we could do something like that. Maybe something like:
> > >
> > > # cat /sys/bus/event_source/devices/cpu/flags
> > > i
Hi Vince,
On Fri, Jan 17, 2014 at 05:45:04AM +, Vince Weaver wrote:
> On Thu, 16 Jan 2014, Peter Zijlstra wrote:
>
> > Yeah I suppose we could do something like that. Maybe something like:
> >
> > # cat /sys/bus/event_source/devices/cpu/flags
> > int precise filter
>
> wouldn't that violate
On Thu, 16 Jan 2014, Peter Zijlstra wrote:
> Yeah I suppose we could do something like that. Maybe something like:
>
> # cat /sys/bus/event_source/devices/cpu/flags
> int precise filter
wouldn't that violate the "one value per file" rule?
I guess we could also stick it in the mmap page somewher
On Thu, Jan 16, 2014 at 12:13:10PM -0500, Vince Weaver wrote:
> On Tue, 14 Jan 2014, Peter Zijlstra wrote:
>
> > On Mon, Jan 13, 2014 at 11:55:17PM -0500, Vince Weaver wrote:
>
> > > I don't see an existing pmu capabilities struct... or do you mean
> > > coming up with one?
> >
> > Yeah, adding
On Tue, 14 Jan 2014, Peter Zijlstra wrote:
> On Mon, Jan 13, 2014 at 11:55:17PM -0500, Vince Weaver wrote:
> > I don't see an existing pmu capabilities struct... or do you mean
> > coming up with one?
>
> Yeah, adding one.
So would it be a struct, or just an integer with flags?
> > Would it on
On Wed, 15 Jan 2014, Will Deacon wrote:
> Hi Vince,
>
> On Tue, Jan 14, 2014 at 04:42:13AM +, Vince Weaver wrote:
> > On Fri, 10 Jan 2014, Will Deacon wrote:
> > > In the absence of a core change, I think I'd rather have something like
> > > your
> > > second patch, but without the extra no_
Hi Vince,
On Tue, Jan 14, 2014 at 04:42:13AM +, Vince Weaver wrote:
> On Fri, 10 Jan 2014, Will Deacon wrote:
> > In the absence of a core change, I think I'd rather have something like your
> > second patch, but without the extra no_overflow_irq field (you can check the
> > platform device, a
On Mon, Jan 13, 2014 at 11:55:17PM -0500, Vince Weaver wrote:
> On Fri, 10 Jan 2014, Peter Zijlstra wrote:
>
> > On Thu, Jan 09, 2014 at 11:08:47PM -0500, Vince Weaver wrote:
> > > On Thu, 9 Jan 2014, Will Deacon wrote:
> > >
> > > > I'd rather see it in the generic code if at all possible. Maybe
On Fri, 10 Jan 2014, Peter Zijlstra wrote:
> On Thu, Jan 09, 2014 at 11:08:47PM -0500, Vince Weaver wrote:
> > On Thu, 9 Jan 2014, Will Deacon wrote:
> >
> > > I'd rather see it in the generic code if at all possible. Maybe we could
> > > add
> > > a flags field to perf_pmu_register?
> >
> > I
On Fri, 10 Jan 2014, Will Deacon wrote:
> In the absence of a core change, I think I'd rather have something like your
> second patch, but without the extra no_overflow_irq field (you can check the
> platform device, as I mentioned previously).
Something like the following? It works on my rasp-p
On Fri, 10 Jan 2014, Stephane Eranian wrote:
> But before we do that, can someone confirm that on Pi there is simply
> no interrupt
> generated by the PMU or is it that we don't know how to route it back?
The closest I've seen is this posting from one of the rasp-pi employees
who presumably has
On Fri, Jan 10, 2014 at 11:08 AM, Will Deacon wrote:
> On Fri, Jan 10, 2014 at 04:08:47AM +, Vince Weaver wrote:
>> On Thu, 9 Jan 2014, Will Deacon wrote:
>>
>> > I'd rather see it in the generic code if at all possible. Maybe we could
>> > add
>> > a flags field to perf_pmu_register?
>>
>> I
On Fri, Jan 10, 2014 at 04:08:47AM +, Vince Weaver wrote:
> On Thu, 9 Jan 2014, Will Deacon wrote:
>
> > I'd rather see it in the generic code if at all possible. Maybe we could add
> > a flags field to perf_pmu_register?
>
> I can look into adding the check in generic code.
>
> In the meant
On Thu, Jan 09, 2014 at 11:08:47PM -0500, Vince Weaver wrote:
> On Thu, 9 Jan 2014, Will Deacon wrote:
>
> > I'd rather see it in the generic code if at all possible. Maybe we could add
> > a flags field to perf_pmu_register?
>
> I can look into adding the check in generic code.
Adding something
On Thu, 9 Jan 2014, Will Deacon wrote:
> I'd rather see it in the generic code if at all possible. Maybe we could add
> a flags field to perf_pmu_register?
I can look into adding the check in generic code.
In the meantime, would you consider a patch like this that disables
the IRQ check and lets
Hi Vince,
On Thu, Jan 09, 2014 at 03:47:19AM +, Vince Weaver wrote:
> On Wed, 8 Jan 2014, Peter Zijlstra wrote:
>
> > On Wed, Jan 08, 2014 at 04:28:20PM -0500, Vince Weaver wrote:
> > > Should the perf_event interface handle setups like this better and work
> > > fine in aggregate mode but r
On Wed, 8 Jan 2014, Peter Zijlstra wrote:
> On Wed, Jan 08, 2014 at 04:28:20PM -0500, Vince Weaver wrote:
> > Should the perf_event interface handle setups like this better and work
> > fine in aggregate mode but return ENOTSUP if a sampled or overflow event
> > is attempted?
>
> Yeah that woul
On Wed, Jan 08, 2014 at 04:28:20PM -0500, Vince Weaver wrote:
> Should the perf_event interface handle setups like this better and work
> fine in aggregate mode but return ENOTSUP if a sampled or overflow event
> is attempted?
Yeah that would be better, we do something similar for P6 class machi
Vince,
I ran into the same problem myself on my Raspberry PI. In fact,
I am really frustrated by ARM platforms not having that IRQ handled
properly. It is pretty common for manufacturers not to provide the code
to route the IRQ, even though the HW does support it. Sometimes the
specs on how to do
I'm working on getting the hardware performance counters working on a
Raspberry-Pi (BCM2835/ARM1176).
The counters are there, but the overflow interrupt is not hooked up so the
init code disables perf_event.
The following patch enables perf_event and it works fine for simple
"perf stat" typ
23 matches
Mail list logo
