[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MMIO regions



On Mon, 11 Oct 1999, Jeff Garzik wrote:

> > It is an unfortunate, but true, fact that the broken video hardware
> > doesn't let you provide memory mapped access which is (a) fast, (b)
> > totally safe, and (c) functional.  Choose which of a, b and c you are
> > willing to sacrifice and then we can look for solutions.  DRI sacrifices
> > (b), for example, by making the locking cooperative rather than
> > compulsory.  The basic unaccelerated fbcon sacrifices (c).  Using VM
> > protection would sacrifice (a).  It's not the ideal choice, sadly.
> 
> Seems like it would make sense for an fbcon driver to specify the level
> of safety (and thus the level of speed penalty).

Well the new system I have implemented has elminated porting MMIO regions
to userspace. This makes way for DRI or any other solutions that might
come down the road. Also I have written fbcon to release the console
system on explict opening of fbdev. This way no accels are running in the
kernel while something like X is running. Especially if something like DRI
is running. This prevents any possible conflicts. Yes I sacrificed some
functionality of the current fbcon for DRI. I hope DRI will in turn help
support fbcon and help us write drivers. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/