Re: Sparc64 and ATI fb, cannot mmap() - why?

From: David S. Miller (davem@redhat.com)
Date: Tue Jun 20 2000 - 09:28:00 EST


   Date: Tue, 20 Jun 2000 09:19:06 -0400 (EDT)
   From: James Simmons <jsimmons@acsu.buffalo.edu>

   That "kludge" solves a problem that linux fbcon can't. Cards with
   multiple buffers. The current fbcon assumes one framebuffer and one
   mmio region. This is just bad. In the future this is going to
   change. Most likely support for multiple apertures will be modeled
   after solaris fbdev. The only difference is I like to see support
   for things like mmapping the Z buffer or stencil buffer etc.

I think the problem is, at the core, that people wish to mmap and
program hardware without having to have any knowledge about the
hardware. I wonder how many people have ever considered it in
this way :-)

And these chips are going to get more complicated, have more varied
ranges of different mmio/fb areas of the chip to get at. It's not
going to get simpler, and just adding more specifiers won't make
the core problem go away.

So in my opinion, the solution is just to do away with the current
fbcon mmap model completely, and go to one where you actually have to
know what you are doing to mmap and play with a piece of hardware.

It would almost make more sense to have bus based mmap routines, and
this can handle also all the issues of 32-bit X server on 64-bit
kernel (more common than you think) et al. Let's use PCI as an
example, you could say something like:

         struct pci_dev_specifier {
                int bus, dev, fn;
         } pdev;

         fd = open("/dev/pci");
         if (fd < 0) {
                perror("open");
                exit(1);
         }
         bus = whatever;
         dev = whatever;
         fn = whatever;
         err = ioctl(fd, PCI_DEV_SPECIFY, &pdev);
         if (err < 0) {
                perror("pci specify");
                exit(1);
         }
         ptr = mmap(fd, ...., FOO_DEV_24BPP_FB_OFF);

There would be an SBUS one too, and the only difference would be which
device to open and the device specifier cookie format and ioctl
number.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:19 EST