GTA03 and E-Ink Interface

[Andy Green]

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

Somebody in the thread at some point said:
| On Wed, Feb 18, 2009 at 4:37 AM, Andy Green <andy at openmoko.com> wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Somebody in the thread at some point said:
|>
|> | Hmm, I didn't expect that GTA03 would still require fb-encoded gpio
|> | (for lack of a better term). I had thought that S3C6410 would allow
|> | remapping of VD pins to GPIO. I don't have the actual S3C6410
|> | datasheet, just the S3C6400X that you had linked to in another thread.
|> | That one suggests XvVD[17:0] can be switched into Function 3 (GPIO
|> | mode). Is this assumption invalid for GTA03's 6410?
|>
|> Nope it's still true, you can just bitbang it directly.  But, there's
|> not much in it except managing a single issue of framebuffer content
|> each time.
|
| I believe using the fb-encoded gpio will require multiple issues of fb
| content (ie: multiple display frames will be needed). My reasoning is
| that multiple commands are needed before and after fb transfer, eg:
| for a typical display update: we've got to first issue a load command,
| LD_IMG, with its transfer mode parameters, x, y, w, h, etc, and since
| that command incorporates a cs change, that means that we'll need at
| least 2 fb-encoded gpio transfers to execute a single actual fb
| transfer.

If chipselect doesn't have to stay asserted for more than one line's
worth of pixels, you can just use "Blue 5" in the scheme we talked about
so far:

Red0 - Red5      =  data0..5
Green0 - Green5  =  data6..11
Blue0 - Blue3    =  data12..15

Blue4            =  "write"
Blue5            =  chipselect  <==

If chipselect needs to stay in a given state through HSYNC, you can do
it with just a 74HC74 or similar, use Blue 5 to clock the latch to
sample, say, Red 0 and hold that state.

This will allow you to pack multiple commands into one video field.

|> There's something quite pleasingly generic about handling it as a true
|> framebuffer, you can walk up to any 18-bit LCD interface on anything
|> that allows GPIO style control of just a couple of remaining signals.
|
| Hmm, I may not have understood the part where you wrote it is generic
| or how this can be treated as a true framebuffer. This approach is
| only useful on platforms that have fb-encoded gpio like glamo which is
| not the majority of LCDC controllers/gfx accelerators as far as I am
| aware. Further, in this approach we at least double the framebuffer
| memory consumption (likely more than double depending on what happens
| with timing). So 800x600x3bytesx2 = 4MB just for framebuffer.

No, this general approach will work on any platform with an 18-bit LCD
interface and framebuffer.  It doesn't ask anything of the host except
it can display video on 18-bit bus.  There is no requirement for GPIO
control of those signals.

It's the plan to bitbang the GPIO directly, and not use it as video,
that would limit applicability.

Put another way, it makes the E-ink + display thing look like a standard
18-bit LCD that can work on anything with 666 framebuffer mode.  That's
why I say it's "pleasingly generic".

|> You need a lib-video-bitbang or something and a lot of people could
|> think to use it.
|
| I'm not sure I understood above portion, or the part about lot of
| people using it. My thinking is that this gpio encoding work would go
| on in the platform driver (eg: the port of am300epd.c, say
| mach-s3c24nn/gta02glamoepd.c ) that serves broadsheetfb and thus would
| not be visible to userspace. Userspace would see a normal framebuffer
| and memory map it and behave as it normally does with a defio
| framebuffer.

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.

A lot of people could think to use it because a lot of people have
devices with 18-bit video interface, eg, other phones.  And you are
guaranteed to find a working framebuffer able to drive the LCD connector
with video.

| I've started thinking about drawing up the schematic for the GTA01
| interface adapter. btw, is there somewhere where I can find info about
| the connector part used for CON6001 and what are valid mating
| connectors. I didn't see a bill of materials for GTA01 on the download
| site.

Googling the part number Werner just dug out gives

http://www.hirose.co.jp/cataloge_hp/e58613007.pdf

- -Andy

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

iEYEARECAAYFAkmeQ3oACgkQOjLpvpq7dMqpawCeLcqC8l4ine0vJTml9ncDTGck
FhwAniHuUkzJFnvL77KIGhmL4eGYlw4a
=2rIJ
-----END PGP SIGNATURE-----