[lkml]   [2011]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: GMA500: ERROR: "__bad_udelay" undefined!
> Opinions are cheap, generating a list of all the paths through the tree
> that can hit vblank waits is alas not, neither is verifying it on a pile
> of real hardware 8(

Yes, it certainly needs testing before being changed.

> Plus none of the Intel issued IMG drivers wait for a vblank event and in
> several cases it's quite clear that there is *no* vblank that can be
> waited for at that point, eg look at the MIPI interfaces.

I don't think there is a particular reason for that. They are based on an old
version of i915 that used to do it that way. i915 changed to polling pipestat
in 2.6.36.

If there is no vblank to be waited for, we shouldn't be doing
wait_for_vblank. If we're waiting for a pipe to turn off, there should be a
wait_for_pipe_disable, and so on..

> So unfortunately it's rather complicated to fix although working them
> through to make some of the msleeps is certainly doable - add a
> sleep_for_vblank() or similar and send patches as you verify each one is
> ok and test it perhaps ?
> Alan

What about catching vblanks in irq handler and using a wait queue in
sleep_for_vblank and do pipestat polling in wait_for_vblank? Then I can start
testing sleep vs wait. All current wait_for_vblanks should be replaced with
mdelay(20) and marked with a FIXME.

wait_for_pipe_disable can do mdelay(20) until something better comes up.

If that is ok with you, I'll send some patches.


 \ /
  Last update: 2011-07-26 16:09    [W:0.046 / U:11.528 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site