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 _______________________________________________ hardware mailing list hardware@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/hardware