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

[Conor Dooley]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260129/11dbc391/attachment.sig>