Who is stomping PCI config space?
Egbert Eich
eich at suse.de
Fri Mar 4 03:12:45 PST 2005
Jon Smirl writes:
>
> Somebody is changing PCI command from 83 to 80 and disabling my
> radeon's memory and iospace. Who is doing this? It has to be X since
> it doesn't happen if I switch to VT6 or VT8.
>
> Why is X mucking with a card it doesn't have a driver loaded for?
> Where is this happening in the X code?
>
Jon,
Yes, X is donig this as it is assuming that it is in
charge of all the graphics hardware in the machine.
It has to make this assumption as it cannot be sure that
the card has *no* legacy resources open. Without a driver
loaded it has no way of knowing any differently.
It doesn't matter if these legacy ports are used on this
card, it only matters these resources are used by another
card for setup purposes.
A lot of cards do have legacy ports open - even if nobody
uses them and without the driver the Xserver cannot really
do much about this.
At the time this was programmed this assumption was
necessary for the fast majority of cards.
I claim it is still required for a large number of
cards today as when the card has been POSTed the
BIOS usually leaves the legacy ports open.
So far we have no central agent available to schedule
access to shared resources.
If you want to access these cards from inside your
kernel you could just check if they are enabled before
you do and enable them if they aren't.
This works as long as you can be sure nobody else will
access legacy resources from anywhere else - this may
be difficult if you have a machine with more than one
CPU, if you have more than one userland process that
may want to access the HW.
You should make sure to restore the state before you
return.
As a note on the side:
The Xserver doesn't 'stomp' over PCI config space any
more without telling the kernel: The code which does
direct PIO banging for config space access doesn't
get used any more unless the user explicitely *asks*
for it.
The option to do so is well hidden from the user.
This has been this way since X.Org 6.8.0 - I didn't
change this for 6.7.0 for lack of testing.
Egbert.
More information about the xorg
mailing list