[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110726160758.6ce05577@bob.linux.org.uk>
Date: Tue, 26 Jul 2011 16:07:58 +0100
From: Alan Cox <alan@...ux.intel.com>
To: Patrik Jakobsson <patrik.r.jakobsson@...il.com>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>, 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!
> 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.
Right but i915 is different hardware, and the two deviate more over
hardware generations.
> 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..
If someone can figure out how it works on things like MIPI yes.
> 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.
We don't have a useful IRQ handler currently (or page flipping which
also needs that). It might help for some cases but again in most of
these situations if you follow the code the CRT is disabled at the
point we wait so there isn't a vblank.
> wait_for_pipe_disable can do mdelay(20) until something better comes
> up.
>
> If that is ok with you, I'll send some patches.
Go for it.
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