From: Michal Simek <michal.simek@amd.com>
To: Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
"Stabellini, Stefano" <stefano.stabellini@amd.com>
Cc: linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
iommu@lists.linux.dev,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"Sarangi, Anirudha" <anirudha.sarangi@amd.com>
Subject: SMMUv3 interrupt handling via custom logic
Date: Fri, 27 Jun 2025 09:19:05 +0200 [thread overview]
Message-ID: <0482d84e-871b-4522-b94b-29a97c87ff66@amd.com> (raw)
Hi Will and Robin, (+Stefano, Anirudha)
We are using smmu-v3 in our SOC and I would like to ask you for recommendation
how to handle our interrupt cases.
here is description which we are using
smmu: iommu@ec000000 {
compatible = "arm,smmu-v3";
reg = <...>;
#iommu-cells = <1>;
interrupt-names = "combined";
interrupts = <0 169 4>;
};
but it is missing one important detail which just arise that actually there is
additional HW logic which deals with SMMU interrupts separately.
There is a secure part (global, cmd, event - gerror, cmdq-sync, eventq in DT)
and non secure part (pri, global, cmd, event - priq, gerror, cmdq-sync, eventq
in DT).
Based on my information all these interrupts should be acked once handled to be
able to get another one.
The driver itself is able to handle them separately but we didn't create any
solution to reach custom HW to do it.
I looked at f935448acf46 ("iommu/arm-smmu-v3: Add workaround for Cavium
ThunderX2 erratum #126") which introduced combined IRQs but it looks like that
there is no need for additional ACK of that IRQs.
The HW logic itself is handling secure and non secure settings for SMMU that's
why would be the best to avoid directly mapping it in Linux.
One way to go is to create secondary interrupt controller driver
a) ioremap one with notice about secure part because we are using SMMU only with
NS world
b) firmware based to tunnel accesses via SMCs and allow only access to limited
amount of registers
The second way is likely create any hooks in the driver to be able to provide
additional SOC specific hooks.
I am not quite sure which way would be the best that's why I would like to get
some recommendation from you.
Stefano: please correct me if any of my description is not accurate.
Thanks,
Michal
next reply other threads:[~2025-06-27 7:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 7:19 Michal Simek [this message]
2025-06-27 10:42 ` Robin Murphy
2025-06-27 19:20 ` Stefano Stabellini
2025-07-11 15:16 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0482d84e-871b-4522-b94b-29a97c87ff66@amd.com \
--to=michal.simek@amd.com \
--cc=anirudha.sarangi@amd.com \
--cc=iommu@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=stefano.stabellini@amd.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®