My current thinking on this is to do it the DRM driver but store the allocation data in normal system RAM. This would allow the allocation routines to function without touching the framebuffer.
I would really like to make sure that DRM drivers can function without having to map the framebuffer into kernel address space. We only have 1GB of kernel address space to work with and the kernel has to live in that 1GB too. 3dlabs is shipping a 512MB card now: http://www.3dlabs.com/product/wildcatvp/vppro/index.htm and a 1GB model is in the works. It is just going to be impossible to map these future cards into the kernel. In my earlier mail I proposed that DRM drivers automatically addmap the registers and framebuffer. At the end of add map it ioremaps the memory: switch ( map->type ) { case _DRM_REGISTERS: case _DRM_FRAME_BUFFER: #if !defined(__sparc__) && !defined(__alpha__) if ( map->offset + map->size < map->offset || map->offset < virt_to_phys(high_memory) ) { DRM(free)( map, sizeof(*map), DRM_MEM_MAPS ); return -EINVAL; } #endif #ifdef __alpha__ map->offset += dev->hose->mem_space->start; #endif #if __REALLY_HAVE_MTRR if ( map->type == _DRM_FRAME_BUFFER || (map->flags & _DRM_WRITE_COMBINING) ) { map->mtrr = mtrr_add( map->offset, map->size, MTRR_TYPE_WRCOMB, 1 ); } #endif map->handle = DRM(ioremap)( map->offset, map->size, dev ); printk(KERN_ERR "Mapping: %lx handle: %p\n", map->offset, map->handle); break; DRM drivers need the registers mapped but I don't think they need the framebuffer mapped. The auto addmap would eliminate the need for an IOCTL to return the physical address of the registers/fb. Auto addmap would add the map entry but not do the ioremap of the framebuffer. I've also been poking around a little in the radeon DRM driver. It seems to be mapping the framebuffer into kernel space but I never see any place that the driver code touches it. --- Michel Dänzer <[EMAIL PROTECTED]> wrote: > On Sat, 2003-12-06 at 23:24, Jon Smirl wrote: > > 3) FB memory allocators. Not sure these should go into the DRM system. It > might > > be better to put this into the library with init/mode support. Mesa would > need > > to be modified to use these allocation routines. On the other hand these > might > > be better inside the DRM driver. Future hardware may not allow direct access > to > > the framebuffer. > > I think at least the core of it definitely has to be in the kernel for > enforceability, cleanup on process death etc. > > > -- > Earthling Michel Dänzer | Debian (powerpc), X and DRI developer > Software libre enthusiast | http://svcs.affero.net/rm.php?r=daenzer > > _______________________________________________ > Xserver mailing list > [EMAIL PROTECTED] > http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/xserver ===== Jon Smirl [EMAIL PROTECTED] __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
