From: Bjorn Helgaas <helgaas@kernel.org>
To: "Havalige, Thippeswamy" <thippeswamy.havalige@amd.com>
Cc: "bhelgaas@google.com" <bhelgaas@google.com>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"kw@linux.com" <kw@linux.com>,
"manivannan.sadhasivam@linaro.org"
<manivannan.sadhasivam@linaro.org>,
"robh@kernel.org" <robh@kernel.org>,
"krzk+dt@kernel.org" <krzk+dt@kernel.org>,
"conor+dt@kernel.org" <conor+dt@kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
"Simek, Michal" <michal.simek@amd.com>,
"Gogada, Bharat Kumar" <bharat.kumar.gogada@amd.com>
Subject: Re: [PATCH v8 3/3] PCI: amd-mdb: Add AMD MDB Root Port driver
Date: Tue, 4 Feb 2025 16:11:59 -0600 [thread overview]
Message-ID: <20250204221159.GA863758@bhelgaas> (raw)
In-Reply-To: <SN7PR12MB7201EAC37631E10EBA5A299B8BF42@SN7PR12MB7201.namprd12.prod.outlook.com>
On Tue, Feb 04, 2025 at 09:37:51AM +0000, Havalige, Thippeswamy wrote:
> > -----Original Message-----
> > From: Bjorn Helgaas <helgaas@kernel.org>
> ...
> > On Wed, Jan 29, 2025 at 05:00:29PM +0530, Thippeswamy Havalige wrote:
> > > Add support for AMD MDB (Multimedia DMA Bridge) IP core as Root Port.
> > > +#define AMD_MDB_PCIE_INTR_INTA_ASSERT 16
> > > +#define AMD_MDB_PCIE_INTR_INTB_ASSERT 18
> > > +#define AMD_MDB_PCIE_INTR_INTC_ASSERT 20
> > > +#define AMD_MDB_PCIE_INTR_INTD_ASSERT 22
> >
> > It's kind of weird that these skip the odd-numbered bits, since
> > dw_pcie_rp_intx_flow(), amd_mdb_mask_intx_irq(),
> > amd_mdb_unmask_intx_irq() only use bits 19:16. Something seems wrong
> > and needs either a fix or a comment about why this is the way it is.
>
> ... the odd bits are meant for deasserting inta, intb intc & intd I
> ll include this in my next patch
> > > +#define IMR(x) BIT(AMD_MDB_PCIE_INTR_ ##x)
> > > +#define AMD_MDB_PCIE_IMR_ALL_MASK \
> > > + ( \
> > > + IMR(CMPL_TIMEOUT) | \
> > > + IMR(INTA_ASSERT) | \
> > > + IMR(INTB_ASSERT) | \
> > > + IMR(INTC_ASSERT) | \
> > > + IMR(INTD_ASSERT) | \
> > > + IMR(PM_PME_RCVD) | \
> > > + IMR(PME_TO_ACK_RCVD) | \
> > > + IMR(MISC_CORRECTABLE) | \
> > > + IMR(NONFATAL) | \
> > > + IMR(FATAL) \
> > > + )
> > > +
> > > +#define AMD_MDB_TLP_PCIE_INTX_MASK GENMASK(23, 16)
> >
> > I would drop AMD_MDB_PCIE_INTR_INTA_ASSERT, etc, and just use
> > AMD_MDB_TLP_PCIE_INTX_MASK in the AMD_MDB_PCIE_IMR_ALL_MASK
> > definition.
> >
> > If there are really eight bits of INTx-related things here for the
> > four INTx interrupts, I think you should make two #defines to
> > separate them out.
> Yes, there are 8 intx related bits I ll define them in my next
> patch. I was in confusion here regarding "PCI_NUM_INTX " since this
> macro indicates INTA INTB INTC INTD bits so I discarded deassert
> bits here.
It seems like what you have is a single 8-bit field that contains both
assert and deassert info, interspersed. GENMASK()/FIELD_GET() isn't
enough to really separate them. Maybe you can do something like this:
#define AMD_MDB_TLP_PCIE_INTX_MASK GENMASK(23, 16)
#define AMD_MDB_PCIE_INTR_INTX_ASSERT(x) BIT(1 << x)
If you don't need the deassert bits, a comment would be useful, but
there's no point in adding a #define for them. If you do need them,
maybe this:
#define AMD_MDB_PCIE_INTR_INTX_DEASSERT(x) BIT((1 << x) + 1)
> > > +static irqreturn_t dw_pcie_rp_intx_flow(int irq, void *args) {
> > > + struct amd_mdb_pcie *pcie = args;
> > > + unsigned long val;
> > > + int i;
> > > +
> > > + val = FIELD_GET(AMD_MDB_TLP_PCIE_INTX_MASK,
> > > + pcie_read(pcie, AMD_MDB_TLP_IR_STATUS_MISC));
> > > +
> > > + for_each_set_bit(i, &val, 4)
> >
> > for_each_set_bit(..., PCI_NUM_INTX)
> In next patch I will update value to 8 here.
And here you could do:
val = FIELD_GET(AMD_MDB_TLP_PCIE_INTX_MASK,
pcie_read(pcie, AMD_MDB_TLP_IR_STATUS_MISC));
for (i = 0; i < PCI_NUM_INTX; i++) {
if (val & AMD_MDB_PCIE_INTR_INTX_ASSERT(i))
generic_handle_domain_irq(pcie->intx_domain, i);
> > > + generic_handle_domain_irq(pcie->intx_domain, i);
> > > + d = irq_domain_get_irq_data(pcie->mdb_domain, irq);
> > > + if (intr_cause[d->hwirq].str)
> > > + dev_warn(dev, "%s\n", intr_cause[d->hwirq].str);
> > > + else
> > > + dev_warn_once(dev, "Unknown IRQ %ld\n", d->hwirq);
> >
> > What's the point of an interrupt handler that only logs it?
>
> At this stage, our objective is to notify the user of the occurrence
> of an event. While we intend to integrate these events with the AER
> subsystem in the future, for the time being, we will limit the
> functionality to notifying the user.
OK, just add a comment to that effect here.
Bjorn
next prev parent reply other threads:[~2025-02-04 22:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-29 11:30 [PATCH v8 0/3] Add support for AMD MDB IP as Root Port Thippeswamy Havalige
2025-01-29 11:30 ` [PATCH v8 1/3] dt-bindings: PCI: dwc: Add AMD Versal2 mdb slcr support Thippeswamy Havalige
2025-01-29 11:30 ` [PATCH v8 2/3] dt-bindings: PCI: amd-mdb: Add AMD Versal2 MDB PCIe Root Port Bridge Thippeswamy Havalige
2025-01-29 11:30 ` [PATCH v8 3/3] PCI: amd-mdb: Add AMD MDB Root Port driver Thippeswamy Havalige
2025-02-03 6:23 ` Havalige, Thippeswamy
2025-02-03 17:41 ` Manivannan Sadhasivam
2025-02-03 18:28 ` Bjorn Helgaas
2025-02-04 9:37 ` Havalige, Thippeswamy
2025-02-04 22:11 ` Bjorn Helgaas [this message]
2025-02-05 11:37 ` Havalige, Thippeswamy
2025-02-05 11:53 ` Havalige, Thippeswamy
2025-02-05 14:20 ` Bjorn Helgaas
2025-02-07 16:45 ` Havalige, Thippeswamy
2025-02-05 15:10 ` Markus Elfring
2025-02-06 16:07 ` Havalige, Thippeswamy
2025-02-06 20:26 ` Bjorn Helgaas
2025-02-07 6:39 ` [v8 " Markus Elfring
2025-02-07 6:59 ` Manivannan Sadhasivam
2025-02-07 9:45 ` Markus Elfring
2025-02-11 23:16 ` Bjorn Helgaas
2025-02-12 5:36 ` Krzysztof Kozlowski
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=20250204221159.GA863758@bhelgaas \
--to=helgaas@kernel.org \
--cc=bharat.kumar.gogada@amd.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jingoohan1@gmail.com \
--cc=krzk+dt@kernel.org \
--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=michal.simek@amd.com \
--cc=robh@kernel.org \
--cc=thippeswamy.havalige@amd.com \
/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;
as well as URLs for NNTP newsgroup(s).