On Sat, 1 Apr 2000, David S. Miller wrote:
> fb->screenbase is an I/O address, so include/linux/fbcon.h cannot
> call the normal memmove() on the frame buffer addresses passed
> to it.
>
> The traces make it clear that memmove() is being called with
> physical I/O addresses:
>
> >>TPC; 0055e3c0 <dest_is_64byte_aligned+48/5c> <=====
>
> (arch/sparc64/lib/VIScopy.S) dest_is_64byte_aligned:
> ... skip 0x48 bytes ...
> EXVIS1(LDBLK [%o1 + 0x00] ASIBLK, %f0) ! LSU Group
>
> o0: 000001ffe1800000 o1: 000001ffe1ab6600 o2: 0000000000000010 o3: 00000000000000f0
> ^^^^^^^^^^^^^^^^^^^^
>
> I/O space starts at 0x10000000000 on UltraSparc systems.
>
> One suggestion is to change include/video/fbcon.h to implement
> fb_memmove() in terms of fb_read{b,w,l}/fb_write{b,w,l}
>
> This would be correct for all architectures which lack a specific
> version in fbcon.h already. The ix86 version works by accident
> because ioremap()'d areas just so happen to be implemented by
> virtually mapping them into the kernel.
That's also my suggestion. BTW, how come no one ever found out before on
SPARC64?
> Even better would be to require that the asm/io.h headers define a
> {memcpy,memmove}_io() (ie. where source _and_ destination are I/O
> addresses) and then have fbcon.h just define fb_memmove to memmove_io
> in the generic cases.
Indeed even better.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of the message to [EMAIL PROTECTED]
