On Wed, Feb 18, 2009 at 4:37 AM, Andy Green <a...@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. _______________________________________________ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware