[PATCH v2 3/3] perf/smmuv3: Synthesize IIDR from CoreSight ID registers

[Robin Murphy]

On 2021-12-07 13:20, Leo Yan wrote:
> On Tue, Dec 07, 2021 at 12:48:13PM +0000, Robin Murphy wrote:
>> On 2021-12-07 12:28, John Garry via iommu wrote:
>>> On 07/12/2021 12:04, Robin Murphy wrote:
>>>>>>
>>>>> So is there some userspace part to go with this now?
>>>>
>>>> FWIW I've not looked into it - is it just a case of someone knocking
>>>> out some JSON from the MMU-600/700 TRMs, or is there still mroe to
>>>> do?
>>>
>>> That should just be it.
> 
> Hope I didn't arrive too late :)
> 
> Yes, I think we just missed two things: the DT binding for SMMUv3 PMU
> which is just addressed by this patchset; and the PMU event aliasing
> for SMMUv3 PMU, before I inquired with John and John said he would
> upstream the related patches after kernel can export a IIDR value via
> sysfs node.
> 
> Seems to me, after this patchset for DT binding and PMU event alias
> patches are landed to the mainline kernel, it would be perfect.
> 
>>>> I had the impression that *some* part of the process was stalled
>>>> until implementations can start providing meaningful IIDRs, but I
>>>> wasn't sure whether that was tooling or just data. I just work the
>>>> low-level enablement angle :)
>>>
>>> Tooling should be ok, but I would just like to see more of these JSONs
>>> so any tooling issues can be ironed out.
>>
>> Sounds good - Jean, Leo, is that something Linaro might like to pick up as
>> part of the PMCG interest, or shall I make a note on my to-do list for the
>> new year?
> 
> I took a look for current patch for using PIDR to synthesize IIDR, it
> looks good to me.  But I tested it on Hisilicon D06 board and observed
> the composed IIDR values are still zeros.
> 
> I added a printk sentence to dump iidr value at the end of the function
> smmu_pmu_get_iidr():
> 
>    leoy at ubuntu:~$ dmesg | grep iidr
>    [   28.674087] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.8.auto: iidr=0x0
>    [   28.705239] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.9.auto: iidr=0x0
>    [   28.729924] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.10.auto: iidr=0x0
>    [   28.754855] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.11.auto: iidr=0x0
>    [   28.779811] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.12.auto: iidr=0x0
>    [   28.804755] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.13.auto: iidr=0x0
>    [   28.829825] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.14.auto: iidr=0x0
>    [   28.854767] arm-smmu-v3-pmcg arm-smmu-v3-pmcg.15.auto: iidr=0x0
> 
> Please confirm if this is expected or not?  I think this might
> introduce difficulty for John for the PMU event alias patches, which
> is dependent on a non-zero IIDR.

Yes, from previous discussions I believe the HiSilicon implementations 
don't have much meaningful ID information at all (hence why we have to 
match ACPI table headers to identify the counter erratum). My trick only 
works for Arm Ltd. implementations since they happen to have the IMP-DEF 
CoreSight registers with the same information as would be in the future 
IIDR.

To clarify, the proposal at this point is to write up JSON files for 
MMU-600/MMU-700, based on this patch, in order to pipe-clean the process 
for future SMMUv3.3 PMCG implementations with real IIDRs.

Whether other implementers might retroactively define "equivalent" IIDR 
values for their existing implementations in a way we could potentially 
quirk in the driver is an orthogonal question.

Cheers,
Robin.

> 
> At last, very appreciate your (Jean-Philippe, Robin and John) help!
> 
> Thanks,
> Leo
>