pci-mvebu driver on km_kirkwood
gerlando.falauto at keymile.com
Fri Feb 21 13:18:25 EST 2014
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
>>  00000000e8000000 - 00000000ec000000 : pcie0.0 (remap 00000000e8000000)
>>  disabled
>>  disabled
>>  disabled
>>  00000000ff000000 - 00000000ff010000 : nand
>>  00000000f4000000 - 00000000f8000000 : vpcie
>>  00000000fe000000 - 00000000fe010000 : dragonite
>>  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.
More information about the linux-arm-kernel