Am Mo 16. Februar 2009 schrieb Jaya Kumar: > On Mon, Feb 16, 2009 at 8:02 AM, Andy Green <a...@openmoko.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Access to Glamo mapped region is much slower than 50ns. But, it's 16 > > bits wide. If you were able to use all the 16 bit width, you would have > > more than enough bandwidth. > > Ok, with you so far. > > > > > Here's an idea, totally abuse the Glamo framebuffer and pixel bus to > > store your bitbang sequence as "video". Then hook up each of your E-ink > > bus signals to one bit of pixel data, eg, E-ink nRD <- RED0. > > I've lost understanding here. I have 22 signals. To talk to the > display, I need to wiggle 3 control signals, set 16-bits of data, > repeat to framebuffer size, wiggle some more and then finally wait > for an interrupt from a 4th control signal to send a command. I think > there's no input signal on the pixel bus so Glamo won't be able to > report the interrupt back to me. But I think it would not be a problem > for me to put that signal on an actual gpio. So that leaves the > problem of the 3 control signal and 16-bits of data. Is there a way > for me to store those 19-bits of data in the framebuffer so that glamo > can push them to the controller. I guess if glamo knows about RGB888 > and can transfer that to the pixel bus, that would work fine since I > can just store my control sequence + data inside the 24-bits of > framebuffer data and then get glamo to push that through. That would > be awesome. > > > > > Pixel data generation is synchronous in the Glamo so the edge quality > > should be good enough to clock from. There's a PLL in the Glamo that > > can be meddled for Glamo pixel clock: it's 24.5MHz typ IIRC. > > > > Because your bus clock is also derived from pixel data, and your system > > is fully synchronous, HSYNC and VSYNC will be invisible so long as you > > return your clock to 0 (presumably) before the end of each video line. > > You lost me here. I have a write signal that is used to clock the data > in for every 16-bit transfer, perhaps that's what you mean by bus > clock. For example, a full buffer transfer involves: > > set chipselect off > set data on > foreach pixel { > set write off > set 16-bits framebuffer data > set write on > } > set chipselect on > > If we treat write as a clock signal, then the clock must return to > idle after exactly the last pixel (of the whole framebuffer) rathar > than a whole horizontal line. I could use the vsync on the host to > tell me when to set chipselect on if I treat that as a separate IO. > > > There's an auto page flip feature in Glamo that can help you issue this > > data just the once, you can keep the other page at all pixels 0x000000, > > then it simplifies enabling page flip and watching it do it once, then > > disabling page flip. > > > > This should give you highest bandwidth solution possible on GTA02. > > Ok, sounds pretty good although the level of complexity seems high. > btw, I'd want to tell Glamo to suspend shortly after a transfer since > it's an E-Ink display since we won't need it to be active until the > next time we want to draw anything. > > Thanks, > jaya >
if that's a problem getting enough datalines from LCM videodata interface, you could use 2 pcs 16bit latch and control their CS and CLK and OE with 2 lines while hooking up the rest for latch data input. this way you have full control of all 32 (28?) output lines to a time granularity of glamo's pixelclock / 2. Of course with gaps during hsync where output won't change. For the very slow e-ink display I don't see where concerns about speed of data transmission arise from. Anyway with the concept sketched above you just fill glamo's videobuffer with the signalpattern for your interleaved 2 x 16 outputs, enable video output, and your kernel driver is idle during glamo "bitbanging" the e-ink interface data via the latches. I could help better if I had a datasheet of the E-Ink controller interface. cheers jOERG
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware