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
