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