linux-kernel - Re: [PATCH 2/4] Documentation: Add documentation for APM X-Gene SoC PMU DTS binding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 5 Apr 2016 14:51:06 -0700
From:	Tai Tri Nguyen <ttnguyen@....com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	will.deacon@....com, catalin.marinas@....com,
	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	patches <patches@....com>
Subject: Re: [PATCH 2/4] Documentation: Add documentation for APM X-Gene SoC
 PMU DTS binding

Hi Mark,

On Tue, Apr 5, 2016 at 12:31 PM, Mark Rutland <mark.rutland@....com> 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@....com> 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@....com> 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