devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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);

  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 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).