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: Wed, 5 Feb 2025 08:20:38 -0600 [thread overview]
Message-ID: <20250205142038.GA910930@bhelgaas> (raw)
In-Reply-To: <SN7PR12MB720115611148E80D555A1A1E8BF72@SN7PR12MB7201.namprd12.prod.outlook.com>
On Wed, Feb 05, 2025 at 11:53:53AM +0000, Havalige, Thippeswamy wrote:
> > -----Original Message-----
> > From: Havalige, Thippeswamy
> > Sent: Wednesday, February 5, 2025 5:08 PM
> > To: Bjorn Helgaas <helgaas@kernel.org>
> > Cc: bhelgaas@google.com; lpieralisi@kernel.org; kw@linux.com;
> > manivannan.sadhasivam@linaro.org; robh@kernel.org; krzk+dt@kernel.org;
> > conor+dt@kernel.org; linux-pci@vger.kernel.org; devicetree@vger.kernel.org;
> > linux-kernel@vger.kernel.org; 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
> > > > > 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
Tangent: I don't know what "deassert" would mean here, since INTx is
an *incoming* interrupt and the Root Port is the receiver and can mask
or acknowledge the interrupt but not really deassert it.
> > > > > > +#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))
> > This condition never met observing zero here.
> To satisfy this condition need to modify macros as following.
> #define AMD_MDB_PCIE_INTR_INTX_ASSERT(x) BIT(x)
> #define AMD_MDB_PCIE_INTR_INTX_DEASSERT(x) BIT(x+1)
Maybe I don't understand how the assert/deassert bits are laid out in
the register.
The original patch has this:
+#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
and if the odd bits are for deassert I thought that meant they would
look like this:
#define AMD_MDB_PCIE_INTR_INTA_DEASSERT 17
#define AMD_MDB_PCIE_INTR_INTB_DEASSERT 19
#define AMD_MDB_PCIE_INTR_INTC_DEASSERT 21
#define AMD_MDB_PCIE_INTR_INTD_DEASSERT 23
+#define AMD_MDB_TLP_PCIE_INTX_MASK GENMASK(23, 16)
If we extract AMD_MDB_TLP_PCIE_INTX_MASK with FIELD_GET(),
the field gets shifted right by 16, so we should end up with
something like this:
INTA assert 0000 0001 == BIT(0)
INTA deassert 0000 0010 == BIT(1)
INTB assert 0000 0100 == BIT(2)
INTB deassert 0000 1000 == BIT(3)
INTC assert 0001 0000 == BIT(4)
INTC deassert 0010 0000 == BIT(5)
INTD assert 0100 0000 == BIT(6)
INTD deassert 1000 0000 == BIT(7)
But maybe that's not how they're actually laid out?
I think the argument to AMD_MDB_PCIE_INTR_INTX_ASSERT() should
be the hwirq (0..3 for INTA..INTD), so if we use
#define AMD_MDB_PCIE_INTR_INTX_ASSERT(x) BIT(x)
#define AMD_MDB_PCIE_INTR_INTX_DEASSERT(x) BIT(x+1)
as you propose, don't the assert/deassert bits collide?
AMD_MDB_PCIE_INTR_INTX_ASSERT(0) == BIT(0) for INTA assert
AMD_MDB_PCIE_INTR_INTX_ASSERT(1) == BIT(1) for INTB assert
AMD_MDB_PCIE_INTR_INTX_DEASSERT(0) == BIT(1) for INTA deassert
> > > generic_handle_domain_irq(pcie->intx_domain, i);
> > >
> > > > > > + generic_handle_domain_irq(pcie->intx_domain, i);
next prev parent reply other threads:[~2025-02-05 14:20 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
2025-02-05 11:37 ` Havalige, Thippeswamy
2025-02-05 11:53 ` Havalige, Thippeswamy
2025-02-05 14:20 ` Bjorn Helgaas [this message]
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=20250205142038.GA910930@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.