GTA03 and E-Ink Interface

Jaya Kumar jayakumar.lkml at
Mon Feb 16 03:24:26 CET 2009

On Mon, Feb 16, 2009 at 8:02 AM, Andy Green <andy at> wrote:
> 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.


More information about the hardware mailing list