Re: [PATCH V2] PCI: dwc: Add support to handle prefetchable memory mapping
On 10/23/2020 9:07 PM, Rob Herring wrote:
External email: Use caution opening links or attachments
On Fri, Oct 23, 2020 at 2:38 AM Vidya Sagar wrote:
On 10/23/2020 12:38 AM, Rob Herring wrote:
External email: Use caution opening links or attachments
On Tue, Oct 20, 2020 at 2:59 PM Vidya Sagar wrote:
DWC sub-system currently doesn't differentiate between prefetchable and
non-prefetchable memory aperture entries in the 'ranges' property and
provides ATU mapping only for the first memory aperture entry out of all
the entries present. This was introduced by the
commit 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources").
Mapping for a memory apreture is required if its CPU address and the bus
address are different and the current mechanism works only if the memory
aperture which needs mapping happens to be the first entry. It doesn't
work either if the memory aperture that needs mapping is not the first
entry or if both prefetchable and non-prefetchable apertures need mapping.
Well that's subtle...
This patch fixes this issue by differentiating between prefetchable and
non-prefetchable apertures in the 'ranges' property there by removing the
dependency on the order in which they are specified and adds support for
mapping prefetchable aperture using ATU region-3 if required.
Now you don't do any iATU entry for a 1:1 memory range which is a
change for pretty much every other platform. That means we leave the
PCI transaction config to the whims of how h/w designers hooked up the
sideband signals. I guess this is how Uniphier works as it only has 1
viewport...
I think the assignment should be in this order:
- config space
- non-prefetchable (IIRC, it's required)
- prefetchable
- i/o
Stopping assignment and warning if you run out of viewports. Looking
at the platforms, I think that would always work. There's only
uniphier and ls1012a where we run out. Those would still behave the
same.
As I see from the code this is how the current mapping is done
Region-0: [Fixed] Non-Prefetchable memory mapping
Region-1: [Shared] if the num of view ports <= 2
Used for I/O by default but whenever config space is accessed,
it is programmed to generate config space, and once done, will program
it back for I/O generation. I'm not sure how they are synchonized when
two different entities are trying to access the config space as well as
the I/O at the same time. I don't see any locking mechanism (or am I
missing something here??)
They aren't synchronized. We just get lucky that I/O and config
accesses aren't interleaved frequently. IMO, we should just not
support I/O space on those platforms. AIUI, almost everything doesn't
use I/O nowadays.
[Fixed] if the num of view ports > 2
Used to generate configuration space accesses
Region-2: [Fixed] I/O accesses
Region-3: [Fixed] Prefetchable memory mapping (This patch is adding it)
I honestly think that an attempt to re-assing what region is used for
what purpose should go into a different patch.
Normally, I'd agree for a fix. If you want to fix it in a minimal way
such that we just setup the last memory region instead of the first,
then that's fine. But to implement the review feedback, you will
simply be adding support for multiple memory regions. The ATU doesn't
care about prefetchable or not. I think it will end up being a more
simple implementation if you just do the I/O region last and only if
you have an available.
I'll surely take it up next but would really like to hear from Jingoo
and Gustavo if this breaks any legacy implementations. For now, I'll
just program the ATU irrespective of 1:1 mapping as I want to get ToT
working again on Tegra194.
I agree that I'm removing configuring an iATU region if it is for 1:1
memory mapping. What I heard from our HW designers is that it is the
default behavior of the Synopsys IP that if the CPU access falls in the
aperture owned by Synopsys IP and there is no iATU region mapped to
capture and generate any specific transaction for that address, then, by
default it generates a memory transaction over the PCIe bus.
It is also possible that some implementors might have chosen to alter
this behavior.
If we assume they haven't, that pretty much guarantees they did. :)
Ok. I'll address it in the next version
In any case, I can continue to have the iATU programming
done irrespective of whether it is for 1:1 mapping or not.
Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources")
Link:
http://patchwork.ozlabs.org/project/linux-pci/patch/20200513190855.23318-1-vid...@nvidia.com/
Signed-off-by: Vidya Sagar
---
V2:
* Rewrote commit subject and description
* Addressed review comments from Lorenzo
.../pci/controller/dwc/pcie-designware-host.c | 42 ---
drivers/pci/controller/dwc/pcie-designware.c | 12 +++---
drivers/pci/controller/dwc/pcie-designware.h | 4 +-
3 files changed, 46 insertions(+), 12 deletions(-)
diff
Re: [PATCH V2] PCI: dwc: Add support to handle prefetchable memory mapping
On Fri, Oct 23, 2020 at 2:38 AM Vidya Sagar wrote:
>
>
>
> On 10/23/2020 12:38 AM, Rob Herring wrote:
> > External email: Use caution opening links or attachments
> >
> >
> > On Tue, Oct 20, 2020 at 2:59 PM Vidya Sagar wrote:
> >>
> >> DWC sub-system currently doesn't differentiate between prefetchable and
> >> non-prefetchable memory aperture entries in the 'ranges' property and
> >> provides ATU mapping only for the first memory aperture entry out of all
> >> the entries present. This was introduced by the
> >> commit 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources").
> >> Mapping for a memory apreture is required if its CPU address and the bus
> >> address are different and the current mechanism works only if the memory
> >> aperture which needs mapping happens to be the first entry. It doesn't
> >> work either if the memory aperture that needs mapping is not the first
> >> entry or if both prefetchable and non-prefetchable apertures need mapping.
> >
> > Well that's subtle...
> >
> >> This patch fixes this issue by differentiating between prefetchable and
> >> non-prefetchable apertures in the 'ranges' property there by removing the
> >> dependency on the order in which they are specified and adds support for
> >> mapping prefetchable aperture using ATU region-3 if required.
> >
> > Now you don't do any iATU entry for a 1:1 memory range which is a
> > change for pretty much every other platform. That means we leave the
> > PCI transaction config to the whims of how h/w designers hooked up the
> > sideband signals. I guess this is how Uniphier works as it only has 1
> > viewport...
> >
> > I think the assignment should be in this order:
> > - config space
> > - non-prefetchable (IIRC, it's required)
> > - prefetchable
> > - i/o
> >
> > Stopping assignment and warning if you run out of viewports. Looking
> > at the platforms, I think that would always work. There's only
> > uniphier and ls1012a where we run out. Those would still behave the
> > same.
> As I see from the code this is how the current mapping is done
>
> Region-0: [Fixed] Non-Prefetchable memory mapping
>
> Region-1: [Shared] if the num of view ports <= 2
> Used for I/O by default but whenever config space is accessed,
> it is programmed to generate config space, and once done, will program
> it back for I/O generation. I'm not sure how they are synchonized when
> two different entities are trying to access the config space as well as
> the I/O at the same time. I don't see any locking mechanism (or am I
> missing something here??)
They aren't synchronized. We just get lucky that I/O and config
accesses aren't interleaved frequently. IMO, we should just not
support I/O space on those platforms. AIUI, almost everything doesn't
use I/O nowadays.
>[Fixed] if the num of view ports > 2
> Used to generate configuration space accesses
>
> Region-2: [Fixed] I/O accesses
>
> Region-3: [Fixed] Prefetchable memory mapping (This patch is adding it)
>
> I honestly think that an attempt to re-assing what region is used for
> what purpose should go into a different patch.
Normally, I'd agree for a fix. If you want to fix it in a minimal way
such that we just setup the last memory region instead of the first,
then that's fine. But to implement the review feedback, you will
simply be adding support for multiple memory regions. The ATU doesn't
care about prefetchable or not. I think it will end up being a more
simple implementation if you just do the I/O region last and only if
you have an available.
>
> I agree that I'm removing configuring an iATU region if it is for 1:1
> memory mapping. What I heard from our HW designers is that it is the
> default behavior of the Synopsys IP that if the CPU access falls in the
> aperture owned by Synopsys IP and there is no iATU region mapped to
> capture and generate any specific transaction for that address, then, by
> default it generates a memory transaction over the PCIe bus.
> It is also possible that some implementors might have chosen to alter
> this behavior.
If we assume they haven't, that pretty much guarantees they did. :)
> In any case, I can continue to have the iATU programming
> done irrespective of whether it is for 1:1 mapping or not.
>
> >
> >
> >>
> >> Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources")
> >> Link:
> >> http://patchwork.ozlabs.org/project/linux-pci/patch/20200513190855.23318-1-vid...@nvidia.com/
> >>
> >> Signed-off-by: Vidya Sagar
> >> ---
> >> V2:
> >> * Rewrote commit subject and description
> >> * Addressed review comments from Lorenzo
> >>
> >> .../pci/controller/dwc/pcie-designware-host.c | 42 ---
> >> drivers/pci/controller/dwc/pcie-designware.c | 12 +++---
> >> drivers/pci/controller/dwc/pcie-designware.h | 4 +-
> >> 3 files changed, 46 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> >>
Re: [PATCH V2] PCI: dwc: Add support to handle prefetchable memory mapping
On 10/23/2020 12:38 AM, Rob Herring wrote:
External email: Use caution opening links or attachments
On Tue, Oct 20, 2020 at 2:59 PM Vidya Sagar wrote:
DWC sub-system currently doesn't differentiate between prefetchable and
non-prefetchable memory aperture entries in the 'ranges' property and
provides ATU mapping only for the first memory aperture entry out of all
the entries present. This was introduced by the
commit 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources").
Mapping for a memory apreture is required if its CPU address and the bus
address are different and the current mechanism works only if the memory
aperture which needs mapping happens to be the first entry. It doesn't
work either if the memory aperture that needs mapping is not the first
entry or if both prefetchable and non-prefetchable apertures need mapping.
Well that's subtle...
This patch fixes this issue by differentiating between prefetchable and
non-prefetchable apertures in the 'ranges' property there by removing the
dependency on the order in which they are specified and adds support for
mapping prefetchable aperture using ATU region-3 if required.
Now you don't do any iATU entry for a 1:1 memory range which is a
change for pretty much every other platform. That means we leave the
PCI transaction config to the whims of how h/w designers hooked up the
sideband signals. I guess this is how Uniphier works as it only has 1
viewport...
I think the assignment should be in this order:
- config space
- non-prefetchable (IIRC, it's required)
- prefetchable
- i/o
Stopping assignment and warning if you run out of viewports. Looking
at the platforms, I think that would always work. There's only
uniphier and ls1012a where we run out. Those would still behave the
same.
As I see from the code this is how the current mapping is done
Region-0: [Fixed] Non-Prefetchable memory mapping
Region-1: [Shared] if the num of view ports <= 2
Used for I/O by default but whenever config space is accessed,
it is programmed to generate config space, and once done, will program
it back for I/O generation. I'm not sure how they are synchonized when
two different entities are trying to access the config space as well as
the I/O at the same time. I don't see any locking mechanism (or am I
missing something here??)
[Fixed] if the num of view ports > 2
Used to generate configuration space accesses
Region-2: [Fixed] I/O accesses
Region-3: [Fixed] Prefetchable memory mapping (This patch is adding it)
I honestly think that an attempt to re-assing what region is used for
what purpose should go into a different patch.
I agree that I'm removing configuring an iATU region if it is for 1:1
memory mapping. What I heard from our HW designers is that it is the
default behavior of the Synopsys IP that if the CPU access falls in the
aperture owned by Synopsys IP and there is no iATU region mapped to
capture and generate any specific transaction for that address, then, by
default it generates a memory transaction over the PCIe bus.
It is also possible that some implementors might have chosen to alter
this behavior. In any case, I can continue to have the iATU programming
done irrespective of whether it is for 1:1 mapping or not.
Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources")
Link:
http://patchwork.ozlabs.org/project/linux-pci/patch/20200513190855.23318-1-vid...@nvidia.com/
Signed-off-by: Vidya Sagar
---
V2:
* Rewrote commit subject and description
* Addressed review comments from Lorenzo
.../pci/controller/dwc/pcie-designware-host.c | 42 ---
drivers/pci/controller/dwc/pcie-designware.c | 12 +++---
drivers/pci/controller/dwc/pcie-designware.h | 4 +-
3 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index db547ee6ff3a..dae6da39bb90 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -521,9 +521,42 @@ static struct pci_ops dw_pcie_ops = {
.write = pci_generic_config_write,
};
+static void dw_pcie_setup_mem_atu(struct pcie_port *pp,
+ struct resource_entry *win)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+
+ /* Check for prefetchable memory aperture */
+ if (win->res->flags & IORESOURCE_PREFETCH && win->offset) {
+ /* Number of view ports must at least be 4 to enable mapping */
+ if (pci->num_viewport < 4) {
+ dev_warn(pci->dev,
+"Insufficient ATU regions to map Prefetchable
memory\n");
+ } else {
+ dw_pcie_prog_outbound_atu(pci,
+ PCIE_ATU_REGION_INDEX3,
+ PCIE_ATU_TYPE_MEM,
+
Re: [PATCH V2] PCI: dwc: Add support to handle prefetchable memory mapping
On Tue, Oct 20, 2020 at 2:59 PM Vidya Sagar wrote:
>
> DWC sub-system currently doesn't differentiate between prefetchable and
> non-prefetchable memory aperture entries in the 'ranges' property and
> provides ATU mapping only for the first memory aperture entry out of all
> the entries present. This was introduced by the
> commit 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources").
> Mapping for a memory apreture is required if its CPU address and the bus
> address are different and the current mechanism works only if the memory
> aperture which needs mapping happens to be the first entry. It doesn't
> work either if the memory aperture that needs mapping is not the first
> entry or if both prefetchable and non-prefetchable apertures need mapping.
Well that's subtle...
> This patch fixes this issue by differentiating between prefetchable and
> non-prefetchable apertures in the 'ranges' property there by removing the
> dependency on the order in which they are specified and adds support for
> mapping prefetchable aperture using ATU region-3 if required.
Now you don't do any iATU entry for a 1:1 memory range which is a
change for pretty much every other platform. That means we leave the
PCI transaction config to the whims of how h/w designers hooked up the
sideband signals. I guess this is how Uniphier works as it only has 1
viewport...
I think the assignment should be in this order:
- config space
- non-prefetchable (IIRC, it's required)
- prefetchable
- i/o
Stopping assignment and warning if you run out of viewports. Looking
at the platforms, I think that would always work. There's only
uniphier and ls1012a where we run out. Those would still behave the
same.
>
> Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources")
> Link:
> http://patchwork.ozlabs.org/project/linux-pci/patch/20200513190855.23318-1-vid...@nvidia.com/
>
> Signed-off-by: Vidya Sagar
> ---
> V2:
> * Rewrote commit subject and description
> * Addressed review comments from Lorenzo
>
> .../pci/controller/dwc/pcie-designware-host.c | 42 ---
> drivers/pci/controller/dwc/pcie-designware.c | 12 +++---
> drivers/pci/controller/dwc/pcie-designware.h | 4 +-
> 3 files changed, 46 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index db547ee6ff3a..dae6da39bb90 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -521,9 +521,42 @@ static struct pci_ops dw_pcie_ops = {
> .write = pci_generic_config_write,
> };
>
> +static void dw_pcie_setup_mem_atu(struct pcie_port *pp,
> + struct resource_entry *win)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +
> + /* Check for prefetchable memory aperture */
> + if (win->res->flags & IORESOURCE_PREFETCH && win->offset) {
> + /* Number of view ports must at least be 4 to enable mapping
> */
> + if (pci->num_viewport < 4) {
> + dev_warn(pci->dev,
> +"Insufficient ATU regions to map
> Prefetchable memory\n");
> + } else {
> + dw_pcie_prog_outbound_atu(pci,
> + PCIE_ATU_REGION_INDEX3,
> + PCIE_ATU_TYPE_MEM,
> + win->res->start,
> + win->res->start -
> win->offset,
> + resource_size(win->res));
> + }
> + } else if (win->offset) { /* Non-prefetchable memory aperture */
> + if (upper_32_bits(resource_size(win->res)))
> + dev_warn(pci->dev,
> +"Memory resource size exceeds max for 32
> bits\n");
This is not designware specific. Either core code should check this or
write a DT schema to check it.
> + dw_pcie_prog_outbound_atu(pci,
> + PCIE_ATU_REGION_INDEX0,
> + PCIE_ATU_TYPE_MEM,
> + win->res->start,
> + win->res->start - win->offset,
> + resource_size(win->res));
> + }
> +}
> +
> void dw_pcie_setup_rc(struct pcie_port *pp)
> {
> u32 val, ctrl, num_ctrls;
> + struct resource_entry *win;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>
> /*
> @@ -578,13 +611,10 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
> * ATU, so we should not program the ATU here.
> */
> if (pp->bridge->child_ops == _child_pcie_ops) {
> - struct resource_entry *entry =
> -
Re: [PATCH V2] PCI: dwc: Add support to handle prefetchable memory mapping
Jingoo, Gustavo,
please review this patch, thanks.
Lorenzo
On Wed, Oct 21, 2020 at 01:29:31AM +0530, Vidya Sagar wrote:
> DWC sub-system currently doesn't differentiate between prefetchable and
> non-prefetchable memory aperture entries in the 'ranges' property and
> provides ATU mapping only for the first memory aperture entry out of all
> the entries present. This was introduced by the
> commit 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources").
> Mapping for a memory apreture is required if its CPU address and the bus
> address are different and the current mechanism works only if the memory
> aperture which needs mapping happens to be the first entry. It doesn't
> work either if the memory aperture that needs mapping is not the first
> entry or if both prefetchable and non-prefetchable apertures need mapping.
>
> This patch fixes this issue by differentiating between prefetchable and
> non-prefetchable apertures in the 'ranges' property there by removing the
> dependency on the order in which they are specified and adds support for
> mapping prefetchable aperture using ATU region-3 if required.
>
> Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources")
> Link:
> http://patchwork.ozlabs.org/project/linux-pci/patch/20200513190855.23318-1-vid...@nvidia.com/
>
> Signed-off-by: Vidya Sagar
> ---
> V2:
> * Rewrote commit subject and description
> * Addressed review comments from Lorenzo
>
> .../pci/controller/dwc/pcie-designware-host.c | 42 ---
> drivers/pci/controller/dwc/pcie-designware.c | 12 +++---
> drivers/pci/controller/dwc/pcie-designware.h | 4 +-
> 3 files changed, 46 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index db547ee6ff3a..dae6da39bb90 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -521,9 +521,42 @@ static struct pci_ops dw_pcie_ops = {
> .write = pci_generic_config_write,
> };
>
> +static void dw_pcie_setup_mem_atu(struct pcie_port *pp,
> + struct resource_entry *win)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> +
> + /* Check for prefetchable memory aperture */
> + if (win->res->flags & IORESOURCE_PREFETCH && win->offset) {
> + /* Number of view ports must at least be 4 to enable mapping */
> + if (pci->num_viewport < 4) {
> + dev_warn(pci->dev,
> + "Insufficient ATU regions to map Prefetchable
> memory\n");
> + } else {
> + dw_pcie_prog_outbound_atu(pci,
> + PCIE_ATU_REGION_INDEX3,
> + PCIE_ATU_TYPE_MEM,
> + win->res->start,
> + win->res->start - win->offset,
> + resource_size(win->res));
> + }
> + } else if (win->offset) { /* Non-prefetchable memory aperture */
> + if (upper_32_bits(resource_size(win->res)))
> + dev_warn(pci->dev,
> + "Memory resource size exceeds max for 32
> bits\n");
> + dw_pcie_prog_outbound_atu(pci,
> + PCIE_ATU_REGION_INDEX0,
> + PCIE_ATU_TYPE_MEM,
> + win->res->start,
> + win->res->start - win->offset,
> + resource_size(win->res));
> + }
> +}
> +
> void dw_pcie_setup_rc(struct pcie_port *pp)
> {
> u32 val, ctrl, num_ctrls;
> + struct resource_entry *win;
> struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
>
> /*
> @@ -578,13 +611,10 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
>* ATU, so we should not program the ATU here.
>*/
> if (pp->bridge->child_ops == _child_pcie_ops) {
> - struct resource_entry *entry =
> - resource_list_first_type(>bridge->windows,
> IORESOURCE_MEM);
> + resource_list_for_each_entry(win, >bridge->windows)
> + if (resource_type(win->res) == IORESOURCE_MEM)
> + dw_pcie_setup_mem_atu(pp, win);
>
> - dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX0,
> - PCIE_ATU_TYPE_MEM, entry->res->start,
> - entry->res->start - entry->offset,
> - resource_size(entry->res));
> if (pci->num_viewport > 2)
> dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX2,
> PCIE_ATU_TYPE_IO, pp->io_base,
> diff
[PATCH V2] PCI: dwc: Add support to handle prefetchable memory mapping
DWC sub-system currently doesn't differentiate between prefetchable and
non-prefetchable memory aperture entries in the 'ranges' property and
provides ATU mapping only for the first memory aperture entry out of all
the entries present. This was introduced by the
commit 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources").
Mapping for a memory apreture is required if its CPU address and the bus
address are different and the current mechanism works only if the memory
aperture which needs mapping happens to be the first entry. It doesn't
work either if the memory aperture that needs mapping is not the first
entry or if both prefetchable and non-prefetchable apertures need mapping.
This patch fixes this issue by differentiating between prefetchable and
non-prefetchable apertures in the 'ranges' property there by removing the
dependency on the order in which they are specified and adds support for
mapping prefetchable aperture using ATU region-3 if required.
Fixes: 0f71c60ffd26 ("PCI: dwc: Remove storing of PCI resources")
Link:
http://patchwork.ozlabs.org/project/linux-pci/patch/20200513190855.23318-1-vid...@nvidia.com/
Signed-off-by: Vidya Sagar
---
V2:
* Rewrote commit subject and description
* Addressed review comments from Lorenzo
.../pci/controller/dwc/pcie-designware-host.c | 42 ---
drivers/pci/controller/dwc/pcie-designware.c | 12 +++---
drivers/pci/controller/dwc/pcie-designware.h | 4 +-
3 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
b/drivers/pci/controller/dwc/pcie-designware-host.c
index db547ee6ff3a..dae6da39bb90 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -521,9 +521,42 @@ static struct pci_ops dw_pcie_ops = {
.write = pci_generic_config_write,
};
+static void dw_pcie_setup_mem_atu(struct pcie_port *pp,
+ struct resource_entry *win)
+{
+ struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
+
+ /* Check for prefetchable memory aperture */
+ if (win->res->flags & IORESOURCE_PREFETCH && win->offset) {
+ /* Number of view ports must at least be 4 to enable mapping */
+ if (pci->num_viewport < 4) {
+ dev_warn(pci->dev,
+"Insufficient ATU regions to map Prefetchable
memory\n");
+ } else {
+ dw_pcie_prog_outbound_atu(pci,
+ PCIE_ATU_REGION_INDEX3,
+ PCIE_ATU_TYPE_MEM,
+ win->res->start,
+ win->res->start - win->offset,
+ resource_size(win->res));
+ }
+ } else if (win->offset) { /* Non-prefetchable memory aperture */
+ if (upper_32_bits(resource_size(win->res)))
+ dev_warn(pci->dev,
+"Memory resource size exceeds max for 32
bits\n");
+ dw_pcie_prog_outbound_atu(pci,
+ PCIE_ATU_REGION_INDEX0,
+ PCIE_ATU_TYPE_MEM,
+ win->res->start,
+ win->res->start - win->offset,
+ resource_size(win->res));
+ }
+}
+
void dw_pcie_setup_rc(struct pcie_port *pp)
{
u32 val, ctrl, num_ctrls;
+ struct resource_entry *win;
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
/*
@@ -578,13 +611,10 @@ void dw_pcie_setup_rc(struct pcie_port *pp)
* ATU, so we should not program the ATU here.
*/
if (pp->bridge->child_ops == _child_pcie_ops) {
- struct resource_entry *entry =
- resource_list_first_type(>bridge->windows,
IORESOURCE_MEM);
+ resource_list_for_each_entry(win, >bridge->windows)
+ if (resource_type(win->res) == IORESOURCE_MEM)
+ dw_pcie_setup_mem_atu(pp, win);
- dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_TYPE_MEM, entry->res->start,
- entry->res->start - entry->offset,
- resource_size(entry->res));
if (pci->num_viewport > 2)
dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX2,
PCIE_ATU_TYPE_IO, pp->io_base,
diff --git a/drivers/pci/controller/dwc/pcie-designware.c
b/drivers/pci/controller/dwc/pcie-designware.c
index c2dea8fc97c8..b5e438b70cd5 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++
