Gerlando, Bjorn, Bjorn, I added you as the To: because there is a PCI related question for you below :) On Wed, 19 Feb 2014 10:39:07 +0100, Gerlando Falauto wrote: > spoiler first: SUCCESS!!!! Awesome :) > > I'm obviously interested in seeing the message that gets shown, as well > > as the new mvebu-mbus debugfs output. > > ---------- > pci 0000:00:01.0: bridge window [mem 0xe0000000-0xebffffff] > PCIE 0.0: creating window at 0xe0000000, size 0xbffffff rounded up to > 0x10000000 Right, rounding from 192 MB to 265 MB. > cat /sys/kernel/debug/mvebu-mbus/devices > [00] disabled > [01] disabled > [02] disabled > [03] disabled > [04] 00000000ff000000 - 00000000ff010000 : nand > [05] 00000000f4000000 - 00000000f8000000 : vpcie > [06] 00000000fe000000 - 00000000fe010000 : dragonite > [07] 00000000e0000000 - 00000000f0000000 : pcie0.0 > > > For good measure, if you could also dump the registers of the PCIe > > window. In your case, it was window 7, so dumping 0xf1020070 and > > 0xf1020074 would be useful. > > Isn't that where the output of debugfs comes from? It is, but the mvebu-mbus is interpreting the sequence of 1s and 0s to give the real size, and this involves a little bit of magic of bit manipulation, which I wanted to check by having a look at the raw values of the registers. > > I am not sure, but since we are configuring an invalid memory size, > > maybe the MBus behavior is undefined, and we get some completely funky > > behavior, where parts of the 192 MB window are actually work, but parts > > of it are not. > > And... Ladies and gentlemen... it turns out YOU'RE RIGHT!!! > With your patch now everything works fine!!! > > No words (or quads, for that matter) can express how grateful I am! ;-) Cool. However, I am not sure my fix is really correct, because is you had another PCIe device that needed 64 MB of memory space, the PCIe core would have allocated addresses 0xec000000 -> 0xf0000000 to it, which would have conflicted with the forced "power of 2 up-rounding" we've applied on the memory space of the first device. Therefore, I believe this constraint should be taken into account by the PCIe core when allocating the different memory regions for each device. Bjorn, the mvebu PCIe host driver has the constraint that the I/O and memory regions associated to each PCIe device of the emulated bridge have a size that is a power of 2. I am currently using the ->align_resource() hook to ensure that the start address of the resource matches certain other constraints, but I don't see a way of telling the PCI core that I need the resource to have its size rounded up to the next power of 2 size. Is there a way of doing this? In the case described by Gerlando, the PCI core has assigned a 192 MB region, but the Marvell hardware can only create windows that have a power of two size, i.e 256 MB. Therefore, the PCI core should be told this constraint, so that it doesn't allocate the next resource right after the 192 MB one. Thanks! Thomas -- 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
