GTA03 and E-Ink Interface

Jaya Kumar jayakumar.lkml at gmail.com
Fri Feb 20 06:04:32 CET 2009


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.

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

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

Thanks,
jaya

ps: if anyone is interested in selling a GTA01 to me, used one is
fine, cheaper is better, I'm in KL, Malaysia at the moment, please let
me know.



More information about the hardware mailing list