|
Description
Florian Mickler
2009-06-12 14:08:26 UTC
II) intel(0): Output VGA1 connected (II) intel(0): Output LVDS1 connected (II) intel(0): Output TV1 disconnected The problem is incorrect TV detection. Are your sure your kernel version includes patch-- commit cb66c692d1ae257f32dc7f6085cf9cb9f2f6bab8, if not please update your linux driver, then upload your log file with modedebug option on. Thanks Ma Ling (In reply to comment #1) > II) intel(0): Output VGA1 connected > (II) intel(0): Output LVDS1 connected > (II) intel(0): Output TV1 disconnected > The problem is incorrect TV detection. > Are your sure your kernel version includes patch-- > commit cb66c692d1ae257f32dc7f6085cf9cb9f2f6bab8, > if not please update your linux driver, then upload your log file with > modedebug option on. > Thanks > Ma Ling ping~ will check as soon as time permits. if i don't get to it within the next 2 days, expect an answer and more information late next week. Could you please help us to download register dump file after you start x in UMS and KMS respectively, and upload them? Thanks Ma Ling Created attachment 26942 [details]
kernel v2.6.30, kms
i used the regdumper utility from current xf86-video-intel git branch 2.7 .
kernel is 2.6.30
Created attachment 26943 [details]
ums regdumper output (same 2.6.30 kernel)
Created attachment 26944 [details]
kernel 2.6.30-03165-g6b70246 dmesg with drm.debug=8
i built kernel 2.6.30-03165-g6b70246 .
lvds still grows white. i attached the dmesg with drm.debug=8 on the kernel cmdline.
Created attachment 26945 [details]
kernel 2.6.30-03165-g6b70246 intel_reg_dumper output
and here is the reg_dumper output for the new kernel.
Created attachment 26947 [details]
reg dumper output, kms, kernel 2.6.30-03165-g6b70246 with bios option "use internal display" (everything working)
ok, here i booted with the bios option to display everything on the lvds, which does not display any problems. attached is the regdumper output.
Created attachment 26948 [details]
kernel 2.6.30-03165-g6b70246, bios-option "use vga", drm.debug=15, lvds is broken , kms enabled
and here is a bootup with full drm-debug for the broken case
The register dump files in comment #6 from UMS and in comments #9 from KMS whose primary monitor is LVDS indicate LVDS is set as 2 channel(they both work fine), whereas two files in coments #8 and #5 from KMS indicate LVDS is set as 1 channel whose primary monitor is external VGA. I will send patch to fix it soon. Thanks for your help Ma Ling Created attachment 27213 [details]
pleaset try the patch on your machine, thanks.
The patch arbitrarily set the lvds is 2 channel mode, but in fact we judge it by the value derived from bios.
Let me try to do some clarification:
in UMS no matter whether you set lvds as primary display or not in bios, lvds and VGA work fine?
But In KMS lvds and vga only work when lvds is set primary display?
Thanks
Ma Ling
(In reply to comment #12) > Let me try to do some clarification: > in UMS no matter whether you set lvds as primary display or not in bios, lvds > and VGA work fine? > But In KMS lvds and vga only work when lvds is set primary display? > > Thanks > Ma Ling > I just checked and the bios-term is "boot display device". [ the "primary display" is an option to change to an pci-express-graphics-card (which i don't have) ] "boot display device" has 3 states: 1. analog(vga) 2. digital(lvds) 3. both In UMS the behaviour is: 1. analog(vga): if an external vgamonitor is pluged in, all the boot and bios happens on the vgamonitor until X starts. Then X sets everything correctly up for my dual-head setup. the internal lvds stays off until X starts. if no vga is attached it falls back to 2.: 2: digital(lvds): everything gets displayed on my lvds. until X starts. X then sets everything correctly up. 3. both: if vga is attached boot until X starts is displayed on both (vga and lvds). X then sets everything correctly up. In KMS the behaviour is: 1. analog(vga): the external monitor is plugged in. all the boot and bios happens on the vga monitor, but from the point of mode-setting on, the lvds 'grows white'. it gets resetted when X starts, but then continues to 'grow white' 2. [smth like: thinkpad display] (lvds): everything gets displayed on my lvds until the point of mode-setting. then the vga and lvds are in clone mode and everything works as one expects. then x starts and sets my dualhead setting up. 3. everything is fine until the mode-setting takes place. from then on, same as 1. so the bug in kms is that as soon as the vga becomes the 'boot display' (i.e. is active before the mode setting) the lvds gets screwed up (and you already pointed out the differences.) against what is your patch? i assume it is against xf86-video-intel master? at least it dosn't seem to be a kernel patch? which makes me wonder, because even with kms the xf86-video-intel driver doesn't seem to be at fault? anyways, i try to test it now. ok, i recompiled my xf86-video-intel with a slightly modified patch (see below) and booted into ums.
it still worked.
i verified via x-server log (and my debug prints) that this is indeed called.
in kms this function is not used. (obviously)
so i think we can conclude about this test:
we verified that it is indeed right to set
clock.p2 = limit->p2.p2_fast;
for my display. but somehow the kms code doesn't get this right if the bios has activated the vga.
i will now try to do smth equivalent to the kernel mode setting code.
diff --git a/src/i830_display.c b/src/i830_display.c
index dd1310f..be3ffd2 100644
--- a/src/i830_display.c
+++ b/src/i830_display.c
@@ -582,11 +582,16 @@ intel_find_pll_i8xx_and_i9xx(const intel_limit_t * limit, xf86CrtcPtr crtc,
* dual-channel. We haven't figured out how to reliably set up
* different single/dual channel state, if we even can.
*/
- if ((INREG(LVDS) & LVDS_CLKB_POWER_MASK) == LVDS_CLKB_POWER_UP)
+ if ((INREG(LVDS) & LVDS_CLKB_POWER_MASK) == LVDS_CLKB_POWER_UP) {
+ xf86DrvMsg(pScrn->scrnIndex, X_INFO, "intel_find_pll: power_up branch");
clock.p2 = limit->p2.p2_fast;
- else
+ } else {
+ xf86DrvMsg(pScrn->scrnIndex, X_INFO, "intel_find_pll: not power_up branch");
clock.p2 = limit->p2.p2_slow;
+ }
+ clock.p2 = limit->p2.p2_fast;
} else {
+ xf86DrvMsg(pScrn->scrnIndex, X_INFO, "intel_find_pll: no lvds");
if (target < limit->p2.dot_limit)
clock.p2 = limit->p2.p2_slow;
else
Created attachment 27240 [details] [review] this fixes the issue for me. but i don't know if it is the right 'fix'. this is with what i came up... Putting some debugprints into the kernels intel_find_best_PLL (as suggested by MaLing's patch ) showed that in intel_find_best_PLL the 'no lvds'-branch got called for all outputs. removing the check for LVDS_PORT_EN fixes this. but i don't know if this breaks some other machine. why was that check there? maybe the check should be moved to another place instead? i could imagine problems setting up things that are turned off.. but somehow my lvds isn't turned off... even if the registers say that. perhaps it gets turned on further down the path? (In reply to comment #15) > i could imagine problems setting up things that are turned off.. but somehow my > lvds isn't turned off... even if the registers say that. > perhaps it gets turned on further down the path? > LVDS_PORT_EN really get's set further down in intel_crtc_mode_set. ping Could you please upload your vbios as below,thanks. # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ # echo 1 > rom # cat rom > /tmp/rom.bin # echo 0 > rom Created attachment 27441 [details]
pleaset try the patch on your machine in UMS mode, thanks.
Created attachment 27442 [details]
pleaset try the patch on your machine in UMS mode, thanks.
(In reply to comment #20) > Created an attachment (id=27442) [details] > pleaset try the patch on your machine in UMS mode, thanks. sorry, the patch is for KMS mode, not UMS mode. (In reply to comment #21) > (In reply to comment #20) > > Created an attachment (id=27442) [details] [details] > > pleaset try the patch on your machine in UMS mode, thanks. > > sorry, the patch is for KMS mode, not UMS mode. > what is the reasoning behind this bit: @@ -645,7 +645,8 @@ intel_find_best_PLL(const intel_limit_t *limit, struct drm_crtc *crtc, int err = target; if (IS_I9XX(dev) && intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) && - (I915_READ(LVDS) & LVDS_PORT_EN) != 0) { + ((I915_READ(LVDS) & LVDS_PORT_EN) != 0 || + dev_priv->lvds_dual_channel)) { /* * For LVDS, if the panel is on, just rely on its current * settings for dual-channel. We haven't figured out how to i don't understand the logic behind this. my working theory is, that if i specify to boot up with analog(vga) then the LVDS_PORT_EN bit gets disabled by the bios (? or smth other disables it) and thus the channel-setting is not done. but later, the LVDS_PORT_EN bit gets enabled (in the modeset-function further down). and then the lvds is not configured right. -> bug if i switch (in the bios) to boot on my lvds, the LVDS_PORT_EN bit obviously get's set right (by the bios, or whatever) and everything works. (as the channel setting is then done.) so in my book the LVDS_PORT_EN check is superfluous and broken as LVDS_PORT_EN gets set later in modeset anyways. your patch would just hack all dual-channel-lvds to ignore the LVDS_PORT_EN and for the rest(the singlechannel ones) it wouldn't matter as single-channel is probably the default? so i think it would be easier to just drop that check? Created attachment 27445 [details] rom data, as requested per comment #18 (In reply to comment #21) > (In reply to comment #20) > > Created an attachment (id=27442) [details] [details] > > pleaset try the patch on your machine in UMS mode, thanks. > > sorry, the patch is for KMS mode, not UMS mode. > i tried it. but it doesnt work. as it should have worked if the priv->dual_channel were set i'm gonna try to debug the panel-properties part. Created attachment 27450 [details] [review] patch ontop of your patch #27442 this patch debugs your channel_bits part. you probably only need the vbios i uploaded. but anyways... i also changed the find_best_PLL logic to make more sense. (In reply to comment #18) > Could you please upload your vbios as below,thanks. > # cd /sys/devices/pci0000\:00/0000\:00\:02.0/ > # echo 1 > rom > # cat rom > /tmp/rom.bin > # echo 0 > rom could you please upload your rom data ? thanks Ma Ling is this not sufficient? http://bugs.freedesktop.org/attachment.cgi?id=27445 you probably just overlooked it. i changed the description now. Created attachment 27708 [details]
pleaset try the patch on your machine in KMS mode, thanks.
this patch use another dynamic approach to generate current lvds channel type, please try it on your machine.
Thanks
Ma Ling
your patch (attachment #27708 [details]) works for me.
you can add my tested-by.
Created attachment 27781 [details]
pleaset try the patch on your machine in KMS mode, thanks.
I know you have tested the patch.
Thanks
Ma Ling
(In reply to comment #30) > Created an attachment (id=27781) [details] > pleaset try the patch on your machine in KMS mode, thanks. > > I know you have tested the patch. > > Thanks > Ma Ling > i cherry-picked 832cc28d5bc676331e6376d940ae45d5937aa688 (drm/i915: Set lvds dual...) from eric's tree onto current git master and applied this patch on top. the result oopse's at i915-init time. i could only see the bottom of the stacktrace... it had i915_init in it. i doublechecked, the same tree without this patch boots. (In reply to comment #31) > (In reply to comment #30) > > Created an attachment (id=27781) [details] [details] > > pleaset try the patch on your machine in KMS mode, thanks. > > > > I know you have tested the patch. > > > > Thanks > > Ma Ling > > > > i cherry-picked 832cc28d5bc676331e6376d940ae45d5937aa688 (drm/i915: Set lvds > dual...) from eric's tree onto current git master and applied this patch on > top. > > the result oopse's at i915-init time. i could only see the bottom of the > stacktrace... it had i915_init in it. i doublechecked, the same tree without > this patch boots. > it has to be this hunk, as this is the only change between you patches... + hdisplay = 1280; + if (IS_GM45(dev)) + vdisplay = 801; /*vdisplay <= 800 is for single channel*/ + else + vdisplay = 1024; there probably is no (dev)->pci_device here... commit 832cc28d5bc676331e6376d940ae45d5937aa688 Author: Florian Mickler <florian@mickler.org> Date: Mon Jul 13 18:40:32 2009 +0800 drm/i915: Set lvds dual channel according to register from vbios Fixed, and close the issue, please reopen if you need. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.