Dear Gerlando Falauto,
On Fri, 21 Feb 2014 10:16:32 +0100, Gerlando Falauto wrote:
> > Sure, but whichever choice we make, the Linux PCI core must know by how
> > much we've enlarge the bridge window BAR, otherwise the Linux PCI core
> > may allocate for the next bridge window BAR a range of addresses that
> > doesn't overlap with what it has allocate for the previous bridge
> > window BAR, but that ends up overlapping due to us "extending" the
> > previous bridge window BAR to match the MBus requirements.
> >
> > Gerlando, would you be able to test a quick hack that creates 2 windows
> > to cover exactly 128 MB + 64 MB ? This would at least allow us to
> > confirm that the strategy of splitting in multiple windows is usable.
>
> Sure, though probably not until next week.
No problem at all.
> I guess it would then also be useful to restore my previous setup, where
> the total PCIe aperture is 192MB, right?
Yes, that's the case I'm interested in at the moment. If you could try
the above (ugly) patch, and see if you can access all your device BARs,
it would be interesting. It would tell us if two separate windows
having the same target/attribute and consecutive placement in the
physical address space can actually work to address a given PCIe
device. As you will see, the patch makes a very ugly special case for
192 MB :-)
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 2394e97..f763ecc 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -223,11 +223,13 @@ static int mvebu_mbus_window_conflicts(struct mvebu_mbus_state *mbus,
if ((u64)base < wend && end > wbase)
return 0;
+#if 0
/*
* Check if target/attribute conflicts
*/
if (target == wtarget && attr == wattr)
return 0;
+#endif
}
return 1;
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 2aa7b77c..67fe6df 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -361,8 +361,15 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
(((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) -
port->memwin_base;
- mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
- port->memwin_base, port->memwin_size);
+ if (port->memwin_size == (SZ_128M + SZ_64M)) {
+ mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+ port->memwin_base, SZ_128M);
+ mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+ port->memwin_base + SZ_128M, SZ_64M);
+ } else {
+ mvebu_mbus_add_window_by_id(port->mem_target, port->mem_attr,
+ port->memwin_base, port->memwin_size);
+ }
}
/*
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
