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: 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

  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.