From: Alan Cox <alan@linux.intel.com>
To: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Arnd Bergmann <arnd@arndb.de>, Ryan Mallon <rmallon@gmail.com>,
Jesper Juhl <jj@chaosbits.net>,
linux-kernel@vger.kernel.org, Greg Kroah-Hartman <gregkh@suse.de>,
devel@driverdev.osuosl.org
Subject: Re: GMA500: ERROR: "__bad_udelay" undefined!
Date: Tue, 26 Jul 2011 16:07:58 +0100 [thread overview]
Message-ID: <20110726160758.6ce05577@bob.linux.org.uk> (raw)
In-Reply-To: <CAMeQTsYhLTPLUBGgBTQ=2xDjzw1aK2Oif+_aC+=hVikALuUXPg@mail.gmail.com>
> 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
next prev parent reply other threads:[~2011-07-26 15:05 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-24 21:37 GMA500: ERROR: "__bad_udelay" undefined! Jesper Juhl
2011-07-25 1:22 ` Ryan Mallon
2011-07-25 1:28 ` Ryan Mallon
2011-07-25 2:15 ` Arnaud Lacombe
2011-07-25 21:08 ` Arnd Bergmann
2011-07-25 21:42 ` Alan Cox
2011-07-26 9:06 ` Patrik Jakobsson
2011-07-26 10:19 ` Alan Cox
2011-07-26 14:07 ` Patrik Jakobsson
2011-07-26 15:07 ` Alan Cox [this message]
2011-08-01 1:54 ` Patrik Jakobsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110726160758.6ce05577@bob.linux.org.uk \
--to=alan@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@suse.de \
--cc=jj@chaosbits.net \
--cc=linux-kernel@vger.kernel.org \
--cc=patrik.r.jakobsson@gmail.com \
--cc=rmallon@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox