Messages in this thread | | | Date | Sat, 18 Sep 1999 13:40:34 -0400 (EDT) | From | James Simmons <> | Subject | SMP and mmap |
| |
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/
| |