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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.