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

Ville Syrjälä syrjala at sci.fi
Wed Mar 16 16:47:13 PST 2005


On Thu, Mar 17, 2005 at 10:30:01AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 23:08 +0200, Ville Syrjälä wrote:
> > On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:
> 
> > I haven't seen anyone coming forward with a design/code for the memory 
> > manager.
> > 
> > In the meantime I'm assuming that people might want to make some use of 
> > their dualhead cards...
> 
> Are you aware that with the current fbdev API, there will simply be no
> working use of dual head ? As soon as somebody will try to do 2
> different things on the 2 heads, it will either lockup due to lack of
> engine arbitration, or have wrong endianness, or whatever ...

I understand you can't have userspace program the accelerator while 
someone else is doing the same thing. Oh and I now understand that the 
same really applies to direct framebuffer access due to the swapper. I 
hadn't really thought about that issue before since I don't own a 
big-endian system. I really must try to get one...

So basically to fix both issues we need some locks everyone must acquire 
before accessing the hardware.

With the current "mmap() registers and go" interface the accelerator lock 
wouldn't actually guarantee anything but it would allow well behaving 
applications to share the accelerator. Good behaviour is already expected 
from the applications anyway due to the direct access to hardware 
registers.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/



More information about the xorg mailing list