From: Niklas Cassel <niklas.cassel@axis.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: kishon@ti.com, Bjorn Helgaas <bhelgaas@google.com>,
Sekhar Nori <nsekhar@ti.com>, John Keeping <john@metanate.com>,
Shawn Lin <shawn.lin@rock-chips.com>,
Cyrille Pitchen <cyrille.pitchen@free-electrons.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t
Date: Sat, 17 Mar 2018 01:55:13 +0100 [thread overview]
Message-ID: <20180317005513.GB22414@axis.com> (raw)
In-Reply-To: <20180316180220.GA13505@red-moon>
On Fri, Mar 16, 2018 at 06:02:20PM +0000, Lorenzo Pieralisi wrote:
> On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote:
> > If a BAR supports 64-bit width or not depends on the hardware,
> > and should thus not depend on sizeof(dma_addr_t).
> >
> > Since this driver is generic, default to always using BAR width
> > of 32-bits. 64-bit BARs can easily be tested by replacing
> > PCI_BASE_ADDRESS_MEM_TYPE_32 with PCI_BASE_ADDRESS_MEM_TYPE_64
> > in bar_flags.
> >
> > Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
> > ---
> > Note to Lorenzo/Bjorn:
> > It is not trivial to convert the bar_size + bar_flags +
> > struct pci_epf->bar member array to an array of struct resources,
> > since we need to be able to store the addresses returned
> > by dma_alloc_coherent(), which is of type dma_addr_t.
> > struct resource uses resource_size_t, which is defined as phys_addr_t.
> > E.g. ARTPEC-7 uses 64-bit dma_addr_t, but only 32-bit phys_addr_t.
> >
> > drivers/pci/endpoint/functions/pci-epf-test.c | 15 +++++++++------
> > 1 file changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > index 800da09d9005..7c70433b11a7 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > @@ -71,6 +71,14 @@ struct pci_epf_test_data {
> > };
> >
> > static int bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
> > +static int bar_flags[] = {
> > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32,
> > + PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_32
> > +};
>
> Niklas,
>
> I think you are almost there, I have one question though to address
> that can even simplify the patchset.
>
> If, according to your own commit logs (and my reading of the code), the
> Cadence driver makes a decision on the BAR size just by checking the
> corresponding region size (I would be happy to hear the reason
> underpinning that choice, BTW), why can't we do the same for DWC (ie to
> let the DWC driver decides whether a BAR should be 64 or 32 bits ?)
We could, but I think that would be a mistake.
The API that the user/"endpoint function" has available to configure
the BARs:
pci_epc_set_bar()
If the user, for some reason, wants to configure a BAR with a
64-bit width, even though the BAR size is less than 4 GB,
I think that the API should allow that.
This would not be possible if pci_epc_set_bar() would start to
ignore PCI_BASE_ADDRESS_MEM_TYPE_64 from the flags parameter
(and BAR width thus only being controlled by the size parameter).
int pci_epc_set_bar(struct pci_epc *epc, u8 func_no, enum pci_barno bar,
dma_addr_t bar_phys, size_t size, int flags);
Best regards,
Niklas
next prev parent reply other threads:[~2018-03-17 0:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-08 13:33 [PATCH v4 0/5] PCI endpoint 64-bit BAR fixes Niklas Cassel
2018-03-08 13:33 ` [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t Niklas Cassel
2018-03-16 18:02 ` Lorenzo Pieralisi
2018-03-17 0:55 ` Niklas Cassel [this message]
2018-03-19 12:36 ` Lorenzo Pieralisi
2018-03-21 5:29 ` Kishon Vijay Abraham I
2018-03-08 13:33 ` [PATCH v4 2/5] PCI: designware-ep: Make dw_pcie_ep_set_bar() handle 64-bit BARs properly Niklas Cassel
2018-03-21 5:49 ` Kishon Vijay Abraham I
2018-03-08 13:33 ` [PATCH v4 3/5] PCI: designware-ep: Make dw_pcie_ep_reset_bar() " Niklas Cassel
2018-03-21 5:54 ` Kishon Vijay Abraham I
2018-03-08 13:33 ` [PATCH v4 4/5] PCI: endpoint: Make pci_epc_set_bar() return the BAR width that was set-up Niklas Cassel
2018-03-21 6:06 ` Kishon Vijay Abraham I
2018-03-08 13:33 ` [PATCH v4 5/5] misc: pci_endpoint_test: Handle 64-bit BARs properly Niklas Cassel
2018-03-15 13:22 ` Greg Kroah-Hartman
2018-03-16 12:55 ` Niklas Cassel
2018-03-21 3:59 ` Niklas Cassel
2018-03-21 9:22 ` Greg Kroah-Hartman
2018-03-21 5:55 ` Kishon Vijay Abraham I
2018-03-19 16:52 ` [PATCH v4 0/5] PCI endpoint 64-bit BAR fixes Lorenzo Pieralisi
2018-03-21 4:10 ` 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=20180317005513.GB22414@axis.com \
--to=niklas.cassel@axis.com \
--cc=bhelgaas@google.com \
--cc=cyrille.pitchen@free-electrons.com \
--cc=john@metanate.com \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=nsekhar@ti.com \
--cc=shawn.lin@rock-chips.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.