[PATCH 2/2] perf: add arm64 smmuv3 pmu driver

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> On Behalf Of Agustin Vega-Frias
> Sent: Wednesday, May 02, 2018 3:20 PM
> To: xieyisheng (A) <xieyisheng1 at huawei.com>
> Cc: Mark Rutland <mark.rutland at arm.com>; Mark Langsdorf
> <mlangsdo at redhat.com>; Neil Leeder <neil.m.leeder at gmail.com>; Jon
> Masters <jcm at redhat.com>; Timur Tabi <timur at codeaurora.org>; Will
> Deacon <will.deacon at arm.com>; linux-kernel at vger.kernel.org; Mark Brown
> <broonie at kernel.org>; Mark Salter <msalter at redhat.com>; linux-arm-
> kernel at lists.infradead.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.

Thanks for coming back on this. It would be good to address cases where
the PMCG base address is at a IMP DEF address offset within the associated
SMMUv3 page address space. As things stands with pmu v1 currently, the
SMMUv3 driver probe will fail. Please find the discussion here[1].

Thanks,
Shameer
[1] https://lkml.org/lkml/2018/1/31/235

>    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, at 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, at 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.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel