Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750788AbXANAbd (ORCPT ); Sat, 13 Jan 2007 19:31:33 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750817AbXANAbd (ORCPT ); Sat, 13 Jan 2007 19:31:33 -0500 Received: from 81-174-33-43.f5.ngi.it ([81.174.33.43]:40795 "EHLO develer.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750788AbXANAba (ORCPT ); Sat, 13 Jan 2007 19:31:30 -0500 X-Greylist: delayed 397 seconds by postgrey-1.27 at vger.kernel.org; Sat, 13 Jan 2007 19:31:29 EST X-Spam-Virus: No Message-ID: <45A97832.2040206@develer.com> Date: Sun, 14 Jan 2007 01:24:18 +0100 From: Bernardo Innocenti Organization: Develer S.r.l. - http://www.develer.com/ User-Agent: Thunderbird 1.5.0.9 (X11/20061223) MIME-Version: 1.0 To: lkml , linux-fbdev-devel@lists.sourceforge.net CC: aleph Subject: How to mmap a shadow framebuffer in virtual memory Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Jan 14 01:24:47 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 45a9784f190921561628829 X-DSPAM-Factors: 27, msg+n, 0.00010, DELAY+HZ, 0.00010, values+don't, 0.00010, data+i2c, 0.00010, oled, 0.00010, oled, 0.00010, screen+base, 0.00010, screen+base, 0.00010, fb+var, 0.00010, fb+var, 0.00010, off+len, 0.00010, off+len, 0.00010, I2C+CLIENT, 0.00010, I2C+CLIENT, 0.00010, for+userland, 0.00010, var+screeninfo, 0.00010, var+screeninfo, 0.00010, CLIENT+END, 0.00010, CLIENT+END, 0.00010, i+#if, 0.00010, start+info, 0.00010, linux+tty, 0.00010, smem, 0.00010, smem, 0.00010, hook+I, 0.00010, fb+info, 0.00010, fb+info, 0.00010 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 25241 Lines: 947 Hello, This is driving me crazy. I wrote this custom fb driver for an organic LED display for an embedded ARM system. The display is connected trough an I2C bus, therefore the display buffer is not memory mapped. Anyway, I want to support mmap() and my driver allocates shadow buffer with __get_free_pages() which gets periodically copied to the display by a thread. This is unlike most fb drivers which just point smem_start to the phisical address of their framebuffer. >From user space, opening /dev/fb0 and writing to it works just fine. mmap()'ing the file and writing to it does not have any effect. Writing the phisical address in smem_start and letting the fbgen code do the rest didn't seem to work, so I reimplemented the fb_mmap hook. I don't feel confident with the Linux VM, so I tried several strategies to allocate the shadow buffer, including vmalloc() and kmalloc(). The virtual framebuffer (vfb) also uses vmalloc() but crashes calling processes because it confuses physical and virtual addresses, or so it seems. Maybe it's just my kernel or my platform... does anybody use a similar technique? Can anybody point me to known-good code that approximates my needs? If you want to review the code below, look for the allocation in oledfb_init() and usage in oledfb_mmap(). This code runs on 2.4.19-rmk7 because I can't upgrade to a newer kernel on this target. /* * linux/drivers/video/oledfb.c -- STV8102 OLED frame buffer device * * Copyright 2006 Develer S.r.l. (http://www.develer.com/) * Author: Bernardo Innocenti * Author: Stefano Fedrigo * * This file is subject to the terms and conditions of the GNU General Public * License. See the file COPYING in the main directory of this archive * for more details. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include