On Sat, 11 Sep 2004 13:49:34 -0400 (EDT), Vladimir Dergachev <[EMAIL PROTECTED]> wrote: > On Sat, 11 Sep 2004, Alan Cox wrote: > > > On Sad, 2004-09-11 at 18:10, Vladimir Dergachev wrote: > >> This is a good point - if we don't need DMA or 3d acceleration we can > >> reduce memory footprint. This would seem that current DRM driver would > >> need to be dependent on whatever driver contains the mode setting code. > >> > >> What do you think ? > > > > Jon wants to get mode setting into a seperate piece of functionality - > > preferably in user space for many cards. I'd dearly love to see hotplug > > handing all but some "emergency" pre-computed mode settings. > > I think there is a misunderstanding. > > My view was that PLL setting (and setting of a fixed mode) would be done > in DRM driver. This way it would be able to restore previous settings > after a lockup or respond to FB request to change modes. > > However the decision of which mode to set, as well as where the > framebuffer is located is done in user-space. (So that subtleties of > layout of offscreen memory are not in the kernel). > > Jon - did I understand you correctly ?
All register writes would occur in the driver. There is nothing stopping the code that computes those register values from running in user space. A example mode setting IO would take: display buffer offset width, height, stride, etc - for fbcon to use register values to set the mode Mode setting needs to be serialized. It may be better to do the serialization before the hotplug event, in that case the mode setting IOCTL would be implicitly serialized and not need a separate lock. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
