Hi Mark, On Tue, Apr 5, 2016 at 12:31 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Tue, Apr 05, 2016 at 11:51:02AM -0700, Tai Tri Nguyen wrote: >> Hi Mark, >> >> On Mon, Apr 4, 2016 at 4:38 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >> > On Mon, Apr 04, 2016 at 04:40:33PM -0700, Tai Tri Nguyen wrote: >> >> On Fri, Apr 1, 2016 at 5:30 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: >> >> > On Thu, Mar 31, 2016 at 04:37:50PM -0700, Tai Nguyen wrote: >> >> >> +This is APM X-Gene SoC PMU (Performance Monitoring Unit) module. >> >> >> +The following PMU devices are supported: >> >> >> + >> >> >> + L3C - L3 cache controller >> >> >> + IOB - IO bridge >> >> >> + MCB - Memory controller bridge >> >> >> + MC - Memory controller >> >> > >> >> > These sound like separate units. How do these relate? >> >> > >> >> > Is there an SOC-wide PMU that aggregates counters, or are these actually >> >> > independent? >> >> > >> >> >> >> Yes, they are independent, but sharing the same top level status interrupt. >> >> There's no SOC-wide PMU which aggregates these counters. >> > >> > If they're just sharing the interrupt, why are they not separate nodes (and >> > drivers) which simply happen to share an interrupt? >> > >> > Is there anything else shared? >> >> Yes, a long with the interrupt they also share top level PMU status CSR region. > > Ah, ok. I had missed that. > > What exactly exists in that region? Are the shared registers just for handling > the shared interrupt, or are they used to handle other parts of the PMUs too? They are shared registers for handling the shared interrupt only, indicating/masking source of the shared interrupt. > >> >> >> +Required properties for L3C subnode: >> >> >> +- compatible : Shall be "apm,xgene-pmu-l3c". >> >> >> +- reg : First resource shall be the L3C PMU resource. >> >> >> +- index : Instance number of the L3C PMU. >> >> >> + >> >> >> +Required properties for IOB subnode: >> >> >> +- compatible : Shall be "apm,xgene-pmu-iob". >> >> >> +- reg : First resource shall be the IOB PMU resource. >> >> >> +- index : Instance number of the IOB PMU. >> >> >> + >> >> >> +Required properties for MCB subnode: >> >> >> +- compatible : Shall be "apm,xgene-pmu-mcb". >> >> >> +- reg : First resource shall be the MCB PMU resource. >> >> >> +- index : Instance number of the MCB PMU. >> >> >> + >> >> >> +Required properties for MC subnode: >> >> >> +- compatible : Shall be "apm,xgene-pmu-mc". >> >> >> +- reg : First resource shall be the MC PMU resource. >> >> >> +- index : Instance number of the MC PMU. >> >> > >> >> > What's the index property useful for? >> >> > >> >> >> >> The index property is used for indicating the physical hardware PMU id. >> >> For example, on X-Gene1 there are 4 memory controllers (MC), each of them has >> >> its own PMU. The index property tells us which MC a PMU belongs to. >> >> The same for MCB/L3C and IOB. >> > >> > Sure, but is this simply informative for the user, or does this have an impact >> > on the programming model? >> > >> >> Yes, it does impact. For example, there are 4 PMUs associated with 4 MCs. >> They all certainly have the same sort of events. The index will help >> to determine >> the right event users want to monitor. Below is an example of perf list output: >> ... >> mc0/mcu-rd-request/ >> ... >> mc1/mcu-rd-request/ > > By "programming model" I mean the way the kernel interacts with the device, > rather than the interface exposed to userspace. For example, does the index > affect which bits are used in the shared CSR region? > > If it's only used for the name exposed to userspace, that's fine. > > Otherwise, there may be subtle gotchas. No, it doesn't impact in that mean. Regards, -- Tai -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
