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

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

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

Ben.