-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Smirl wrote: > We should discuss the design of DRM maps so that we don't work at > cross purposes. > > I have a new requirement coming from the egl-driver work that my user > space driver does not have root priv so it can't create the maps. This > implies that the drivers need to pre-create the maps. > > To access the maps I rely on doing GetMap and searching for the map I > need. My driver does not have the info needed to create the maps even > if it had the privs. I have never liked how user space needs to figure > out a bunch of info about the hardware and them tell it to the device > driver since the device driver obviously already knows all of the info > it is being told. > > The register map should be marked read only or root only. I don't need > access to the register map. > > 1) Should the maps be created once at driver load time or on > open/close? I can probably make the egl drivers work either way.
I did it at neither time in the MGA driver. When I added support there for PCI cards, I added a DMA boot-strap ioctl. User-mode passes in some parameters to the kernel (e.g., size of DMA buffers, requested AGP mode, etc.). The kernel then uses those parameters as guidelines to initialize itself. Any changes the kernel has to make (e.g., 4x AGP was requested, but the card is 0x AGP aka PCI) are communicated back via the same structure. > 2) Is compatibility maintained by doing a match in AddMap and then > returning the matching map? I handled the compat issue a little differently in MGA. Since I added a new ioctl, I could put the driver in either "new" mode or "old" mode. In old mode, everything worked *exactly* as before. In new mode, the map types / offsets were obtained differently. In fact, some of the maps are not available to user-mode in new mode (e.g., the MMIO register map). I think the answer to this question will vary from driver to driver. > 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are > marked differently it is way for my driver to tell AGP from PCI cards. I would advise against that. There are (rare) cases where user-mode wants to select AGP parameters, AGP mode vs. PCI mode, etc. If AGP is acquired and those maps added at module load, the only way to make those selections will be via module paramters. Yuck. > 4) Are there issues with sarea other than the one we talked about with XvMC? > > 5) I had set things up so that a reset program could access the > register/framebuffer maps before the card was initialized. You need > that because you can't initialize a card that hasn't been reset. BenH > is working on another reset scheme so this may not be needed any more. One route that I had considered going for MGA was to have some of the maps created when the module loadad and some maps created in the DMA boot-strap ioctl. I didn't see a need to do that, so I decided to keep all the mapping code grouped together. I think it should be fine to go that way, though. > 6) Is there some need for user space collecting info about the > hardware and then feeding it back into the driver that I can't see? Yes and no. Detecting certain hardware features in the kernel can add extra bloat. For example, MGA needs to know (at least for G200) whether the card has SDRAM or SGRAM. It's easier to have that in user-mode so that you don't add a big chunk of one-time code to the kernel. This example is a little weak. I think there may be a different way to do this detection than the way X does it. Dunno. > 7) Any more issues? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCwWjIX1gOwKyEAw8RAh2DAJ9gw8i3lDQ/+WX8WEPskWJu8VFi/QCfXAYN dwj7o6qd7BDT3dBLksD9vp8= =xwte -----END PGP SIGNATURE----- ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
