From mboxrd@z Thu Jan 1 00:00:00 1970 From: Helge Hafting Subject: Re: [Linux-fbdev-devel] Generic VESA framebuffer driver and Video card BOOT? Date: Mon, 18 Oct 2004 22:21:47 +0200 Sender: linux-kernel-owner@vger.kernel.org Message-ID: <20041018202147.GA28720@hh.idb.hist.no> References: <416E6ADC.3007.294DF20D@localhost> <87d5zkqj8h.fsf@bytesex.org> <87y8i8p1jq.fsf@bytesex.org> <20041017120728.GC10532@admingilde.org> <20041018083632.GE3065@bytesex> <20041018113929.GB3618@admingilde.org> <20041018121033.GB5106@bytesex> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <20041018121033.GB5106@bytesex> List-Id: Cc: linux-fbdev-devel@lists.sourceforge.net, Linux Kernel Development , penguinppc-team@lists.penguinppc.org On Mon, Oct 18, 2004 at 02:10:33PM +0200, Gerd Knorr wrote: > On Mon, Oct 18, 2004 at 01:39:29PM +0200, Martin Waitz wrote: > > hi :) > > > > > Whenever writing to the gfx memory before finishing the initialization > > > is harmless or not probably depends on the hardware, I'd better not > > > count on it ... > > > > when the application tries to access the framebuffer memory then > > the driver is asked to map the corresponding page. > > On first access only, and even that only if the driver doesn't map the > pages at mmap() time already. Not a single fb driver seems to map the > pages lazy today, grepping in drivers/video for nopage handles shows > nothing. I'm not sure you can actually do that for iomem mappings. > Isn't it possible for the driver to unmap the mapping when suspending? Then you're guaranteed to get that first access. This can be simplified to a all-or-nothing approach, it is not necessary to fault the pages in individually. Helge Hafting