[Intel-gfx] [PATCH 5/8] drm/i915: avoid waking up from PC8 on GMBUS operations

[Paulo Zanoni]

2013/8/5 Daniel Vetter <daniel at ffwll.ch>:
> 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 at intel.com>
>> >
>> > 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