Created attachment 37955 [details]
vbios

Created attachment 37956 [details]
intel_reg_dump

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.)

(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?

(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

> 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

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?

Created attachment 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

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).

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

(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.

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

(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@gmail.com: Try booting with vesafb=sodoff, i915.modeset=1 doesn't stop vesafb from loading but the invalid module parameter will.

Created attachment 38133 [details]
dmesg.sodoff

Created attachment 38134 [details]
dmesg.novesakernel

> cfritz@gmail.com: 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)

(In reply to comment #16)
> > cfritz@gmail.com: 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.

(In reply to comment #17)
> (In reply to comment #16)
> > > cfritz@gmail.com: 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.

> 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)

(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?

(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.

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.

> 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)

Created attachment 38486 [details]
dmesg of drm-intel-staging

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.

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...

> 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

Created attachment 38513 [details]
intel_reg_dump 2.6.36-rc3 after screen went black

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.

(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.

Created attachment 38514 [details]
intel_reg_dump 2.6.36-rc3 with xforcevesa modeset=0

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

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).

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;

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...

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

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)

Found it in the reg_dumper: FDI_PLL_BIOS_0: 0x082b3019

Ok, so not an unusual FDI configuration.

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);

(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?

(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.

(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)

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?

> 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).

Created attachment 38633 [details]
intel_reg_dump kernel drm-intel-next

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.

Considering that the panel works in ms windows, are there any intel_reg_dumper-like tools for windows, that I could check?

Anything else we could try?

I'm having one with i3 so i think this affects all U160:s.

Bug #29278 http://bugs.freedesktop.org/show_bug.cgi?id=29278 looks very similar to this and patch is already available. Did anyone try that yet?

(In reply to comment #49)
> Bug #29278 http://bugs.freedesktop.org/show_bug.cgi?id=29278 looks very similar
> to this and patch is already available. Did anyone try that yet?

I compiled the current drm-staging today, but it still goes black.

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

What would be those next stabs?

I'm experiencing the same issue on a new U160-0894 (i5-470UM, working Turbo). I've tried current (Thu Oct 28 15:22:13 PDT 2010) versions of the fixes/next/staging branches to no effect. 

To be clear:
Backlight is on, no output appears once the i915 driver loads.
External monitor works fine.
i915.modeset=0 'works', but of course the intel driver then cannot load later.
No other framebuffer driver is compiled in and dmesg says: "fbcon: inteldrmfb (fb0) is primary device"

In my dmesg I'm also seeing: "[drm:intel_panel_get_max_backlight] *ERROR* fixme: max PWM is zero."

Which I did not see in either of the posted dmesg outputs. However the backlight appears to be fine, and even responds to the Fn+Up/Down controls while the screen is blank (more or less bleed-through), so probably not useful.

Please let me know what I can do to help.

I would also like to help with anything that's possible.

I would even spend a decent amount of money if this can help to resolve the
issue quicker. If someone wants to tackle this task as freelancer, feel free
to contact me and we will discuss the details then.

Am 2010 10 28 23:43 schrieb <bugzilla-daemon@freedesktop.org>:
> https://bugs.freedesktop.org/show_bug.cgi?id=29647
>
> Vietor Davis <vietor@zettabytestorage.com> changed:
>
> What |Removed |Added
>
----------------------------------------------------------------------------
> CC| |vietor@zettabytestorage.com
>
> --- Comment #52 from Vietor Davis <vietor@zettabytestorage.com> 2010-10-28
15:43:36 PDT ---
> I'm experiencing the same issue on a new U160-0894 (i5-470UM, working
Turbo).
> I've tried current (Thu Oct 28 15:22:13 PDT 2010) versions of the
> fixes/next/staging branches to no effect.
>
> To be clear:
> Backlight is on, no output appears once the i915 driver loads.
> External monitor works fine.
> i915.modeset=0 'works', but of course the intel driver then cannot load
later.
> No other framebuffer driver is compiled in and dmesg says: "fbcon:
inteldrmfb
> (fb0) is primary device"
>
> In my dmesg I'm also seeing: "[drm:intel_panel_get_max_backlight] *ERROR*
> fixme: max PWM is zero."
>
> Which I did not see in either of the posted dmesg outputs. However the
> backlight appears to be fine, and even responds to the Fn+Up/Down controls
> while the screen is blank (more or less bleed-through), so probably not
useful.
>
> Please let me know what I can do to help.
>
> --
> Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.

Using intel_reg_dumper, the suggestions in this discussion, and a bit of poking around, I've attempted to harmonize the output from intel_reg_dumper between the plain no-frame-buffer output, and the intelfb using KMS.

Specifically I'm using the drm-intel-fixes branch of the current version of drm-intel, and have applied the two suggestions in this thread, and reverted commit 12e8ba25ef52f19e7a42e61aecb3c1fef83b2a82.

None of this has caused any change in behavior which I've noticed, but the diff of the intel_reg_dumper output is getting fairly small and perhaps someone who actually has some idea what they are doing can find some insight in it.

Created attachment 40129 [details]
fulltext of intel_reg_dumper showing diff between no-fb (as -) and intelfb (as +)

I have an additional piece of information that other users did not report. I can reproduce this bug on my Lenovo U160 laptop. When loading i915.ko, the laptop display panel (LVDS) becomes blank. However I discovered that what actually happens is that the moment i915.ko is loaded, the output switches to HDMI. I found this out by connecting a monitor to the laptop's HDMI output while the LCD panel was blank.

Like many reporters, I can reproduce the bug with different kernels: Ubuntu 10.10's 2.6.35-based kernel, as well as a vanilla 2.6.36.

After discovering this, I tried playing with "xrandr --output LVDS --auto" (and --off) but all it seems to do is to turn the backlight on and off. The display remains blank.

PS: Vietor Davis' last message reveals what seems to be an important difference in the registers, between using vesa and i915:
-                  CPU_VGACNTRL: 0x0020298e (enabled)
+                  CPU_VGACNTRL: 0x80000000 (disabled)
Anyone can comment on this?

Marc Bevand:
"However I discovered that what actually happens is that the moment i915.ko is loaded, the output switches to HDMI. I found this out by connecting a monitor to the laptop's HDMI output while the LCD panel was blank."

I do not think this is correct, rather I think what you are seeing is the HDMI port correctly detect a connection and begin using it. I can plug a VGA connector into my U160 and see the same behavior you describe, however, if you look at "/sys/class/drm/card0-*/enabled" I think you'll see what's actually happening here (At least what I *think* is happening...). 

To begin with, in my configuration, only "/sys/class/drm/card0-LVDS-1/enabled" says 'enabled', however, as I plug in a VGA connector "/sys/class/drm/card0-VGA-1/enabled" transitions from 'disabled' to 'enabled' and I see the expected output on the monitor.

It looks very much like everything is working, except the LVDS output.

*** This bug has been marked as a duplicate of bug 31596 ***

Applied the patch posted in the other thread manually as it hadn't shown up in git yet. Confirmed fixed my U160 model 0894 with a U470 (i5-470UM) CPU. 

Thank you Chris, you've made my week.