Re: Simplification in pbus_size_mem

From: Richard Curnow
Date: Thu Nov 20 2003 - 10:26:59 EST


* Ivan Kokshaysky <ink@xxxxxxxxxxxxxxxxxxxx> [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@xxxxxxxxxx /// rc@xxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/