[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <93b3738c386c528193b158da0f85fd27@codeaurora.org>
Date: Wed, 02 May 2018 10:20:19 -0400
From: Agustin Vega-Frias <agustinv@...eaurora.org>
To: Yisheng Xie <xieyisheng1@...wei.com>
Cc: Neil Leeder <neil.m.leeder@...il.com>,
Will Deacon <will.deacon@....com>,
Mark Rutland <mark.rutland@....com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
Mark Langsdorf <mlangsdo@...hat.com>,
Mark Salter <msalter@...hat.com>, Jon Masters <jcm@...hat.com>,
Timur Tabi <timur@...eaurora.org>,
Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH 2/2] perf: add arm64 smmuv3 pmu driver
On 2018-04-02 02:37, Yisheng Xie wrote:
> Hi Neil,
>
> On 2018/4/1 13:44, Neil Leeder wrote:
>> Hi Yisheng Xie,
>>
>> On 3/29/2018 03:03 AM, Yisheng Xie wrote:
>>>
>>> Hi Neil,
>>>
>>> On 2017/8/5 3:59, Neil Leeder wrote:
>>>> + mem_resource_0 = platform_get_resource(pdev, IORESOURCE_MEM,
>>>> 0);
>>>> + mem_map_0 = devm_ioremap_resource(&pdev->dev, mem_resource_0);
>>>> +
>>> Can we use devm_ioremap instead? for the reg_base of smmu_pmu is
>>> IMPLEMENTATION DEFINED. If the reg of smmu_pmu is inside smmu,
>>> devm_ioremap_resource will failed and return -EBUSY, eg.:
>>>
>>> smmu reg ranges: 0x180000000 ~ 0x1801fffff
>>> its smmu_pmu reg ranges: 0x180001000 ~ 0x180001fff
>>>
>> Just to let you know that I no longer work at Qualcomm and I won't be
>> able to provide updates to this patchset. I expect that others from my
>> former team at Qualcomm will pick up ownership.
>
> Thanks for this infomation.
>
> hi Agustin and Timur,
>
> Is there any new status about this patchset?
>
Hi,
Apologies for the slow response.
We are having some internal discussions about when/if to do this.
I expect to have more clarity within a few weeks.
For what is worth let me take the opportunity to outline the approach
we would like to see for a V2 either developed by us or somebody else
in the community:
1. Rework to comply with the IORT spec changes.
2. Rework probing to extract extra information from the IORT table
about SMMU/device associations.
With this information and some perf user space work I think it's
possible
to have a single dynamic PMU node and use a similar approach to what
is
used in the Coresight drivers to pass the device we want to monitor
and
for the driver to find the PMU/PMCG. E.g.:
$ lspci
0001:00:00.0 PCI bridge: Airgo Networks, Inc. Device 0401
0002:00:00.0 PCI bridge: Airgo Networks, Inc. Device 0401
0002:01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family
[ConnectX-3]
0003:00:00.0 PCI bridge: Airgo Networks, Inc. Device 0401
0003:01:00.0 Ethernet controller: Mellanox Technologies MT27500 Family
[ConnectX-3]
# Monitor TLB misses on root complex 2 (no stream filter is applied)
perf stat -a -e smmu/tlb_miss,@0002:00:00.0/ <workload>
# Monitor TLB misses on a device on root complex 2 (derive the stream
number from the RID)
perf stat -a -e smmu/tlb_miss,@0002:01:00.0/ <workload>
Thanks,
AgustÃn
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
Powered by blists - more mailing lists