GTA03 and E-Ink Interface

[Jaya Kumar]

On Fri, Feb 20, 2009 at 12:45 AM, Andy Green <andy at openmoko.com> 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