All of lore.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: Shradha Todi <shradha.t@samsung.com>
Cc: lchen.firstlove@zohomail.com, lpieralisi@kernel.org,
	kw@linux.com, mani@kernel.org, kishon@kernel.org,
	bhelgaas@google.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, pankaj.dubey@samsung.com
Subject: Re: [PATCH v4] PCI: endpoint: Add prefetch BAR support
Date: Thu, 29 Feb 2024 10:56:43 +0100	[thread overview]
Message-ID: <ZeBU23Ccvv8WqFx_@fedora> (raw)
In-Reply-To: <20240228134448.56372-1-shradha.t@samsung.com>

On Wed, Feb 28, 2024 at 07:14:48PM +0530, Shradha Todi wrote:
> Reviewed-by: Shradha Todi <shradha.t@samsung.com>
> 
> This patch looks useful. Can we revisit this and get it merged?

Hello Shradha,

This patch is two years old, and no longer applies to pci-next.


However:
Usually, fixed hardware requirements are specified in
struct pci_epc_features (more specifically struct pci_epc_bar_desc).

A requested BAR configuration by an EPF is specified in struct epf_bar.


I don't think that Prefetch is a fixed hardware requirement,
so I do not think that we should put it in struct pci_epc_features.

It seems more like something that an endpoint function driver can
chose to request (or not to request), just like MEM_TYPE_64.

From the PCIe base spec:
"Generally only 64-bit BARs are good candidates, since only Legacy
Endpoints are permitted to set the Prefetchable bit in 32-bit BARs,
and most scalable platforms map all 32-bit Memory BARs into
non-prefetchable Memory Space regardless of the Prefetchable bit value."

"For a PCI Express Endpoint, 64-bit addressing must be supported for all BARs
that have the Prefetchable bit Set. 32-bit addressing is permitted for all BARs
that do not have the Prefetchable bit Set."

"Any device that has a range that behaves like normal memory should mark the
range as prefetchable. A linear frame buffer in a graphics device is an example
of a range that should be marked prefetchable."

We are not a legacy endpoint, so we should never set Prefetch for 32-bit BARs.
For 64-bit BARs, we should always set it, if the EPF-core allocated the memory
(regular memory) for that BAR.


Thus, I think the best solution is to do:

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index cd4ffb39dcdc..186c8cd87bb3 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -879,7 +879,8 @@ static void pci_epf_configure_bar(struct pci_epf *epf,
        for (i = 0; i < PCI_STD_NUM_BARS; i++) {
                epf_bar = &epf->bar[i];
                if (epc_features->bar[i].only_64bit)
-                       epf_bar->flags |= PCI_BASE_ADDRESS_MEM_TYPE_64;
+                       epf_bar->flags |= (PCI_BASE_ADDRESS_MEM_TYPE_64 |
+                                          PCI_BASE_ADDRESS_MEM_PREFETCH);
        }
 }
 
diff --git a/drivers/pci/endpoint/pci-epf-core.c b/drivers/pci/endpoint/pci-epf-core.c
index 0a28a0b0911b..acb93055181b 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -305,7 +305,8 @@ void *pci_epf_alloc_space(struct pci_epf *epf, size_t size, enum pci_barno bar,
        epf_bar[bar].size = size;
        epf_bar[bar].barno = bar;
        epf_bar[bar].flags |= upper_32_bits(size) ?
-                               PCI_BASE_ADDRESS_MEM_TYPE_64 :
+                               (PCI_BASE_ADDRESS_MEM_TYPE_64 |
+                                PCI_BASE_ADDRESS_MEM_PREFETCH) :
                                PCI_BASE_ADDRESS_MEM_TYPE_32;
 
        return space;


Now when I look at it, the whole "if (epc_features->bar[i].only_64bit)"
should move to pci_epf_alloc_space() IMO, so that not all EPF drivers need to
duplicate this code.


Kind regards,
Niklas

      reply	other threads:[~2024-02-29  9:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20240228134451epcas5p1b974d61fcab67fb5f52a7b291cf85966@epcas5p1.samsung.com>
2022-01-21  4:12 ` [PATCH v4] PCI: endpoint: Add prefetch BAR support Li Chen
2022-02-09  3:04   ` Li Chen
2024-02-28 13:44   ` Shradha Todi
2024-02-29  9:56     ` Niklas Cassel [this message]

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=ZeBU23Ccvv8WqFx_@fedora \
    --to=cassel@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=kishon@kernel.org \
    --cc=kw@linux.com \
    --cc=lchen.firstlove@zohomail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=pankaj.dubey@samsung.com \
    --cc=shradha.t@samsung.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.