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

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@xxxxxxxxxxxxxxxxxxx]
> On Behalf Of Agustin Vega-Frias
> Sent: Wednesday, May 02, 2018 3:20 PM
> To: xieyisheng (A) <xieyisheng1@xxxxxxxxxx>
> Cc: Mark Rutland <mark.rutland@xxxxxxx>; Mark Langsdorf
> <mlangsdo@xxxxxxxxxx>; Neil Leeder <neil.m.leeder@xxxxxxxxx>; Jon
> Masters <jcm@xxxxxxxxxx>; Timur Tabi <timur@xxxxxxxxxxxxxx>; Will
> Deacon <will.deacon@xxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; Mark Brown
> <broonie@xxxxxxxxxx>; Mark Salter <msalter@xxxxxxxxxx>; linux-arm-
> kernel@xxxxxxxxxxxxxxxxxxx
> 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,@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.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel