Messages in this thread | | | Date | Thu, 20 Nov 2003 15:25:58 +0000 | From | Richard Curnow <> | Subject | Re: Simplification in pbus_size_mem |
| |
* Ivan Kokshaysky <ink@jurassic.park.msu.ru> [2003-11-20]: > On Thu, Nov 20, 2003 at 12:28:38PM +0000, Richard Curnow wrote: > > * 96Mb PCI memory aperture > > Also there is a PCI-PCI bridge, I guess? ;-)
Yes. 'cat /proc/pci' (with my patch so the USB card gets allocations) gives
Bus 0, device 2, function 0: PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 6). Master Capable. Latency=32. Min Gnt=12. Bus 1, device 9, function 0: USB Controller: Lucent Microelectronics USS-344S USB Controller (rev 17). IRQ 4. Master Capable. Latency=32. Min Gnt=3.Max Lat=86. Non-prefetchable 32 bit memory at 0x14100000 [0x14100fff]. Bus 1, device 9, function 1: USB Controller: Lucent Microelectronics USS-344S USB Controller (#2) (rev 17). IRQ 4. Master Capable. Latency=32. Min Gnt=3.Max Lat=86. Non-prefetchable 32 bit memory at 0x14101000 [0x14101fff]. Bus 1, device 9, function 2: USB Controller: Lucent Microelectronics USS-344S USB Controller (#3) (rev 17). IRQ 4. Master Capable. Latency=32. Min Gnt=3.Max Lat=86. Non-prefetchable 32 bit memory at 0x14102000 [0x14102fff]. Bus 1, device 9, function 3: USB Controller: Lucent Microelectronics USS-344S USB Controller (#4) (rev 17). IRQ 4. Master Capable. Latency=32. Min Gnt=3.Max Lat=86. Non-prefetchable 32 bit memory at 0x14103000 [0x14103fff]. Bus 1, device 11, function 0: VGA compatible controller: SGS Thomson Microelectronics STG4000 [3D Prophet Kyro Series] (rev 1). IRQ 2. Master Capable. Latency=32. Prefetchable 32 bit memory at 0x10000000 [0x13ffffff]. Prefetchable 32 bit memory at 0x14000000 [0x1407ffff]. I/O at 0x2000 [0x20ff]. Bus 1, device 12, function 0: Ethernet controller: SGS Thomson Microelectronics DEC-Tulip compatible 10/100 Ethernet (rev 161). IRQ 1. Master Capable. Latency=32. Min Gnt=255.Max Lat=255. I/O at 0x2400 [0x24ff]. Non-prefetchable 32 bit memory at 0x14104000 [0x141040ff].
(This is an SH-4 platform.)
> 768Kb sounds strange. It must be power of 2. Perhaps it's 512Kb MMIO > and 256Kb ROM? But MMIO registers must be non-prefetchable. Weird.
Looks like it's actually 512kB. I'm not sure why I thought it was 768kB.
> > alignment requirement that was found?), hence in the pass where the > > prefetchable block is sized, 'size' ends up as 96Mb, which means there > > is no space left in which to place the non-prefetchable blocks for the > > USB card. > > Yes, it's a trade-off - minimizing alignment vs. size requirements. > In most situations the former approach gives much better allocations.
So is the idea that by rounding up 'size' to 96Mb in this case, it's guaranteed that there will be a 64Mb aligned chunk inside where the framebuffer can go, still leaving enough room around for the other allocation, _regardless_ of the alignment of the base of the memory aperture? (Or if there are multiple PCI-to-PCI bridges, the aperture base for any one bridge is going to depend on the sizes of the apertures forwarded by the others, I suppose).
If this is so, I can begin to see what the loop in the existing code is doing.
> > > With the patch above, the alignment requirement for the prefetchable > > memory actually ends up as the alignment required for the framebuffer, > > and the size isn't rounded up unnecessarily. The USB card gets > > allocated successfully as a result. > > Well, it works only because your 96Mb PCI aperture is aligned at 64Mb > (or more).
It's aligned at 256Mb in fact, as shown above.
> If it was aligned at 32Mb, you wouldn't be able to allocate > prefetchable memory at all with your patch.
Good point.
I'll think about this some more.
> As a workaround, you can mark those additional 768Kb regions as > non-prefetchable and be done with it.
How do I do that?
Many thanks for your help Richard
-- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// richard.curnow@superh.com /// rc@rc0.org.uk Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |