Re: GTA03 and E-Ink Interface
On Wed, Feb 18, 2009 at 4:37 AM, Andy Green 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
Re: GTA03 and E-Ink Interface
Jaya Kumar wrote: > btw, is there somewhere where I can find info about > the connector part used for CON6001 It's a Hirose FH23-39S-0.3SHW(05). - Werner ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GTA03 and E-Ink Interface
-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 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- ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GTA03 and E-Ink Interface
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Somebody in the thread at some point said: | | 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. BTW are you talking about E-ink virtual framebuffer? You won't need this kind of bit depth for that? 1 byte is just 480KBytes for 800 x 600. The LCD framebuffer on GTAxx is 640x480 anyway, in 666 mode / 24-bit it's < 1Mbyte. If your command is longer, you can issue a blank raster while you compose the next frame, the controller shouldn't care because we control the write signal for the bus. You only need page flip (is that why you doubled this number?) in Glamo case, because you don't have usable VSYNC interrupt, so using this lets you be sure you issue just one frame easier. - -Andy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmeRcIACgkQOjLpvpq7dMrrDwCdGZQRdl6rwNAvNtNpkiM7opCe rAwAnAxSuxVfq6LC1re8T1d0uCX7tOCD =8gg4 -END PGP SIGNATURE- ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GTA03 and E-Ink Interface
On Fri, Feb 20, 2009 at 12:45 AM, Andy Green 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. > > 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. 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. Thanks, jaya ___ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware
Re: GTA03 and E-Ink Interface
-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 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
