Subject: Re: Sharing bus_space maps between drivers
To: Vincent <>
From: Michael Lorenz <>
List: tech-kern
Date: 12/29/2006 16:41:34
Hash: SHA1


On Dec 29, 2006, at 10:52, Vincent wrote:

> Martin Husemann hat also geschrieben:
>> This sounds all backward. What DRI part are we talking about? Is this 
>> the chip specific driver that provides abstract DRI services and
>> attaches to the same hardware as, for example, vga @ pci?
>> There are a lot of different ways to organize this. Maybe we even 
>> need to
>> allow multiple of them:
>>   - vga @ pci and radeondri @ agp both share the hardware via some 
>> (tm)
>>     kind of cooperation.
>>   - radeondri @ agp owns the hardware, and allows vga @ radeondri (by
>>     forwarding some of it's bus_space variables, restricted to the 
>> common
>>     vga set)
>>   - radeondri @ agp completely replaces vga @ pci and directly allows
>>     wsdisplay @ radeondri (probably using code shared with vga @ pci)
> You need also to take into account the radeon framebuffer we try 
> currently to debug. radeonfb @ agp masks vga @ pci because only one 
> driver can get attached to a piece of hardware, if I read my NetBSD 
> correctly. Method 2 is more or less what I was suggesting. But since 
> there seems to be at least three different drivers competing for the 
> same space and hardware, I would suggest a forth proposal: developing 
> a radeon @ pci generic driver that would do nothing but map the chip 
> and offer access to vga @ radeon, radeonfb @ radeon and radeondri @ 
> radeon. If this makes somehow sense.

I'd suggest to attach the DRI stuff on top of display drivers, along 
with wsdisplay. That way we can:
- - simply hand over tags and such
- - shut up wsdisplay when DRI is talking to the hardware and the other 
way around ( think ioctl(WSDISPLAYIO_SMODE, ...) )
- - no need for funny hacks to have two drivers muck with the same 
( no I'm not talking about any kind of emulation layer )

have fun
Version: GnuPG v1.2.4 (Darwin)