On Fri, Feb 20, 2009 at 12:45 AM, Andy Green <[email protected]> wrote: > Blue4 = "write" > Blue5 = chipselect <==
I believe we already ate that for the main course, RGB664=16-bits data, B4,5=WR and DC. If glamo causes B4,5 to change during hsync, then we'll have to latch them so that WR and DC are consistent. CS was going to go on a real GPIO, ie: LCD_MOSI/DIN. > > I'm only talking about the LCD controller framebuffer. If you will do > it in kernel space to expose a second, virtual framebuffer to hide the > detail of how it's done, that sounds great. That's how all the e-paper drivers in the kernel work today. http://lxr.linux.no/linux+v2.6.28/drivers/video/fb_defio.c . We just expose a virtual framebuffer that is backed by platform dependent backends, in some cases a 2nd encoded framebuffer, in some cases, USB, GPIO, etc. For example, broadsheetfb+am300epd just translates the virtual fb that is used by userspace into gpio writes on the fly. In the case of GTA01/3, that'll be the same. In the case of GTA02, there'll need to be an 800x600/2 <- since 8bpp, x 3bytes (since 18-bits to encode data) * 2 (since each 16-bit data transfer requires at least 2 iterations of itself encoding WR on/off and possibly more if it is racy) fb to store all the encoded gpio for a framebuffer. Thanks, jaya _______________________________________________ hardware mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/hardware
