From: Zhenyu Wang <zhenyuw@linux.intel.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Anholt <eric@anholt.net>, mailing54 <mailing54@plzk.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Dave Airlie <airlied@redhat.com>,
dri-devel@lists.sourceforge.net, Ma Ling <ling.ma@intel.com>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
"Zhao, Yakui" <yakui.zhao@intel.com>,
Keith Packard <keithp@keithp.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: Linux 2.6.31-rc7
Date: Thu, 10 Sep 2009 13:47:05 +0800 [thread overview]
Message-ID: <20090910054705.GA1014@zhen-devel.sh.intel.com> (raw)
In-Reply-To: <alpine.LFD.2.01.0908252114130.3218@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2839 bytes --]
On 2009.08.25 21:20:18 -0700, Linus Torvalds wrote:
>
> And how about MacBook 2.1, which apparently also goes black?
>
Linus, sorry for reply this old thread.
I just handed on one MacBook with 945GM, and tried to find out
the reason of black screen. It is TV detection that caused it.
MacBook routes integrated TV DAC to mini-DVI port too, like for VGA.
Our TV detect does load detect, which trys to set a mode onto TV port
and checked back its status. This TV load-detect makes the LVDS black
on MacBook.
It looks our load detect function has problem that when we pick
up one crtc, we don't check if its has a fb. During first TV detect,
choosed crtc obviously has no fb, it would fail in modesetting when
setting plane surface. This might have effect on the purpose of load-
detect process. I'll see how it should be fixed. But even if I hacked
plane setting with all zeros, screen still goes black on my MacBook,
although TV detect return is right that there's none found.
So this blank issue is within detect process, if you try to load fbcon
or X later, setting mode is fine on LVDS. That's why build fbcon in
kernel might workaround this issue.
I don't know much about our TV detect method details, but looks like
here we should check current TV status when system start. Otherwise
it seems we can't stopping blank the screen...So I did a temp hacking
like,
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 5b1c9e9..f3ecbaa 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1451,8 +1451,18 @@ intel_tv_detect(struct drm_connector *connector)
struct intel_output *intel_output = to_intel_output(connector);
struct intel_tv_priv *tv_priv = intel_output->dev_priv;
struct drm_encoder *encoder = &intel_output->enc;
+ struct drm_i915_private *dev_priv = connector->dev->dev_private;
int dpms_mode;
int type = tv_priv->type;
+ static int first_detect = 1;
+
+ if (first_detect) {
+ first_detect = 0;
+ if (!(I915_READ(TV_CTL) & TV_ENC_ENABLE))
+ return connector_status_disconnected;
+ else
+ return connector_status_connected;
+ }
mode = reported_modes[0];
drm_mode_set_crtcinfo(&mode, CRTC_INTERLACE_HALVE_V);
which makes LVDS working, but I haven't tested with mini-DVI <-> S-Video.
I'm not sure if this is ideal enough for this, but first get port states in
system startup for initial setup, and userspace could check and set required
config later seems sane to me, as you have also suggested to do.
This patch doesn't aim to be upstream, we may set the state in priv struct
to check boot state, but I'd like to hear others' comment about this.
thanks.
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2009-09-10 5:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-22 1:26 Linux 2.6.31-rc7 Linus Torvalds
2009-08-22 3:09 ` Regression: Linux 2.6.31-rc7 lost sensors on asus mobo Gene Heskett
2009-08-22 3:47 ` Linus Torvalds
2009-08-22 12:56 ` Gene Heskett
2009-08-22 6:12 ` Robert Hancock
2009-08-22 10:54 ` Stefan Richter
2009-08-22 13:48 ` Gene Heskett
2009-08-22 14:38 ` Stefan Richter
2009-08-22 19:55 ` Gene Heskett
2009-08-22 13:40 ` Gene Heskett
2009-08-23 10:56 ` Linux 2.6.31-rc7 Geert Uytterhoeven
2009-08-26 5:06 ` KOSAKI Motohiro
2009-08-25 17:25 ` mailing54
2009-08-25 18:11 ` Linus Torvalds
2009-08-25 21:37 ` mailing54
2009-08-25 22:07 ` Linus Torvalds
[not found] ` <1251239637.26348.20.camel@gaiman.anholt.net>
2009-08-26 1:51 ` Zhenyu Wang
2009-08-26 3:33 ` Linus Torvalds
2009-08-26 3:47 ` Dave Airlie
2009-08-26 4:13 ` Linus Torvalds
2009-08-26 4:58 ` Dave Airlie
2009-08-26 17:12 ` Linus Torvalds
2009-08-26 17:18 ` Jesse Barnes
2009-08-26 6:26 ` Eric Anholt
2009-08-26 6:35 ` Dave Airlie
2009-08-26 3:58 ` Zhenyu Wang
2009-08-26 4:20 ` Linus Torvalds
2009-09-10 5:47 ` Zhenyu Wang [this message]
2009-08-26 10:09 ` ykzhao
2009-08-30 22:01 ` Tino Keitel
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=20090910054705.GA1014@zhen-devel.sh.intel.com \
--to=zhenyuw@linux.intel.com \
--cc=airlied@redhat.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=eric@anholt.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jbarnes@virtuousgeek.org \
--cc=keithp@keithp.com \
--cc=ling.ma@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mailing54@plzk.org \
--cc=torvalds@linux-foundation.org \
--cc=yakui.zhao@intel.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