FB model basic issues (WAS: radeon, apertures & memory mapping)

Benjamin Herrenschmidt benh at kernel.crashing.org
Wed Mar 16 16:28:00 PST 2005


On Thu, 2005-03-17 at 02:14 +0200, Ville Syrjälä wrote:
> On Thu, Mar 17, 2005 at 10:27:56AM +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-03-16 at 22:55 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 16, 2005 at 10:49:11AM +1100, Benjamin Herrenschmidt wrote:
> > > > In the meantime, can you tell me more about your arbitration scheme ?
> > > 
> > > There is a lock associated with the graphics card. The lock is always 
> > > taken before programming the hardware. Other things wanting access to the 
> > > hardware wait until the lock is released.
> > 
> > Ok, so it would be easy to have directFB use an external arbiter without
> > breaking existing clients ? It will need at least to use the vga arbiter
> > that I'm about to finish, that should allow at least to have X on one
> > card and directFB on another without conflict.
> 
> Is the vga arbiter required for something else besides access to some 
> legacy ports? DirectFB only uses legacy ports to wait for vsync if a 
> better method is not available.

Yes. I need to extend the Arbiter API a bit in fact to deal with clients
that don't "know" if the card is doing legacy decoding like you.

The problem is that unless the card you are using is not doing any
legacy decoding (has been set not to decode legacy VGA IO ports and
legacy VGA memory), trying to use another card in the system that does
decode them requires switching off IO and MEM access on you. Even if you
aren't actually using those legacy stuff, the simple fact that the card
is decoding them mean it needs to be disabled.

(In fact, it could be avoided in some cases where the card is under a
different P2P bridge by just disabling VGA forwarding, but that's the
aribter salad, as a client, you don't have to "know" that).

So the arbiter provides calls to "lock" some resources and deals with
eventually ping-pong'ing IOs. It's currently providing APIs to lock
legacy IO and legacy MEM and to inform the arbiter that the card isn't
decoding some or all of the legacy stuff (to put it out of the arbiter
hands basically). It needs an addition to the API I posted for cases
where you don't know if the card is doing legacy decoding, to indicate
you want to access the normal memory/IO resources of the card, and
implictely lock the legacy ones if they are beeing decoded. I'm working
on it, I hope to have something to start playin with soon, there are
some issues to deal with the kernel vga console though that i'm trying
to iron out.

Ben.





More information about the xorg mailing list