DCON improvements...

[Jim Gettys]

Thanks for a great explanation.
                     - Jim

On Wed, 2007-12-19 at 13:26 -0500, Adam Jackson wrote:
> On Mon, 2007-12-17 at 13:22 -0500, David Woodhouse wrote:
> > If we should design a next generation of DCON chip, are there any
> > improvements we should make to it?
> > 
> > Adam, do I recall correctly that you had problems hooking it up to X for
> > idle detection? Anything we could do to make that better?
> 
> I filed a bug about this with some observations:
> 
> http://dev.laptop.org/ticket/1671
> 
> It's not so much that detecting idle is hard in X, that's fairly easy.
> The way DCON1 works, once I notice that I'm idle, I have to keep doing
> stuff for another 1+e frame times to load a frame into the DCON and then
> switch to it.  Worse, I can't abort that operation midway through, once
> you tell DCON to load a frame it's going to do it or die trying.
> 
> Coming back out from DCON to GPU control is a timing disaster because
> the DCON silicon is _broken_, or was last time I looked at it anyway and
> I doubt it's changed.  The spec says the DCON should signal when it's in
> the vertical blank period by raising a line from the start of vertical
> front porch to the end of vertical sync; this is kind of odd, but works.
> But the silicon instead asserts the line during vertical back porch,
> which means you're already past the vsync pulse and you can't switch
> back to GPU control once you get that signal because the panel is
> strobing back up to the top of scanout.
> 
> I don't remember what we ended up implementing to work around this, but
> I'm fairly sure it involved a) the cli instruction, b) waiting at least
> another 1+e frames before finishing the switch.  50Hz refresh rate means
> 20ms frames, so the ping-pong latency is 40ms to get into the DCON and
> then back out.  Don't give up latency like that, you never get it back.
> 
> All of this timing dance made some sort of sense at the time because we
> were designing for the GX, which can't accept an external timing source
> for the graphics block.  LX, however, can genlock, so the right thing to
> do there would have been to slave it to the DCON's timing source.  If
> you only have one clock domain you can't drift, and you don't need to
> play stupid games trying to figure out when vsync really is.  Also, if
> you're genlocked, you can use the GPU's interrupts to handle transition
> timing, which saves you some GPIO pins.  ISTR access to DCON registers
> being really slow anyway, so anything I can do to talk to it less is a
> win.
> 
> In a spherical world, the way this would work is DCON would be
> continuously loading frames, would notice when idle has happened by
> snooping on the GPU cache or the framebuffer compression logic, and
> would handle the flip transparently.  To do that right you also need the
> DCON to be the thing that draws the cursor.  In other words, you really
> need this to be a GPU feature, not something you bolt on externally.
> But failing that, please, demand a genlockable GPU, slave it to the
> DCON's timing, and separate the DCON's "load frame" and "enter/leave
> scanout control" operations into two separate commands.
> 
> - ajax
> 
-- 
Jim Gettys
One Laptop Per Child