Re: vgacon, vga16fb, clgenfb on PPC

[Cort Dougan <cort@fsmlabs.com>]

I lost all my PReP boxes and can't test anymore.  Motorola has a bunch of
guys on staff doing linux/ppc development for their systems (PReP) now so
you may want to have them test.

For now feel free to push it to the bk tree here.

} 	Hi,
}
} Finally I was able to compile a recent kernel again (2.3.41 from
} bitkeeper/PPC)!
}
} I revised my patch to make vga16fb and clgenfb compile (as modules, in my
} case). I couldn't test clgenfb, but vga16fb works fine as my second head (S3
} Trio64V+ initialized by em86, first head on ATI Rage II+ handled by atyfb).
}
} Compared to my previous version from 2 months ago, I think I found the bug that
} caused the endianness problems with vgacon on PReP: defining
} scr_memcpyw_{from,to} to be equal to memcpy() was wrong, since in that case no
} byteswapping was done when accessing video memory.
}
} The idea behind this patch is to make scr_{write,read}w() use {write,read}w()
} when {vga,mda}con is compiled in (independent of CONFIG_FB), and to use native
} byte ordering when it isn't.
}
} This patch is especially interesting for people who want to
}
}   - have a second head handled by vga16fb
}   - use clgenfb
}   - have vgacon on one head and clgenfb on the second
}   - ...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/