All of lore.kernel.org
 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 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.