2013/8/5 Daniel Vetter <daniel@xxxxxxxx>: > On Tue, Jul 30, 2013 at 10:30:41AM +0100, Chris Wilson wrote: >> On Mon, Jul 29, 2013 at 05:48:24PM -0300, Paulo Zanoni wrote: >> > From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> >> > >> > If we're already allowing PC8, just don't use the IRQs, so we won't >> > need to wake from PC8. Waking up from PC8 is a slow thing, so avoid it >> > when we can. >> >> You would also need to explain that the GMBUS is outside of the display >> power well. >> >> Looks reasonable, the only bit is moving the read of forbid_count into >> hsw_pc8_enabled() so that the gmbus code isn't poking around with >> someone else's locks, and we can safely do an unlocked optimistic read >> here. > > IIrc EDID reads with interrupts take 22ms, without them they can easily > take 100ms. Is pc8+ exit indeed longer than that difference? My tests consisted of running "xrandr" in a loop, When you do that, you allow/disallow PC8 many many many times per xrandr invocation, so it's not about pc8+ exit taking longer than 100ms, it's about adding up all the pc8 allow/disallow times that happen in between everything. I didn't measure the times, but I can notice the difference by seeing how faster my terminal scrolls with the new code. > > If the issue is that we flip-flop between pc8+ allow/deny too often then > we could just add a slight delay. Yeah, if we delay the code to reallow PC8+ we'll be able to reduce the slowdown. I even think that 1 second for a delayed PC8 reallow seems reasonable (after all, the screen is off). But I though that the current "do everything without even waking up from PC8" looked much much prettier :) > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Paulo Zanoni _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
