linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Verma, Devendra" <Devendra.Verma@amd.com>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Simek, Michal" <michal.simek@amd.com>
Subject: Re: [PATCH RESEND v6 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support
Date: Wed, 10 Dec 2025 10:32:28 -0600	[thread overview]
Message-ID: <20251210163228.GA3526502@bhelgaas> (raw)
In-Reply-To: <b2s6genayrgyicxawx2scpswfji3c62vxn7cgvpzwfbm6vodtx@5dseozibsrte>

On Wed, Dec 10, 2025 at 10:26:38PM +0900, Manivannan Sadhasivam wrote:
> On Wed, Dec 10, 2025 at 11:40:04AM +0000, Verma, Devendra wrote:
> > > -----Original Message-----
> > > From: Manivannan Sadhasivam <mani@kernel.org>
> > > On Fri, Nov 21, 2025 at 05:04:54PM +0530, Devendra K Verma wrote:
> > > > AMD MDB PCIe endpoint support. For AMD specific support added the
> > > > following
> > > >   - AMD supported PCIe Device IDs and Vendor ID (Xilinx).
> > > >   - AMD MDB specific driver data
> > > >   - AMD MDB specific VSEC capability to retrieve the device DDR
> > > >     base address.

> > > > +/* Synopsys */
> > > >  #define DW_PCIE_VSEC_DMA_ID                  0x6

> > > > +/* AMD MDB (Xilinx) specific defines */
> > > > +#define DW_PCIE_XILINX_MDB_VSEC_DMA_ID               0x6

> > > > static void dw_edma_pcie_get_vsec_dma_data(struct pci_dev *pdev,

> > > > +      * Synopsys and AMD (Xilinx) use the same VSEC ID for the
> > > > + purpose
> > >
> > > Same or different?
> > 
> > It is the same capability for which Synosys and AMD (Xilinx) share
> > the common value.
> 
> This is confusing. You are searching for either DW_PCIE_VSEC_DMA_ID
> or DW_PCIE_XILINX_MDB_VSEC_DMA_ID below, which means that the VSEC
> IDs are different.

This is perennially confusing.

Since this is a "Vendor-Specific" (not a "Designated Vendor-Specific")
capability, we must search for the per-vendor VSEC ID, i.e.,
DW_PCIE_VSEC_DMA_ID for PCI_VENDOR_ID_SYNOPSYS devices or
DW_PCIE_XILINX_MDB_VSEC_DMA_ID for PCI_VENDOR_ID_XILINX devices.

The fact that DW_PCIE_VSEC_DMA_ID == DW_PCIE_XILINX_MDB_VSEC_DMA_ID is
a coincidence and is not relevant to the code.  The comment that
"Synopsys and AMD (Xilinx) use the same VSEC ID for the purpose"
should be removed because it adds confusion and the code doesn't rely
on that.

However, the subsequent code DOES rely on the fact that the Synopsys
and the Xilinx VSECs have the same *registers* at the same offsets:

        pci_read_config_dword(pdev, vsec + 0x8, &val);
        map = FIELD_GET(DW_PCIE_VSEC_DMA_MAP, val);
        pdata->rg.bar = FIELD_GET(DW_PCIE_VSEC_DMA_BAR, val);

        pci_read_config_dword(pdev, vsec + 0xc, &val);
        pdata->wr_ch_cnt = min_t(u16, pdata->wr_ch_cnt,
                                 FIELD_GET(DW_PCIE_VSEC_DMA_WR_CH, val));
        pdata->rd_ch_cnt = min_t(u16, pdata->rd_ch_cnt,
                                 FIELD_GET(DW_PCIE_VSEC_DMA_RD_CH, val));

        pci_read_config_dword(pdev, vsec + 0x14, &val);
        off = val;

        pci_read_config_dword(pdev, vsec + 0x10, &val);

The VSEC ID *values* are not relevant, but the fact that the registers
in the Synopsys and the Xilinx capabilities are identical *is*
important and not obvious, so if you share the code that reads those
registers, there should be a comment about that.

The normal way to use VSEC is to look for a capability for a single
vendor and interpret it using code for that specific vendor.  I think
I would split this into separate dw_edma_pcie_get_synopsys_dma_data()
and dw_edma_pcie_get_xilinx_dma_data() functions to make it obvious
that these are indeed controlled by different vendors, e.g.,

  dw_edma_pcie_get_synopsys_dma_data()
  {
    vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_SYNOPSYS,
                                    DW_PCIE_VSEC_DMA_ID);
    if (!vsec)
      return;

    pci_read_config_dword(pdev, vsec + 0x8, &val);
    ...
  }

  dw_edma_pcie_get_xilinx_dma_data()
  {
    vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
                                    DW_PCIE_XILINX_MDB_VSEC_DMA_ID);
    if (!vsec)
      return;

    pci_read_config_dword(pdev, vsec + 0x8, &val);
    ...

    vsec = pci_find_vsec_capability(pdev, PCI_VENDOR_ID_XILINX,
                                    DW_PCIE_XILINX_MDB_VSEC_ID);
    if (!vsec)
      return;
    ...
  }

It's safe to call both of them for all devices like this:

  dw_edma_pcie_probe
  {
    ...
    dw_edma_pcie_get_synopsys_dma_data(pdev, vsec_data);
    dw_edma_pcie_get_xilinx_dma_data(pdev, vsec_data);
    ...
  }

Most of the code in dw_edma_pcie_get_synopsys_dma_data() would be
duplicated, but that's OK and acknowledges the fact that Synopsys and
Xilinx can evolve that VSEC independently.

Bjorn

  reply	other threads:[~2025-12-10 16:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21 11:34 [PATCH RESEND v6 0/2] Add AMD MDB Endpoint and non-LL mode Support Devendra K Verma
2025-11-21 11:34 ` [PATCH RESEND v6 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support Devendra K Verma
2025-12-01  9:58   ` Verma, Devendra
2025-12-08  5:24   ` Manivannan Sadhasivam
2025-12-10 11:40     ` Verma, Devendra
2025-12-10 13:26       ` Manivannan Sadhasivam
2025-12-10 16:32         ` Bjorn Helgaas [this message]
2025-12-11 11:40           ` Verma, Devendra
2025-12-12  0:54           ` Manivannan Sadhasivam
2025-11-21 11:34 ` [PATCH RESEND v6 2/2] dmaengine: dw-edma: Add non-LL mode Devendra K Verma
2025-12-01  9:58   ` Verma, Devendra
2025-12-03  9:24     ` Eugen Hristev
2025-12-10  9:54       ` Verma, Devendra
2025-12-08  5:29   ` Manivannan Sadhasivam
2025-12-10 11:39     ` Verma, Devendra
2025-12-10 13:28       ` Manivannan Sadhasivam
2025-12-11 11:39         ` Verma, Devendra
2025-12-12  0:51           ` Manivannan Sadhasivam
  -- strict thread matches above, loose matches on Subject: below --
2025-11-11  7:05 [PATCH RESEND v6 0/2] Add AMD MDB Endpoint and non-LL mode Support Devendra K Verma
2025-11-11  7:05 ` [PATCH RESEND v6 1/2] dmaengine: dw-edma: Add AMD MDB Endpoint Support Devendra K Verma

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=20251210163228.GA3526502@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=Devendra.Verma@amd.com \
    --cc=bhelgaas@google.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=michal.simek@amd.com \
    --cc=vkoul@kernel.org \
    /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).