[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110726111927.129270f7@lxorguk.ukuu.org.uk>
Date: Tue, 26 Jul 2011 11:19:27 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Patrik Jakobsson <patrik.r.jakobsson@...il.com>
Cc: Alan Cox <alan@...ux.intel.com>, Arnd Bergmann <arnd@...db.de>,
Ryan Mallon <rmallon@...il.com>,
Jesper Juhl <jj@...osbits.net>, linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...e.de>, devel@...verdev.osuosl.org
Subject: Re: GMA500: ERROR: "__bad_udelay" undefined!
> > Don't know yet - its on the fixme list to dig into - I think the answer
> > is some cases but not all.
>
> IMO, it should be replaced with actually waiting for the vblank and not an
> arbitrary time. I think this is fine as long as we don't use it when waiting for
> a pipe to disable. And I guess we could sleep while waiting for vblank.
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(
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.
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists