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

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> 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.  

And you can't have someone program the accelerator while somebody does
direct access neither. It's basically all exclusive.
> 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...

The only thing that would "work" without arbitration is direct
famebuffer access on both, with both using a different swapper, that is
a different aperture. That is either doing the the way I described
earlier (having both apertures overlap the beginning of memory) or doing
the mapping the "right" way (that is both apertures mapping half of
memory so that together they map all of it).

The problem is that I think a bunch of BIOSes for x86 didn't care since
they don't use the swapper and didn't set the aperture size properly.

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

Plus the VGA arbitration of course ... But yes. That's more or less what
DRM provides.

> 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.

It's more than the accelerator. A framebuffer access concurrent with
accelerator operations can lockup too.

Ben.