From: Brian Norris <briannorris@chromium.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: "Jingoo Han" <jingoohan1@gmail.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
"Rob Herring" <robh@kernel.org>,
"Marc Zyngier" <marc.zyngier@arm.com>,
"Krzysztof Wilczyński" <kw@linux.com>
Subject: Re: [PATCH] PCI: dwc: Use level-triggered handler for MSI IRQs
Date: Thu, 2 Jan 2025 17:43:26 -0800 [thread overview]
Message-ID: <Z3dAvgO3XEUaJfq_@google.com> (raw)
In-Reply-To: <20241230171145.hsqynixmowjn77ki@thinkpad>
On Mon, Dec 30, 2024 at 10:41:45PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Oct 15, 2024 at 02:12:16PM -0700, Brian Norris wrote:
> > From: Brian Norris <briannorris@google.com>
> >
> > Per Synopsis's documentation, the msi_ctrl_int signal is
> > level-triggered, not edge-triggered.
> >
>
> Could you please quote the spec reference?
From the reference manual for msi_ctrl_int:
"Asserted when an MSI interrupt is pending. De-asserted when there is
no MSI interrupt pending.
...
Active State: High (level)"
The reference manual also points at the databook for more info. One
relevant excerpt from the databook:
"When any status bit remains set, then msi_ctrl_int remains asserted.
The interrupt status register provides a status bit for up to 32
interrupt vectors per Endpoint. When the decoded interrupt vector is
enabled but is masked, then the controller sets the corresponding bit
in interrupt status register but the it does not assert the top-level
controller output msi_ctrl_int.
That's essentially a prose description of level-triggering, plus
32-vector multiplexing and masking.
Did you want a v2 with this included, or did you just want it noted
here?
(Side note: I think it doesn't really matter that much whether we use
the 'level' or 'edge' variant handlers here, at least if the parent
interrupt is configured correctly as level-triggered. We're not actually
in danger of a level-triggered interrupt flood or similar issue.)
Brian
next prev parent reply other threads:[~2025-01-03 1:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 21:12 [PATCH] PCI: dwc: Use level-triggered handler for MSI IRQs Brian Norris
2024-12-30 17:11 ` Manivannan Sadhasivam
2025-01-03 1:43 ` Brian Norris [this message]
2025-01-03 17:49 ` Bjorn Helgaas
2025-01-03 17:58 ` Bjorn Helgaas
2025-01-03 22:47 ` Brian Norris
2025-01-04 10:09 ` Manivannan Sadhasivam
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=Z3dAvgO3XEUaJfq_@google.com \
--to=briannorris@chromium.org \
--cc=bhelgaas@google.com \
--cc=jingoohan1@gmail.com \
--cc=kw@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=marc.zyngier@arm.com \
--cc=robh@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