Dear Thomas,
On 02/21/2014 02:47 PM, Thomas Petazzoni wrote:
Dear Gerlando Falauto,
On Fri, 21 Feb 2014 13:24:36 +0100, Gerlando Falauto wrote:
So I restored the total aperture size to 192MB.
I had to rework your patch a bit because:
a) I'm running an older kernel and driver
b) sizes are actually 1-byte offset
Hum, right. This is a bit weird, maybe I should change that, I don't
think the mvebu-mbus driver should accept 1-byte offset sizes.
I don't know anything about this, I only know the size dumped is of the
form 0x...ffff, that's all.
Here's the assignment (same as before):
pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xebffffff]
pci 0000:01:00.0: BAR 1: assigned [mem 0xe0000000-0xe7ffffff]
pci 0000:01:00.0: BAR 3: assigned [mem 0xe8000000-0xe87fffff]
pci 0000:01:00.0: BAR 4: assigned [mem 0xe8800000-0xe8801fff]
pci 0000:01:00.0: BAR 0: assigned [mem 0xe8802000-0xe8802fff]
pci 0000:01:00.0: BAR 2: assigned [mem 0xe8803000-0xe8803fff]
pci 0000:01:00.0: BAR 5: assigned [mem 0xe8804000-0xe8804fff]
And here's the output I get from:
# cat /sys/kernel/debug/mvebu-mbus/devices
[00] 00000000e8000000 - 00000000ec000000 : pcie0.0 (remap 00000000e8000000)
[01] disabled
[02] disabled
[03] disabled
[04] 00000000ff000000 - 00000000ff010000 : nand
[05] 00000000f4000000 - 00000000f8000000 : vpcie
[06] 00000000fe000000 - 00000000fe010000 : dragonite
[07] 00000000e0000000 - 00000000e8000000 : pcie0.0
This seems correct: we have two windows pointing to the same device,
and they have consecutive addresses.
I don't know how to interpret the (remap ... ) bit, but yes, this looks
right to me as well. I just don't know why mbus window 7 gets picked
before 0, but apart from that, it looks nice.
I did not get to test the whole address space thoroughly, but all the
BARs are still accessible (mainly BAR0 which contains the control space
and is mapped on the "new" MBUS window, and BAR1 which is the "big"
one). So at least, the issues we had before are now gone.
Did you check that what you read from BAR0 (which is mapped on the new
MBUS window) is really what you expect, and not just the same thing as
BAR1 accessible for the big window? I just want to make sure that the
hardware indeed properly handles two windows for the same device.
Yes, there's no way the two BARs could be aliased. It's a fairly complex
FPGA design, where BAR1 is the huge address space for a PCI-to-localbus
bridge (whose connected devices are recognized correctly) and BAR0 is
the control BAR (and its registers are read and written without a problem).
So I'd say this looks like a very promising approach. :-)
Indeed. However, I don't think this approach solves the entire problem,
for two reasons:
*) For small BARs that are not power-of-two sized, we may not want to
consume two windows, but instead consume a little bit more address
space. Using two windows to map a 96 KB BAR would be a waste of
windows: using a single 128 KB window is much more efficient.
*) I don't know if the algorithm to split the BAR into multiple
windows is going to be trivial.
I see others have already replied and I pretty much agree with them.
Thanks,
Gerlando
--
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
