On 10/07/2015 07:20 AM, Will Deacon wrote: > Hi again, Drew, > > On Thu, Sep 24, 2015 at 06:52:57PM +0100, Will Deacon wrote: >> On Mon, Aug 17, 2015 at 10:40:36PM +0100, Drew Richardson wrote: >>> So my suggestion to solve the problem is that the kernel can have the >>> list of events as proposed in the patch. >> >> Sorry, but I just don't buy this argument. Your problem is that the user >> needs to be running an up-to-date perf tool, but with your proposed >> solution, you're asking them to update the *kernel* instead, which is >> (unfortunately) one of the hardest pieces of software to upgrade on a >> typical ARM platform. > > I've spent some time thinking about this and, actually, it makes sense > to do this for the architected events. These event numbers are guaranteed > to be portable between CPUs, so if we expose those through sysfs then > we don't have this dependency on updating the kernel for newer cores > (well, once the initial period without your patch has expired). It's the > noon-portable, micro-architectural events that I object to. > > So how about you roll a new version of this patch just exposing the > architected events and making use of the macros in perf_event.h to make > it a bit tidier (PMU_EVENT_ATTR, PMU_EVENT_ATTR_STRING etc)? > > Be aware that there's a fair amount of arm64 perf patches queue for 4.4, > since we're moving over to the code in drivers/perf/. Hopefully these > will appear on the arm64 for-next/core branch shortly.
Have you considered using OF/ACPI to describe this aspect of the hardware? Thanks, Christopher Covington -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
