Vince, I checked again the ARM code for perf_events. I was wrong, you can pass RAW unmodified. If you look into __hw_perf_event_init() you will see that they get the mapping via raw_event() but all this function does is mask off reserved bits in the config field (very much like on x86). The returned value is then set in hwc->config. So I think we can proceed with your patch.
The *_perf_types enum list all the events but they are only used to initialize the generic PMU events. I think that is a bit overkill but harmless. On Fri, Aug 20, 2010 at 11:28 PM, stephane eranian <eran...@googlemail.com> wrote: > On Fri, Aug 20, 2010 at 4:41 PM, Vince Weaver <vweav...@eecs.utk.edu> wrote: >> On Fri, 20 Aug 2010, stephane eranian wrote: >>> >>> However I have one comment: >>> >>> The event table has the encoding that is specific to perf_events. This >>> means >>> the table can only be used with perf_events. That is not the approach >>> taken >>> by libpfm4. I am trying hard to make the core of the library >>> OS-agnostic. That >>> means the table should have the official encodings of the event. If you >>> need >>> an OS specific encoding, then you need to add a shim layer specific to >>> the OS >>> to make the conversion. >> >> at least for the Cortex A8 (the machine I have) the perf events match the >> actual value you set to hardware (with the difference that it's only a >> 32-bit hardware register). >> >> For example, in the Cortex-A8 Technical Reference manual, section 3.2.50 >> it shows that the EVTSEL (EVent SELection) register is just >> a 32-bit value with the lowest 8-bits being the "EVTSEL" bits (and the >> other bits are reserverd). The event values in table 3-98 correspond >> exactly to the 8-bit value used by perf events. >> >> There are a few possible corner cases; most notably I think perf-events >> might play some tricks to get the cycle count (which is provided by a >> separate register, I'll have to check on that). >> >> Now the other ARM chips might be different, I have to admit that I haven't >> tracked down the documentation for them yet. But at least for the chip I >> have the perf events values match the actual hardware register values. >> > We can ask Will Deadcon @ ARM, he seems to be the current perf_events > ARM maintainer. I want to understand why they went with the full event table > the kernel and what appears to be their own encoding scheme, even though > it matches documentation. Why not just TYPE_RAW+config? > >> Vince >> > ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
