[PATCH v1.1 4/7] dt-bindings: iommu: Add spacemit/t100 features

[郑律]

> From: "Robin Murphy"<robin.murphy at arm.com>
> Date:  Fri, Jan 30, 2026, 01:06
> Subject:  Re: [PATCH v1.1 4/7] dt-bindings: iommu: Add spacemit/t100 features
> To: "Conor Dooley"<conor at kernel.org>, "郑律"<lv.zheng at spacemit.com>
> Cc: "Tomasz Jeznach"<tjeznach at rivosinc.com>, "Joerg Roedel"<joro at 8bytes.org>, "Will Deacon"<will at kernel.org>, "Rob Herring"<robh at kernel.org>, "Krzysztof Kozlowski"<krzk+dt at kernel.org>, "Conor Dooley"<conor+dt at kernel.org>, "Paul Walmsley"<pjw at kernel.org>, "Palmer Dabbelt"<palmer at dabbelt.com>, "Albert Ou"<aou at eecs.berkeley.edu>, "Alexandre Ghiti"<alex at ghiti.fr>, "Jingyu Li"<joey.li at spacemit.com>, "iommu"<iommu at lists.linux.dev>, "linux-perf-users"<linux-perf-users at vger.kernel.org>, "linux-riscv"<linux-riscv at lists.infradead.org>, "spacemit"<spacemit at lists.linux.dev>, "devicetree"<devicetree at vger.kernel.org>
> On 29/01/2026 4:41 pm, Conor Dooley wrote:
> > On Thu, Jan 29, 2026 at 06:43:03PM +0800, 郑律 wrote:
> >>> From: "Conor Dooley"<conor at kernel.org>
> >>> Date:  Thu, Jan 29, 2026, 18:08
> >>> Subject:  Re: [PATCH v1.1 4/7] dt-bindings: iommu: Add spacemit/t100 features
> >>> To: "Lv Zheng"<lv.zheng at spacemit.com>
> >>> Cc: "Tomasz Jeznach"<tjeznach at rivosinc.com>, "Joerg Roedel"<joro at 8bytes.org>, "Will Deacon"<will at kernel.org>, "Robin Murphy"<robin.murphy at arm.com>, "Rob Herring"<robh at kernel.org>, "Krzysztof Kozlowski"<krzk+dt at kernel.org>, "Conor Dooley"<conor+dt at kernel.org>, "Paul Walmsley"<pjw at kernel.org>, "Palmer Dabbelt"<palmer at dabbelt.com>, "Albert Ou"<aou at eecs.berkeley.edu>, "Alexandre Ghiti"<alex at ghiti.fr>, "Jingyu Li"<joey.li at spacemit.com>, "Zhijian Chen"<zhijian at spacemit.com>, <iommu at lists.linux.dev>, <linux-perf-users at vger.kernel.org>, <linux-riscv at lists.infradead.org>, <spacemit at lists.linux.dev>, <devicetree at vger.kernel.org>
> >>> On Thu, Jan 29, 2026 at 02:09:13PM +0800, Lv Zheng wrote:
> >>>> Adds device tree bindings for SpacemiT T100 specific features.
> >>>>   
> >>>> vendor-hpm-events: Allow vendor events to be customized in the device
> >>>>                     tree.
> >>>> global-filter: The feature saves silicon area by reducing filters to
> >>>>                 one and use it as a global filter across all events.
> >>>>                 This usually is sufficient for real applications.
> >>>   
> >>> Why can these not be determined from a device specific compatible?
> >>
> >> The specification only defines less than 10 standard event types while the
> >> real silicons should have implemented many other event types based on
> >> their micro-architecture. I tried to provide a common mechanism for all
> >> vendor specific event types across different vendors.
> > 
> > Given that the variance is based on uarch, it sounds like it can be
> > determined from the compatible.
> > 
> >> It is similar for the global filter, the global filter mechanism actually
> >> complies to the IOMMU specification, users can alter the iohpmevt
> >> registers as is what is specified in the IOMMU specification. It only
> >> provides slight application difference between the final effection. Thus
> >> this could also be a non-device specific option.
> > 
> > What is a "user" in this context? Given you're talking about reducing
> > silicon area, it sounds like this will be set in stone for each SoC, and
> > therefore can be determined by compatible. If other devices do this,
> > they can also determine it from their compatible.
> > 
> > Properties for things that can be determined based on compatible are
> > generally not permitted, so you'll need to provide a compelling
> > rationale. Common mechanism isn't one, since determining based on
> > compatible would be a common mechanism based on match data that people
> > can tack onto for their devices.
> 
> Also, reinventing jevents via devicetree is pretty grim anyway - the PMU 
> can simply expose an "identifier" attribute that uniquely identifies the 
> vendor implementation, and perf tooling can match that to a set of event 
> definitions in userspace, with the added bonus that jevents can also 
> encode meaningful descriptions, metrics and suchlike. There doesn't 
> *need* to be a sysfs alias for every possible event. I see the RISC-V 
> CPU PMUs are already on-board with this approach - note the 
> "Unit"/"Compat" matching for system/uncore PMUs is a little different 
> from the mapfile used for CPUs, but see other architectures for examples.

Thanks for the idea. It sounds great and I'll give it a try.

Best regards,
Lv

> 
> Thanks,
> Robin.


This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not an intended recipient of this message, please delete it and any attachment from your system and notify the sender immediately by reply e-mail. Unintended recipients should not use, copy, disclose or take any action based on this message or any information contained in this message. Emails cannot be guaranteed to be secure or error free as they can be intercepted, amended, lost or destroyed, and you should take full responsibility for security checking. 
 
本邮件及其任何附件具有保密性质，并可能受其他保护或不允许被披露给第三方。如阁下误收到本邮件，敬请立即以回复电子邮件的方式通知发件人，并将本邮件及其任何附件从阁下系统中予以删除。如阁下并非本邮件写明之收件人，敬请切勿使用、复制、披露本邮件或其任何内容，亦请切勿依本邮件或其任何内容而采取任何行动。电子邮件无法保证是一种安全和不会出现任何差错的通信方式，可能会被拦截、修改、丢失或损坏，收件人需自行负责做好安全检查。