[Intel-gfx] [PATCH] drm/i915: s/mdelay/msleep/

[Daniel Vetter]

On Mon, Apr 8, 2013 at 1:49 PM, Paulo Zanoni <przanoni at gmail.com> wrote:
> 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?

The hand-waving in the commit message is supposed to specifically
address this concern. For the wait_pipe_off case we certainly don't
care, and the mdelays in the ilk code run at boot-up when there's a
pretty big chance that the scheduler will take away our cpu anyway
(and so extend the wait).

If the hw really needs an exact wait, we're screwed and would need to
use tricks like stop_machine to make sure no one else can interrupt
us.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch