[PATCH v3 4/8] dt-bindings: iommu: Add spacemit/t100 features

[Lv Zheng]

On 2/6/2026 6:24 PM, Conor Dooley wrote:
> On Fri, Feb 06, 2026 at 09:33:09AM +0800, Lv Zheng wrote:
>> On 2/6/2026 2:24 AM, Conor Dooley wrote:
>>> On Thu, Feb 05, 2026 at 11:11:51AM +0800, Lv Zheng wrote:
>>>> On 2/5/2026 1:37 AM, Conor Dooley wrote:
>>>>> On Wed, Feb 04, 2026 at 05:09:12PM +0800, Lv Zheng wrote:
>>>>>> Adds device tree bindings for SpacemiT T100 specific features by
>>>>>> introducing spacemit,100 compatible. T100 contains distributed IOATCs,
>>>>>> each of which exposes pmiv interrupt.
>>>>>>
>>>>>> Signed-off-by: Lv Zheng <lv.zheng at linux.spacemit.com>
>>>>>> Signed-off-by: Jingyu Li <joey.li at spacemit.com>
>>>>>> ---
>>>>>>     .../bindings/iommu/riscv,iommu.yaml           | 37 +++++++++++++++++++
>>>>>>     1 file changed, 37 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml b/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
>>>>>> index d4838c3b3741..2da3456e7402 100644
>>>>>> --- a/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/iommu/riscv,iommu.yaml
>>>>>> @@ -32,6 +32,12 @@ properties:
>>>>>>       # should be specified along with 'reg' property providing MMIO location.
>>>>>>       compatible:
>>>>>>         oneOf:
>>>>>> +      - description: SpacemiT distributed IOMMUs
>>>>>> +        items:
>>>>>> +          - enum:
>>>>>> +              - spacemit,t100
>>>>>> +          - const: spacemit,riscv-iommu
>>>>>
>>>>> What actually is the t100? Is it an SoC or is it the name of the core
>>>>> complex IP that spacemit is using in multiple SoCs?
>>>>
>>>> T100 is the name of the IOMMU IP developed by SpacemiT, announced in RISC-V
>>>> 2024 China Summit:
>>>> https://www.bilibili.com/video/BV1DNtCeiEBk/
>>>> It's world first server SPEC IOMMU in RISC-V, supports IOTLB placed in
>>>> adjacent to the DMA masters and supports PCIe ATS and PRI.
>>>> You can find it shipped in the recent publicly purchasable SoC SpacemiT K3.
>>>
>>> Right, then what you need here is something like:
>>>
>>> items:
>>>     - enum:
>>>         - spacemit,k3-iommu
>>>     - spacemit,t100-iommu
>>>     - riscv,iommu
>>>
>>> Driver can then match on spacemit,t100-iommu - but you need to have
>>> soc-specific compatibles.
>>> I'm not convinced that riscv,iommu is suitable here though, does the
>>> driver work on your platform without the portions of code that are added
>>> by this series and enabled by your new compatible? If not, the I don't
>>> think the riscv,iommu fallback should be here.
>>>
>>> Additionally, please stop sending new versions so frequently and in
>>> response to earlier submissions. I have a v4 in my inbox while we are
>>> still discussing v3.
>>
>> SpacemiT provides RISC-V IOMMU implementation, T100 is the first
>> generation of the this IP product line, we have plan to develop T200,
>> T300, etc., with more features introduced to be adoptive to new
>> RISC-V IOMMU specifications.
>> Besides, T100 is not only shipped in K3, but also shipped in V100 and
>> the follow-up SoCs, like Kn, Vn00, they will likely use the same
>> synthesis result of T100 RTLs.
>>
>>  From SpacemiT's point of view, we need a common sense of this IP
>> series for something like IOATCs, that's why spacemit,riscv-iommu
>> (this is same like qemu,riscv-iommu) is introduced. And a common sense
> 
> No, it's not the same as qemu,riscv-iommu. That exists to avoid
> riscv,iommu being allowed in isolation and as a "SoC"/integration
> specific compatible. The driver matches against riscv,iommu not
> qemu,riscv-iommu and has no qemu,riscv-iommu specific behaviours.
> It is akin to having spacemit,k3-iommu.

Got it.

> 
>> of T100 for all SoCs shipped T100 (like global filters, vendor events
>> and etc.,).
>>
>> IMO, the current compatible is proper to reflect these concerns.
>> What do you think?
> 
> I pretty much already told you what I think, that you need SoC-specific
> compatibles for SoCs that integrate this IP and that the you should drop
> the spacemit,riscv-iommu compatible. The spacemit,riscv-iommu compatible
> doesn't provide any additional value over spacemit,t100-iommu, and has
> the downside of maybe being confusing in the future if spacemit
> produces a iommu that doesn't have the IOATC behaviour.

Sounds reasonable. Thanks.

> 
> Also, I don't see an answer to my question about whether the hardware
> will work without the driver changes this series introduces and enables
> with the new compatible?

Basically, T100 is riscv,iommu compatible, its IOATS part should be able
to work using standard HPM events with standard riscv,iommu HPM
compatible driver. People can now test the real hardware of spacemit
T100 on K3.
https://canonical.com/blog/spacemit-announces-availability-of-ubuntu-on-k3-k1-series
I'll try to ask our product team to find third party testers, and if
any, adds Cc(s) in the next revision.

Without the awareness of this compatible, hardware will face the
following problems:

Handled in this series:
1. No vendor event matches
2. No global filter awareness
3. No IOATC enumeration
That's the basic support introduced in this series to enable some basic
features of T100 that we couldn't find in the upstream.

And there are other features not handled in this series:
4. No identities matching vendors
5. No awareness of only PMIV working as WSI, others (CIV/FIV/PIV) are
    configurable as MSI to make IOATS/IOATC PMIV behaves same and more
    suitable for kernel performance sampling.
6. And many other SpacemiT specific features people can find the
    discussions in the IOMMU spec community that is not limited to HPM,
    ex., RISC-V DMA64 compliance, QEMU old style MSI-PTE support, etc.
7. ACPI support for spacemit,v100-iommu.
8. PCIe ATS/PRI support for spacemit,k3-iommu/spacemit,v100-iommu.
9. etc.

Cheers,
Lv

> 
> Cheers,
> Conor.