-----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 <a...@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----- _______________________________________________ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware