From: Niklas Cassel <cassel@kernel.org>
To: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Cc: bhelgaas@google.com, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
thierry.reding@gmail.com, jonathanh@nvidia.com,
kishon@kernel.org, arnd@arndb.de, gregkh@linuxfoundation.org,
Frank.Li@nxp.com, den@valinux.co.jp, hongxing.zhu@nxp.com,
jingoohan1@gmail.com, vidyas@nvidia.com, 18255117159@163.com,
linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] PCI: tegra194: Expose BAR2 (MSI-X) and BAR4 (DMA) as 64-bit BAR_RESERVED
Date: Wed, 25 Feb 2026 18:51:44 +0100 [thread overview]
Message-ID: <aZ82sMy2rbWGQQFt@ryzen> (raw)
In-Reply-To: <20260222193456.2460963-4-mmaddireddy@nvidia.com>
On Mon, Feb 23, 2026 at 01:04:55AM +0530, Manikanta Maddireddy wrote:
> Tegra endpoint exposes three 64-bit BARs at indices 0, 2, and 4:
> - BAR0+BAR1: EPF test/data (programmable 64-bit BAR)
> - BAR2+BAR3: MSI-X table (hardware-backed)
> - BAR4+BAR5: DMA registers (hardware-backed)
>
> Update tegra_pcie_epc_features so BAR2 is BAR_RESERVED with
> PCI_EPC_BAR_RSVD_MSIX_CTRL_MMIO (128KB), BAR3 is BAR_64BIT_UPPER,
> BAR4 is BAR_RESERVED with PCI_EPC_BAR_RSVD_DMA_CTRL_MMIO (4KB), and
> BAR5 is BAR_64BIT_UPPER. This keeps CONSECUTIVE_BAR_TEST working
> while allowing the host to use 64-bit BAR2 (MSI-X) and BAR4 (DMA).
>
> Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
> ---
> drivers/pci/controller/dwc/pcie-tegra194.c | 38 +++++++++++++++++++---
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 3c84a230dc79..b5397a63461f 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c
> @@ -2000,16 +2000,44 @@ static int tegra_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> return 0;
> }
>
> -/* Tegra EP: BAR0 = 64-bit programmable BAR */
> +static const struct pci_epc_bar_rsvd_region tegra194_bar2_rsvd[] = {
> + {
> + /* MSI-X structure */
> + .type = PCI_EPC_BAR_RSVD_MSIX_CTRL_RAM,
> + .offset = 0x0,
> + .size = SZ_128K,
> + },
> +};
> +
> +static const struct pci_epc_bar_rsvd_region tegra194_bar4_rsvd[] = {
> + {
> + /* DMA_CAP (BAR4: DMA Port Logic Structure) */
> + .type = PCI_EPC_BAR_RSVD_DMA_CTRL_MMIO,
> + .offset = 0x0,
> + .size = SZ_4K,
> + },
> +};
> +
> +/* Tegra EP: BAR0 = 64-bit programmable BAR, BAR2 = 64-bit MSI-X table, BAR4 = 64-bit DMA regs. */
> static const struct pci_epc_features tegra_pcie_epc_features = {
> .linkup_notifier = true,
> .msi_capable = true,
> .bar[BAR_0] = { .type = BAR_PROGRAMMABLE, .only_64bit = true, },
> .bar[BAR_1] = { .type = BAR_64BIT_UPPER, },
> - .bar[BAR_2] = { .type = BAR_DISABLED, },
> - .bar[BAR_3] = { .type = BAR_DISABLED, },
> - .bar[BAR_4] = { .type = BAR_DISABLED, },
> - .bar[BAR_5] = { .type = BAR_DISABLED, },
> + .bar[BAR_2] = {
> + .type = BAR_RESERVED,
> + .only_64bit = true,
Here you define a BAR of type BAR_RESERVED as .only_64bit.
In include/linux/pci-epc.h:
"only_64bit should not be set on a BAR of type BAR_RESERVED.
(If BARx is a 64-bit BAR that an EPF driver is not allowed to
reprogram, then both BARx and BARx+1 must be set to type
BAR_RESERVED.)"
However, if we look at pci_epc_get_next_free_bar(), it will
handle this perfectly fine already.
So I think it does make sense to allow a RERSERVED_BAR to have
only_64bit = true after all.
(E.g. if we in the future want to disable the RESERVED BAR,
it is good to know that it is a 64-bit BAR, even if it is
RESERVED, because if we disable it, the disable function will
know that it will need to clear the upper bits/adjecent BAR as
well.)
Perhaps just create a new commit in your series which simply removes
does:
@@ -243,11 +243,6 @@ struct pci_epc_bar_rsvd_region {
* should be configured as 32-bit or 64-bit, the EPF driver must
* configure this BAR as 64-bit. Additionally, the BAR succeeding
* this BAR must be set to type BAR_64BIT_UPPER.
- *
- * only_64bit should not be set on a BAR of type BAR_RESERVED.
- * (If BARx is a 64-bit BAR that an EPF driver is not allowed to
- * reprogram, then both BARx and BARx+1 must be set to type
- * BAR_RESERVED.)
* @nr_rsvd_regions: number of fixed subregions described for BAR_RESERVED
* @rsvd_regions: fixed subregions behind BAR_RESERVED
*/
from include/linux/pci-epc.h.
With the motivation that if the BAR is 64-bit by default, and it is
reserved, it makes sense to set it as only64bit, because that is the most
accurate description, and even if we don't have a disable_bar() function
to disable a BAR that we have not called set_bar() on today (so we can't
disable a reserved BAR today), we might implement it in the future, and
then the disable_bar() function will need to clear the adjecent BAR as
well, so better to describe it as correctly as possible already.
Kind regards,
Niklas
next prev parent reply other threads:[~2026-02-25 17:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-22 19:34 [PATCH 0/4] PCI: endpoint: Add Tegra194/234 BAR layout and pci_endpoint_test support Manikanta Maddireddy
2026-02-22 19:34 ` [PATCH 1/4] PCI: endpoint: Add reserved region type for MSI-X Table and PBA Manikanta Maddireddy
2026-02-25 17:21 ` Niklas Cassel
2026-02-22 19:34 ` [PATCH 2/4] PCI: tegra194: Make BAR0 programmable and remove 1MB size limit Manikanta Maddireddy
2026-02-25 17:31 ` Niklas Cassel
2026-03-03 7:19 ` Manikanta Maddireddy
2026-02-22 19:34 ` [PATCH 3/4] PCI: tegra194: Expose BAR2 (MSI-X) and BAR4 (DMA) as 64-bit BAR_RESERVED Manikanta Maddireddy
2026-02-25 17:51 ` Niklas Cassel [this message]
2026-02-22 19:34 ` [PATCH 4/4] misc: pci_endpoint_test: Add Tegra194 and Tegra234 device table entries Manikanta Maddireddy
2026-02-25 17:58 ` Niklas Cassel
2026-02-25 18:16 ` Niklas Cassel
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=aZ82sMy2rbWGQQFt@ryzen \
--to=cassel@kernel.org \
--cc=18255117159@163.com \
--cc=Frank.Li@nxp.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=den@valinux.co.jp \
--cc=gregkh@linuxfoundation.org \
--cc=hongxing.zhu@nxp.com \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=vidyas@nvidia.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.