SMP and mmap

James Simmons (jsimmons@edgeglobal.com)
Sat, 18 Sep 1999 13:40:34 -0400 (EDT)


Hi!

I have been working on the developement of fbcon. Well as you know fbcon
can both mmap accel regions as well as the framebuffer. Also some fbcon
drivers use accels to accomplish certain console funtions such as
clearing the screen. Now for many low end card you can't access the
framebuffer at the same time as the accel engine. Well one solution was to
unmap the framebuffer just before someone would access the accel engine.
Then use a no_page routine to put processes to sleep while the accel
engine was active. Then once the accel engine was idle wake up all the
processes that attempted framebuffer access. Now this soultion is far to
expensive. So I have been looking for another way.
The accel engine can be access from both userland and from kernel. Lets
consider the first case. The kernel using the accel engine. So just before
I access the accel engine in the kernel I need to physically not allow any
processes access to the framebuffer. Another way I looked at it was to
make sure the accel code was done atomically. So the best way I can do
this is with a spin_lock. Since the accels are done for the console code
and that code can be called by a interrupt I need to use spin_lock_irqsave
correct? What do I put the spin_lock on ? Would I put the spinlock on all
the pages allocated for the framebuffer? Would this be enough to block
access to the framebuffer? Also a spin_lock only can disable the local
the CPU interrupts. What about other processes on other CPUs that might be
trying to access the framebuffer? Would the spinlock in the code prevent
other CPUs from trying to use the framebuffer as well? Or do I have to use
a global lock with cli()? Another big problem is if multiple processes
try to access the MMIO mmap accel regions. This would confuse most
cards. How could I prevent this from happening?

-
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/