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
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
