Re: [Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures & memory mapping)

["Ville Syrjälä" <syrjala@sci.fi>]

On Wed, Mar 16, 2005 at 10:50:52AM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2005-03-16 at 07:37 +0800, Antonino A. Daplas wrote:
> > On Tuesday 15 March 2005 21:36, Ville Syrjälä wrote:
> > > On Tue, Mar 15, 2005 at 09:51:40AM +0100, Geert Uytterhoeven wrote:
> > > > On Tue, 15 Mar 2005, Ville [iso-8859-1] Syrj??wrote:
> > > > > If radeonfb will allocate the buffer for the second head from the top
> > > > > of the memory users would basically have to guess it's location.
> > > > > matroxfb simply cuts the memory in two pieces and allocates the buffers
> > > > > from the start of each piece. I don't really like that approach. Adding
> > > > > a simple byte_offset field to fb_var_screeninfo would solve the problem
> > > > > quite nicely but I don't know if such API changes are acceptable at
> > > > > this stage.
> > > >
> > > > You wouldn't have to guess its location, look at fix.smem_start.
> > >
> > > But how would someone mmap() the whole memory then? matroxfb already plays
> > 
> > This is multi-head, right?  That implies one fb per head.  So,  can't you do
> > separate mmaps?  fb0->fix.smem_start|len and fb1->fix.smem_start|len.
> 
> Sure, re-read the thread :) Also, he's worried about management of
> offscreen memory. (which is an issue too because of possible problems
> with the setup of the apertures -> start of the discussion,

There's also the case with Matrox Millennium I/II cards. They must place 
the visible frame buffer so that no line crosses the boundary of memory 
banks. matroxfb deals with that by moving the buffer and changing 
smem_start and smem_len appropriately. But that is really bad for 
DirectFB's offscreen memory management. After a mode switch the memory 
manager would need to know what kind of initial byte offset was used. Of 
couse it would be possible to determine that from smem_start by knowing 
how the aperture must be aligned. Actually we already do that sort of 
thing to allow hw accelerated rendering when used on matroxfb controlled 
G450/G450/G550 CRTC2. But in that case the offset won't change on mode 
switch.

> and because
> it seems that directFB has only been tested on little endian machines
> (damn them !) and thus doesn't understand the problem with swapper on
> framebuffer access).

Actually people do use it on big-endian systems but since neither the 
mach64, ati128 or radeon drivers play with the swapper settings I can only 
assume that they haven't been tested very extensively.

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