registry team mailing list archive

[Bug Watch Updater <608907@xxxxxxxxxxxxxxxxxx>]

Launchpad has imported 47 comments from the remote bug at
http://bugs.freedesktop.org/show_bug.cgi?id=29647.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2010-08-18T08:05:16+00:00 Christian Wehrfritz wrote:

Created an attachment (id=37954)
dmesg

Hello,

I can't get more than 1024x768 with xforcevesa and i915.modeset=0 on a
Lenovo U160. If I boot into single mode, then do a rmmod i915; modprobe
i915 modeset=1, the screen goes black while the LED backlight is still
lit. The happens with all kernels, I tried, e.g. Ubuntu 10.4, 10.10,
latest Fedora, and vanilla 2.6.36-RC1.

The graphics chip is a 
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device 3920
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 43
        Region 0: Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at 1800 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
                Address: fee0f00c  Data: 4171
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel modules: i915

I have attached the vbios dump *before* the modules insertion. The dmesg
and the intel_reg_dump output were recorded *after* inserting i915.

Is there anything I can test?

Best regards,
Christian

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/13

------------------------------------------------------------------------
On 2010-08-18T08:05:57+00:00 Christian Wehrfritz wrote:

Created an attachment (id=37955)
vbios

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/14

------------------------------------------------------------------------
On 2010-08-18T08:06:24+00:00 Christian Wehrfritz wrote:

Created an attachment (id=37956)
intel_reg_dump

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/15

------------------------------------------------------------------------
On 2010-08-19T10:21:40+00:00 Chris Wilson wrote:

Can you please try
http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay as that
contains various fixes for Arrandale? (Including a few timing fixes
which have proven vital for bringing up DP/eDP.)

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/16

------------------------------------------------------------------------
On 2010-08-19T14:05:15+00:00 Christian Wehrfritz wrote:

(In reply to comment #3)
> Can you please try http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay
> as that contains various fixes for Arrandale? (Including a few timing fixes
> which have proven vital for bringing up DP/eDP.)

I'm afraid that didn't work. I pulled the repo with
 git clone git://anongit.freedesktop.org/~ickle/linux-2.6

but that resulted in a 2.6.32-rc2 kernel (which wouldn't boot with
xforcevesa i915.modeset=0 single. How do I get the source of that
overlay?

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/17

------------------------------------------------------------------------
On 2010-08-19T14:15:28+00:00 Chris Wilson wrote:

(In reply to comment #4)
> I'm afraid that didn't work. I pulled the repo with
>  git clone git://anongit.freedesktop.org/~ickle/linux-2.6
> 
> but that resulted in a 2.6.32-rc2 kernel (which wouldn't boot with xforcevesa
> i915.modeset=0 single. How do I get the source of that overlay?

After git clone, git checkout -b testing origin/overlay

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/18

------------------------------------------------------------------------
On 2010-08-20T03:19:40+00:00 Christian Wehrfritz wrote:

> After git clone, git checkout -b testing origin/overlay

Thanks!

Screen, however, stays black with that kernel. Here are the last dmesg
lines starting just before the `modprobe i915 modeset=1`:

[   43.884476] [drm] Module unloaded
[  138.283424] i915 0000:00:02.0: setting latency timer to 64
[  138.329902] [drm] detected 63M stolen memory, trimming to 32M
[  138.330110] i915 0000:00:02.0: irq 43 for MSI/MSI-X
[  138.330137] [drm] set up 32M of stolen space
[  138.450379] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  138.477971] acpi device:06: registered as cooling_device4
[  138.478954] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/input/input8
[  138.479074] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[  138.479445] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
[  138.848474] checking generic (d0000000 130000) vs hw (d0000000 10000000)
[  138.848479] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[  138.849853] Console: switching to colour dummy device 80x25
[  138.867007] Console: switching to colour frame buffer device 170x48
[  138.872953] fb0: inteldrmfb frame buffer device
[  138.872955] drm: registered panic notifier

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/19

------------------------------------------------------------------------
On 2010-08-20T03:33:02+00:00 Chris Wilson wrote:

So we know we have something different. Can you try booting [still with
the overlay branch, as it that rules out several known bugs] with
i915.modeset=1. i.e. skip loading of the VESA fb, and attach a fresh
drm.debug=0xe dmesg?

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/20

------------------------------------------------------------------------
On 2010-08-20T03:51:41+00:00 Christian Wehrfritz wrote:

Created an attachment (id=38010)
dmesg of boot with modeset=1 (overlay kernel)

here's the dmesg of booting the overlay image with modeset=1 and
drm.debug=0xe

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/21

------------------------------------------------------------------------
On 2010-08-20T17:03:57+00:00 Jerone Young wrote:

This issue is also being tracked in launchpad:
https://bugs.launchpad.net/linux/+bug/608907

The issue appears to be with LG 1366x768 displays (product ID 703).

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/22

------------------------------------------------------------------------
On 2010-08-20T17:13:13+00:00 Jerone Young wrote:

Also to add. This is similar to the issue with the Thinkpad X201 panel:
https://bugs.launchpad.net/gentoo/+bug/554569

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/23

------------------------------------------------------------------------
On 2010-08-20T23:29:06+00:00 Chris Wilson wrote:

(In reply to comment #10)
> Also to add. This is similar to the issue with the Thinkpad X201 panel:
> https://bugs.launchpad.net/gentoo/+bug/554569

Nope. Different bugs, this one has been fixed.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/25

------------------------------------------------------------------------
On 2010-08-21T14:07:36+00:00 Jerone Young wrote:

@Chris
        Actually the issue is a similar issue. The fix for the X201 probably needs more tweaking to also work with this LG display.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/30

------------------------------------------------------------------------
On 2010-08-24T14:07:42+00:00 Robert Hooker wrote:

(In reply to comment #8)
> Created an attachment (id=38010) [details]
> dmesg of boot with modeset=1 (overlay kernel)
> 
> here's the dmesg of booting the overlay image with modeset=1 and drm.debug=0xe

cfritz@xxxxxxxxx: Try booting with vesafb=sodoff, i915.modeset=1 doesn't
stop vesafb from loading but the invalid module parameter will.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/40

------------------------------------------------------------------------
On 2010-08-24T15:43:52+00:00 Christian Wehrfritz wrote:

Created an attachment (id=38133)
dmesg.sodoff

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/41

------------------------------------------------------------------------
On 2010-08-24T15:44:25+00:00 Christian Wehrfritz wrote:

Created an attachment (id=38134)
dmesg.novesakernel

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/42

------------------------------------------------------------------------
On 2010-08-24T15:45:55+00:00 Christian Wehrfritz wrote:

> cfritz@xxxxxxxxx: Try booting with vesafb=sodoff, i915.modeset=1 doesn't stop
> vesafb from loading but the invalid module parameter will.

I had no module named vesafb - that was compiled into the kernel. The
dmesg.sodoff contains the dmesg from the run that you suggested. I then
compiled a kernel without vesafb (.config: # CONFIG_FB_VESA is not set),
the dmesg is dmesg.novesakernel. Note that I always booted into single
mode. (Booting into X, logging in, opening a xterm and pulling the dmesg
is a bit hard without a display)

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/43

------------------------------------------------------------------------
On 2010-08-24T19:32:52+00:00 Robert Hooker wrote:

(In reply to comment #16)
> > cfritz@xxxxxxxxx: Try booting with vesafb=sodoff, i915.modeset=1 doesn't stop
> > vesafb from loading but the invalid module parameter will.
> 
> I had no module named vesafb - that was compiled into the kernel. The
> dmesg.sodoff contains the dmesg from the run that you suggested. I then
> compiled a kernel without vesafb (.config: # CONFIG_FB_VESA is not set), the
> dmesg is dmesg.novesakernel. Note that I always booted into single mode.
> (Booting into X, logging in, opening a xterm and pulling the dmesg is a bit
> hard without a display)

Yeah it's not a module but you still stop it from loading by passing an
invalid option to it, no need to recompile :) Chris was just asking for
a log of that kernel without vesafb and it was still loading in the
dmesg you posted in comment 8.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/44

------------------------------------------------------------------------
On 2010-08-27T13:13:05+00:00 Sascha Lars Strodthoff wrote:

(In reply to comment #17)
> (In reply to comment #16)
> > > cfritz@xxxxxxxxx: Try booting with vesafb=sodoff, i915.modeset=1 doesn't stop
> > > vesafb from loading but the invalid module parameter will.
> > 
> > I had no module named vesafb - that was compiled into the kernel. The
> > dmesg.sodoff contains the dmesg from the run that you suggested. I then
> > compiled a kernel without vesafb (.config: # CONFIG_FB_VESA is not set), the
> > dmesg is dmesg.novesakernel. Note that I always booted into single mode.
> > (Booting into X, logging in, opening a xterm and pulling the dmesg is a bit
> > hard without a display)
> 
> Yeah it's not a module but you still stop it from loading by passing an invalid
> option to it, no need to recompile :) Chris was just asking for a log of that
> kernel without vesafb and it was still loading in the dmesg you posted in
> comment 8.


I have followed your description and tried it with the non.existing
parameters.

You can see it inside the dmesg in the attachment of launchpad post #27
https://bugs.launchpad.net/null/+bug/608907/comments/27 .

[ 0.000000] Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.36-020636rc2-generic root=UUID=7c27cd01
-d23e-4fd2-afb1-445ef72f3d0e ro quiet drm.debug=0xe i915.modeset=1
vesafb.grtfdse=0x34 novesafb single

I tried also vesafb=sodoff.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/48

------------------------------------------------------------------------
On 2010-08-27T14:00:20+00:00 Christian Wehrfritz wrote:


> I have followed your description and tried it with the non.existing parameters.

Well, not quite. If you take
 - the kernel from http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay and
 - a command line like BOOT_IMAGE=/boot/vmlinuz-2.6.36-rc1+ root=UUID=980cc70e-5947-4f68-93af-526b4eb3224e ro vesafb=sodoff single quiet splash

you'd get the dmesg they are interested in (and which I have already
posted 3 days ago, see dmesg.sodoff)

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/49

------------------------------------------------------------------------
On 2010-08-27T14:22:54+00:00 Sascha Lars Strodthoff wrote:

(In reply to comment #19)
> > I have followed your description and tried it with the non.existing parameters.
> 
> Well, not quite. If you take
>  - the kernel from http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay
> and
>  - a command line like BOOT_IMAGE=/boot/vmlinuz-2.6.36-rc1+
> root=UUID=980cc70e-5947-4f68-93af-526b4eb3224e ro vesafb=sodoff single quiet
> splash
> 
> you'd get the dmesg they are interested in (and which I have already posted 3
> days ago, see dmesg.sodoff)

thx!

ok, what else can we do to support the fixing process?

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/50

------------------------------------------------------------------------
On 2010-09-01T15:14:39+00:00 Sascha Lars Strodthoff wrote:

(In reply to comment #19)
> > I have followed your description and tried it with the non.existing parameters.
> 
> Well, not quite. If you take
>  - the kernel from http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=overlay
> and
>  - a command line like BOOT_IMAGE=/boot/vmlinuz-2.6.36-rc1+
> root=UUID=980cc70e-5947-4f68-93af-526b4eb3224e ro vesafb=sodoff single quiet
> splash
> 
> you'd get the dmesg they are interested in (and which I have already posted 3
> days ago, see dmesg.sodoff)

Is there anything that I can do at the moment?
Plz, let me know.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/51

------------------------------------------------------------------------
On 2010-09-06T09:44:47+00:00 Chris Wilson wrote:

All the latest Arrandale/DP fixes have been compiled into

http://cgit.freedesktop.org/~ickle/drm-intel/log/?h=drm-intel-staging

Please can you try that branch (which is essentially 2.6.36-rc3 +
regression fixes + eDP) to see if we have nailed the problem for 2.6.36.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/53

------------------------------------------------------------------------
On 2010-09-06T13:47:14+00:00 Christian Wehrfritz wrote:

> Please can you try that branch (which is essentially 2.6.36-rc3 + regression
> fixes + eDP) to see if we have nailed the problem for 2.6.36.

I did:
 git clone git://anongit.freedesktop.org/~ickle/drm-intel
 git checkout -b testing origin/drm-intel-staging

The screen is as black as ever. I'll attach the dmesg.36rc3
(drm.debug=0xe i915.modeset=1 vesafb=sodoff single)

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/55

------------------------------------------------------------------------
On 2010-09-06T13:48:49+00:00 Christian Wehrfritz wrote:

Created an attachment (id=38486)
dmesg of drm-intel-staging

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/56

------------------------------------------------------------------------
On 2010-09-07T05:25:26+00:00 Chris Wilson wrote:

Thanks for testing. It's just a normal LVDS panel, everything looks in
order... So why is it still black? Is the backlight still on? What else
could we be misprogramming? LVDS panel depth?

Can you download http://cgit.freedesktop.org/xorg/app/intel-gpu-tools
and build intel_reg_dumper and attach its output? Lets see if there are
any oddities in the registers.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/57

------------------------------------------------------------------------
On 2010-09-07T05:31:31+00:00 Chris Wilson wrote:

And I have to ask where did you find an Arrandale U160? Is it still a
11.1" chasis? That would make a good netbook...

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/58

------------------------------------------------------------------------
On 2010-09-07T06:41:48+00:00 Christian Wehrfritz wrote:

> Is the backlight still on?

I think so. The last thing I see is a ureadahead exit (Ubuntu 10.10),
then the screen goes totally black for a short moment, then it gets a
bit brighter, which looks like the LED backlight.

> Can you download http://cgit.freedesktop.org/xorg/app/intel-gpu-tools and build
> intel_reg_dumper and attach its output? Lets see if there are any oddities in
> the registers.

I pulled the regdump with the latest kernel, that you recommended, after
booting into drm.debug=0xe i915.modeset=1 vesafb=sodoff single

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/59

------------------------------------------------------------------------
On 2010-09-07T06:42:57+00:00 Christian Wehrfritz wrote:

Created an attachment (id=38513)
intel_reg_dump 2.6.36-rc3 after screen went black

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/60

------------------------------------------------------------------------
On 2010-09-07T06:51:32+00:00 Chris Wilson wrote:

Hmm, as expected they look fine.

Can you grab the same reg dump but with i915.modeset=0 (i.e. so I can
compare with what the BIOS is using)?

At this point, my suspicion is that we are failing to setup the FDI link
correctly. Does changing mode help? Can you also grab a reg dump with
i915.modeset=1 at 640x480?

X should be happy to run and change mode using xrandr, or you can use
modetest from libdrm.git.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/61

------------------------------------------------------------------------
On 2010-09-07T06:59:13+00:00 Christian Wehrfritz wrote:

(In reply to comment #26)
> And I have to ask where did you find an Arrandale U160?

It's a Lenovo Ideapad U160:
http://shop.lenovo.com/us/landing_pages/ideapad/2010/u-series

> Is it still a 11.1" chasis?

11.6"

> That would make a good netbook...

Well, up to now, I don't consider it good.. I've never had that much
trouble getting a laptop to run Linux during the last 15 years. The
panel that is not working is the most obvious annoyance. Besides that,
the WLan chip doesn't work with the vanilla kernel, the ethernet chip
doesn't work at all, yet (but I've read, that it should work with extra
drivers). And the audio out won't work with jackd.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/62

------------------------------------------------------------------------
On 2010-09-07T07:02:52+00:00 Christian Wehrfritz wrote:

Created an attachment (id=38514)
intel_reg_dump 2.6.36-rc3 with xforcevesa modeset=0

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/63

------------------------------------------------------------------------
On 2010-09-07T07:11:35+00:00 Chris Wilson wrote:

Ah, they don't seem to have made it to this side of the pond. Perhaps
Jesse can pick one up?

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/64

------------------------------------------------------------------------
On 2010-09-07T07:19:39+00:00 Chris Wilson wrote:

The biggest differences that stand out are:

vesa:
PCH_DREF_CONTROL: 0x00001002 (cpu source disable, ssc_source enable, nonspread_source disable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)
PCH_FPA1: 0x00030d07 (n = 3, m1 = 13, m2 = 7)
FDI_TXA_CTL: 0xb01c4000 (enable, train pattern not train, voltage swing 0.4V,pre-emphasis none, port width X4, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
FDI_RXA_CTL: 0xb01a2050 (enable, train pattern not train, port width X4, 6bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, PCDClk)
        
i915:
PCH_DREF_CONTROL: 0x00001402 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)
PCH_FPA1: 0x00010e05 (n = 1, m1 = 14, m2 = 5)
FDI_TXA_CTL: 0xb0044000 (enable, train pattern not train, voltage swing 0.4V,pre-emphasis none, port width X1, enhanced framing enable, FDI PLL enable, scrambing enable, master mode disable)
FDI_RXA_CTL: 0xb0022050 (enable, train pattern not train, port width X1, 6bpc,link_reverse_strap_overwrite no, dmi_link_reverse no, FDI PLL enable,FS ecc disable, FE ecc disable, FS err report disable, FE err report disable,scrambing enable, enhanced framing enable, PCDClk)
   

That is we attempt to use a single lane for driving the FDI with spread-
spectrum, whereas bios/vesa uses 4 lanes (and no ssc).

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/65

------------------------------------------------------------------------
On 2010-09-07T10:10:25+00:00 Chris Wilson wrote:

Stab in the dark, let's boost the b/w to the panel:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 2951552..64240f1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3706,6 +3706,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
                         */
                        u32 bps = target_clock * bpp * 21 / 20;
                        lane = bps / (link_bw * 8) + 1;
+                       lane = 4; /* XXX bug 29647 */
                }
 
                intel_crtc->fdi_lanes = lane;

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/66

------------------------------------------------------------------------
On 2010-09-07T10:22:53+00:00 Chris Wilson wrote:

But we should be using around 57% of the b/w of a single lane for your
panel configuration. So it might be the PLL configuration instead...

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/67

------------------------------------------------------------------------
On 2010-09-07T11:26:15+00:00 Chris Wilson wrote:

What is the output of sudo intel-gpu-tools/tools/intel_reg_read 0x46000
?

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/68

------------------------------------------------------------------------
On 2010-09-07T12:16:08+00:00 Christian Wehrfritz wrote:

The patch didn't work, it's still black.

(In reply to comment #36)
> What is the output of sudo intel-gpu-tools/tools/intel_reg_read 0x46000 ?

0x46000 : 0x82B3019

for both, the vesa kernel, and the patched kernel (vesafb=sodoff single)

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/69

------------------------------------------------------------------------
On 2010-09-07T12:46:12+00:00 Chris Wilson wrote:

Found it in the reg_dumper: FDI_PLL_BIOS_0: 0x082b3019

Ok, so not an unusual FDI configuration.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/70

------------------------------------------------------------------------
On 2010-09-07T12:57:58+00:00 Chris Wilson wrote:

Next stab before diving into the PLL maze, disable the nonspread source:


diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index 1f6196a..fd74159 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3730,7 +3730,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
                temp = I915_READ(PCH_DREF_CONTROL);
                /* Always enable nonspread source */
                temp &= ~DREF_NONSPREAD_SOURCE_MASK;
-               temp |= DREF_NONSPREAD_SOURCE_ENABLE;
+               //temp |= DREF_NONSPREAD_SOURCE_ENABLE;
                I915_WRITE(PCH_DREF_CONTROL, temp);
                POSTING_READ(PCH_DREF_CONTROL);

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/71

------------------------------------------------------------------------
On 2010-09-07T13:39:41+00:00 Christian Wehrfritz wrote:

(In reply to comment #39)
> Next stab before diving into the PLL maze, disable the nonspread source:

I did that (and removed the lane = 4;). It did not help.

Before we go diving, two questions:
 - I assume, it's sufficient, to `make modules; make modules_install`, instead of building a new kernel the ubuntu way (sudo make-kpkg --initrd kernel_image kernel_headers; sudo dpkg -i linux-image-2.6.*.Custom_i386.deb), right?

 - if I test one of your patches, what output do you want me to attach?
reg_dump and dmesg, every time?

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/72

------------------------------------------------------------------------
On 2010-09-07T13:46:36+00:00 Chris Wilson wrote:

(In reply to comment #40)
> (In reply to comment #39)
> > Next stab before diving into the PLL maze, disable the nonspread source:
> 
> I did that (and removed the lane = 4;). It did not help.
> 
> Before we go diving, two questions:
>  - I assume, it's sufficient, to `make modules; make modules_install`, instead
> of building a new kernel the ubuntu way (sudo make-kpkg --initrd kernel_image
> kernel_headers; sudo dpkg -i linux-image-2.6.*.Custom_i386.deb), right?

Hmm, I've had issues where i915 is included in the initrd and so had to
rerun update-initramfs which was not happening automatically on Ubuntu.
Though I don't use initramfs unless I'm building a full disto-equivalent
kernel, so I may be misinformed.

>  - if I test one of your patches, what output do you want me to attach?
> reg_dump and dmesg, every time?

For those two stabs, the quickest way to check would be through
intel_reg_dumper. dmesg doesn't contain the relevant information unless
we patch it in.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/73

------------------------------------------------------------------------
On 2010-09-07T14:30:56+00:00 Christian Wehrfritz wrote:

(In reply to comment #41)

> For those two stabs, the quickest way to check would be through
> intel_reg_dumper.

ok, the diff between the rc3 and the disabled nonspread source is:
root@cfritz-laptop:~# diff regs.36rc3 regs.disable_nonspread_source 
64c64
<     PCH_DREF_CONTROL: 0x00001402 (cpu source disable, ssc_source enable, nonspread_source enable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)
---
>     PCH_DREF_CONTROL: 0x00001002 (cpu source disable, ssc_source enable, nonspread_source disable, superspread_source disable, ssc4_mode downspread, ssc1 enable, ssc4 disable)

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/74

------------------------------------------------------------------------
On 2010-09-11T00:59:10+00:00 Chris Wilson wrote:

Jesse reorganised the code around the FDI setup and worked on a few bugs
that implied we weren't setting up the panel in the right order, and
there were a few missing flushes whilst training the FDI...

So nothing that purports to explicitly target this bug, but I think
we're heading the right direction!

Can you check with the current code:

git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-
intel-next

and see how we are faring?

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/75

------------------------------------------------------------------------
On 2010-09-11T14:31:05+00:00 Christian Wehrfritz wrote:

> Can you check with the current code:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
> drm-intel-next
> 
> and see how we are faring?

It looks the same (black), but there are changes in the reg dumps.

I don't think that this has side effects on the panel, but Lenovo also screwed up turbo boost on this unit:
"The resistor locations that select the CPU type installed were populated with values for the i3 CPU rather than the i5 or i7.  As a result the Turbo mode does not function correctly, and overall performance is limited." (http://forums.lenovo.com/t5/IdeaPad-Y-U-B-and-Z-series/U160-Turbo-Boost-broken/td-p/268106/page/2).

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/76

------------------------------------------------------------------------
On 2010-09-11T14:32:18+00:00 Christian Wehrfritz wrote:

Created an attachment (id=38633)
intel_reg_dump kernel drm-intel-next

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/77

------------------------------------------------------------------------
On 2010-09-11T14:49:44+00:00 Chris Wilson wrote:

Aye no change, just we now use the "wrong" pipe for initial output
(there will be a slight flicker as it changes) due to bug 30126.

Thanks for checking. Looks like we may have to do a few more stabs to
see if we can find an "easy" solution.

Reply at: https://bugs.launchpad.net/linux/+bug/608907/comments/78


** Changed in: linux
       Status: Unknown => Confirmed

** Changed in: linux
   Importance: Unknown => Critical

-- 
[lucid][maverick][i915] Lenovo U160 Intel i7 620UM blank screen
https://bugs.launchpad.net/bugs/608907
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for NULL Project.