[patch] VRAM detection in controlfb
geert at linux-m68k.org
Wed Jun 7 17:59:56 EST 2000
On Tue, 6 Jun 2000, Michel Lanners wrote:
> On 6 Jun, this message from Michael Schmitz echoed through cyberspace:
> >> Anyways, that's the long answer. The short answer is: no, you probably
> >> don't want to cache the framebuffer.
> > Thanks for the long answer, and all those nasty gremlins have actually
> > been observed long time ago when people started to play with the
> > framebuffer drivers. At least on m68k, the framebuffer address space was
> > set non-cacheable right from the start (in head.S). I would hope that
> > somehow translated to PPC as well :-)
> That's what fbmem.c does in its default mmap(). However, at least for
> control (and maybe other comparable video implementations as well), you
> get much better performance on scroll and other fb-to-fb copy
> operations, without visible inconvenients, when the framebuffer is set
> to write-through caching.
| $ grep ioremap drivers/video/amifb.c
| videomemory = (u_long)ioremap_writethrough(videomemory_phys, videomemorysize);
It does mean that if the accel engine draws something, and the CPU wants to
chnge that, that there may be a cache incoherency. For amifb that doesn't
matter since it's unaccelerated.
Summarized: use write-through cachine for unaccelerated hardware, no caching
for accelerated hardware.
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc-dev