> Unfortunely most fbdev drivers set the hardware in IO access mode. Plus > some of the devices lack any kind of DMA support. In this case seperating > out the parts of the driver that program the "high level" stuff leaves > almost nothing left. Would it still be wise to seperate it out as you > suggest? Would we really gain that much doing this for the case of IO > access only graphics hardware?
The problem is the same. DMA or not DMA, what we want is arbitration. When fbdev sets up a mode, the X server mustn't blast 2D engine (either using PIO or sending DMA commands) etc... So that "arbitration" module will have to provide the necessary arbitration so that the 2D/3D DMA command flow can be interrupted (if any), and/or the hw access "lock" passed between things like fbdev/fbcon and userland clients. Right now, even plain fbdev as it exist is racy in this regard. Nothing prevent an accelerated printk or cursor operation to happen in the middle of a userland initiated mode switch, potentially locking up the card. My latest radeonfb has minimal spinlock so at least the indirect register accesses (like PLL) are safe, but it's still broken in some way. Unfortunately, the way fbcon currently works, the only way to deal with those issues is by taking the console semaphore on every fbdev operations. (Thanks to printk & blanking coming from irq). If fbcon can completely separate update of the text/attr buffer from actual refresh of the framebuffer, it may be possible to do something smarter. This problem isn't really an issue we need to deal with in that proposed "low level" driver though. It's entirely an fbdev/fbcon issue that is caused by having fbcon active on a VT, that is by having a KDTEXT VT. I expect that when such a console is frontmost, the HW lock will be solely owned by fbdev/fbcon. Only a KDGRAPHICS vt shall release that HW lock, letting userland grab it for drawing operations, fbdev taking it only when requested to do things like mode changes or palette changes. Ben. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
