Re: PCI ROM resource allocation issue with 2.6.17-rc2

From: Linus Torvalds
Date: Wed Apr 26 2006 - 01:07:13 EST




On Wed, 26 Apr 2006, Dave Airlie wrote:
>
> my secondary head is being assigned non-prefetchable resources outside
> the bridge,
> PCI: Transparent bridge - 0000:00:1e.0

Note that the "transparent" really means that it forwards all IO resources
even outside the windows, and the windows are really just for show.

The kernel even used to totally ignore them, now it uses them as a hint
and will _preferably_ put stuff inside the window for such bridges, if the
windows have been set up (not all systems will even set up the windows at
all).

> PCI: Bridge: 0000:00:1e.0
> IO window: b000-bfff
> MEM window: ff900000-ff9fffff
> PREFETCH window: e8000000-efffffff
> is the bridge,
>
> 02:02.0 VGA compatible controller: ATI Technologies Inc Radeon RV100
> QY [Radeon 7000/VE] (prog-if 00 [VGA])
> Subsystem: C.P. Technology Co. Ltd: Unknown device 2049
> Flags: stepping, medium devsel, IRQ 255
> Memory at e8000000 (32-bit, prefetchable) [disabled] [size=128M]
> I/O ports at b000 [disabled] [size=256]
> Memory at ffff0000 (32-bit, non-prefetchable) [disabled] [size=64K]
> Expansion ROM at ff900000 [disabled] [size=128K]
> Capabilities: [50] Power Management version 2
>
> is the device,
>
> when I modprobe radeon which does pci_enable_device, the bars are enabled...
>
> However when X starts it tries to reassign the memory at 0xffff0000
> down into the bridge memory... at 0xfff90000, should the kernel do
> this? or does it actually matter if the memory is behind the bridge as
> its transparent... maybe I can at least patch X to check for
> transparent bridges...

It really shouldn't even matter where it ends up being enabled. Trying to
move it into the bridge window is as good as anything else, since it was
disabled to begin with (which means that you can't necessarily trust the
location that it was disabled _at_ - the ffff0000 value could even be just
what the firmware left it at after doing PCI BAR sizing, although I
suspect that it's a perfectly valid address).

Linus


-
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/