GTA03 and E-Ink Interface

[Andy Green]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Somebody in the thread at some point said:
| 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.

If "DC" is another one of these slow signals you can latch that too same
way as proposed.

|> 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.

Great.

| 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.

640x480 may be all the framebuffer can emit... if it's true you can
split the bulk transfer over multiple frames.

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmeVc4ACgkQOjLpvpq7dMrMcACeJ6vCuKsm5Llz2Jl957HZliXC
lJAAoIqSoBLkc6/TM4VDea68UbIkj3oD
=OkT7
-----END PGP SIGNATURE-----