public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox