[PATCH] drm/i915: s/mdelay/msleep/

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi

2013/4/8 Chris Wilson <chris at chris-wilson.co.uk>:
> On Sun, Apr 07, 2013 at 11:13:03AM +0200, Daniel Vetter wrote:
>> The first in wait_pipe_off is really just a delay loop to wait for the
>> scanline counter to settle (which takes about a frame worth of time).
>> So also shrink it a bit.
>>
>> The other is in the ilk dprs code. If we need _exactly_ an 1ms wait in
>> there, that's already not guaranteed with the current code (since
>> especially at start-up we're likely to get scheduled away in between).
>> So replace those, too.
>>
>> Noticed while trying to understand why we've again broken the panel
>> fitter.
>>
>> Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> The only reason the mdelay(5) persisted for so long was that we were
> being lazy and not verifying that path could not be called from atomic
> context.
>
> The others I just credit Jesse for.

Documentation/timers/timers-howto.txt says that "msleep(1~20) may not
do what the caller intends, and will often sleep longer (~20 ms actual
sleep for any value given in the 1~20ms range). In many cases this is
not the desired behavior.". It suggests us to use usleep_range().

So it seems we may significantly increase those delays we're changing.
Is this a problem for this patch?



>
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



--
Paulo Zanoni


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux