pbuffers, extensions to DRM

[Jon Smirl]

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 <michel@daenzer.net> 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
> Xserver@pdx.freedesktop.org
> http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/xserver

=====
Jon Smirl
jonsmirl@yahoo.com

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree