"Keith Packard" <keithp@xxxxxxxxxx> wrote: >On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> wrote: > >> Do these fixes help with the DP issues you've been seeing, Keith? >> Seems like the first one shouldn't change behavior since we ought to >> time out on waiting on vblank in that case, and the timeout is the same >> as the msleep we used to use. > >The first one changes when the monitor sees the training message -- >before the change, the training message would get sent before waiting >for the vblank, and could potentially mess up the monitor >synchronization with signals. > >I tested this by turning an external DP monitor on/off repeatedly >without X running. Before the patch, the monitor would fail to sync once >in a while. With the patch, I haven't seen it fail. That's not to say >that it has actually fixed anything, just that it seems better. > >The best feature of the patch is that it shortens the time it takes to >light up a DP pipe -- the code was always hitting the timeout instead of >seeing a vblank signal, so we'd get a 50ms delay instead of a couple of ms. Yeah, definitely an improvement. I'll test myself when I get home (tested on my PCH eDP already, unfortunately didn't help). > >> The second one looks like a good change, but really the pipe off change >> is separate from the plane disable bug fix. > >Yeah, yeah, I know. I should have split the patch into two pieces... > >With these two patches in place, I'm not getting any timeouts while >waiting for vblank, which seems like a useful result, and should make >mode setting a tiny bit faster as well. > >I've got a couple more changes to work on today: > > 1) re-train the monitor when it gets unplugged and then plugged back > in. Right now, if you kick the cable out, you're stuck fumbling > around in the dark trying to run 'xrandr' again. Cool. Making use of our hotplug interrupts and never polling should be a goal; it looked like there were some other aux commands we could add as well. I'm meeting with the SV guys on Wed. To go over our eDP stuff, hopefully we can run the above through their equipment too and make sure we have all the timings etc correct. > > 2) send hotplug notification through the X server, at least for the > 'reliable' hotplug signals. Right now, when you run 'xrandr' > after changing connections, gnome sees the connection status change > event and 'does stuff', which frequently collides with the 'xrandr' > command you're running. This is very confusing to users. Great, yeah we shouldn't be sending events in response to our normal status ioctls, that sounds broken. On 9xx and above we should be able to do reliable hotplug for everything (though at a power cost for TV and maybe VGA). -- Jesse Barnes, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
