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
