Home » Mailing list archives » linux-kernel » 2011 » January » 3

Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard

Previous thread: [PATCH] new UDPCP Communication Protocol by stefani on Monday, January 3, 2011 - 7:34 am. (1 message)

Next thread: [PATCH] x86: fix section mismatch in LAPIC initialization by Jan Beulich on Monday, January 3, 2011 - 8:03 am. (3 messages)
[view original message]
From: Knut Petersen
Subject: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 7:25 am

Hi everybody!

The AOpen i915GMm-HFS is a desktop motherboard for the Intel Pentium M.
A mobile chipset is used
(Intel 915GM / ICH6-M). Kernel 2.6.31.14 works fine for that mobo, but
from 2.6.32 on graphics support
is broken because the i915 driver "detects" an lvds device with a
resolution of 1024x768 pixels that in reality
is not present. Unfortunately the driver assumes that the "detected"
lvds is the primary screen and uses the
wrong resolution also for the real VGA and DVI connectors.

Obvious solution: The motherboard needs an entry in the intel_no_lvds
blacklist in intel_lvds.c

Kernel version       Comment
======================
2.6.37-rc8-git2      patch applies cleanly and fixes the problem.
2.6.36.2:                patch applies with a few lines offset, fixed
the problem
2.6.32 to 2.6.35:   Not tested
2.6.31 / older         Not needed

Signed-off-by: Knut Petersen <knut_petersen@t-online.de>


--- linux-2.6.37-rc8-git2/drivers/gpu/drm/i915/intel_lvds.c   
2010-12-29 02:05:48.000000000 +0100
+++ linux-2.6.37-rc8-git2-kp/drivers/gpu/drm/i915/intel_lvds.c   
2011-01-03 13:48:38.000000000 +0100
@@ -708,6 +708,14 @@ static const struct dmi_system_id intel_
             DMI_MATCH(DMI_PRODUCT_VERSION, "AO00001JW"),
         },
     },
+        {
+                .callback = intel_no_lvds_dmi_callback,
+                .ident = "AOpen motherboard i915GMm-HFS",
+                .matches = {
+                        DMI_MATCH(DMI_BOARD_VENDOR, "AOpen"),
+                        DMI_MATCH(DMI_BOARD_NAME, "i915GMm-HFS"),
+                },
+        },
     {
         .callback = intel_no_lvds_dmi_callback,
         .ident = "Clientron U800",

--


[ message continues ]
[view original message]
From: Chris Wilson
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 7:54 am

Can you try:

diff --git a/drivers/gpu/drm/i915/intel_i2c.c
b/drivers/gpu/drm/i915/intel_i2c.c
index 58040f6..111128d 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -384,7 +384,7 @@ int intel_setup_gmbus(struct drm_device *dev)
                bus->reg0 = i | GMBUS_RATE_100KHZ;
 
                /* XXX force bit banging until GMBUS is fully debugged */
-               bus->force_bit = intel_gpio_create(dev_priv, i);
+               //bus->force_bit = intel_gpio_create(dev_priv, i);
        }
 
        intel_i2c_reset(dev_priv->dev);
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--


[ message continues ]
[view original message]
From: Knut Petersen
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 11:12 am

Am 03.01.2011 15:54, schrieb Chris Wilson:

I tried 2.6.37-rc8-git2 with both patches applied.

Well, your patch does not hurt, the system runs fine. But my patch is
still needed as the intel_no_lvds_dmi_callback is called:

<6>[    2.131481] agpgart-intel 0000:00:00.0: Intel 915GM Chipset
<6>[    2.131668] agpgart-intel 0000:00:00.0: detected gtt size: 262144K
total, 262144K mappable
<6>[    2.132594] agpgart-intel 0000:00:00.0: detected 8192K stolen memory
<6>[    2.135338] agpgart-intel 0000:00:00.0: AGP aperture is 256M @
0xc0000000
<6>[    2.135551] [drm] Initialized drm 1.1.0 20060810
<6>[    2.135703] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) ->
IRQ 16
<7>[    2.135843] i915 0000:00:02.0: setting latency timer to 64
<7>[    2.139787] [drm:parse_general_definitions], crt_ddc_bus_pin: 2
<7>[    2.139824] [drm:parse_lfp_panel_data], Found panel mode in BIOS
VBT tables:
<7>[    2.139827] [drm:drm_mode_debug_printmodeline], Modeline
0:"1024x768" 0 65000 1024 1048 1184 1344 768 771 777 806 0x8 0xa
<7>[    2.139899] [drm:parse_sdvo_device_mapping], the SDVO device with
slave addr 70 is found on SDVOB port
<7>[    2.139903] [drm:parse_sdvo_device_mapping], SDVO device: dvo=1,
addr=70, wiring=1, ddc_pin=29, i2c_pin=5, i2c_speed=83
<7>[    2.139909] [drm:parse_sdvo_device_mapping], the SDVO device with
slave addr 72 is found on SDVOC port
<7>[    2.139913] [drm:parse_sdvo_device_mapping], SDVO device: dvo=2,
addr=72, wiring=0, ddc_pin=29, i2c_pin=5, i2c_speed=32
<7>[    2.139970] [drm:intel_modeset_init], 2 display pipes available.
<7>[    2.139977] [drm:intel_crtc_init], swapping pipes & planes for FBC
<7>[    2.139984] [drm:intel_crtc_init], swapping pipes & planes for FBC
<7>[    2.139990] [drm:intel_no_lvds_dmi_callback], Skipping LVDS

--


[ message continues ]
[view original message]
From: Linus Torvalds
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 12:45 pm

On Mon, Jan 3, 2011 at 10:12 AM, Knut Petersen

I thought Chris meant "instead of", rather than "both". Chris?

                Linus
--


[ message continues ]
[view original message]
From: Chris Wilson
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 12:59 pm

Right, I was trying to ascertain whether the intel_lvds_ddc_probe()
correctly detected the missing panel. That function currently requires
GMBUS to differentiate between a NAK and an IO error (bitbanging just
returns EREMOTEIO regardless, iirc). So far it has been successful in
detecting one false-positive for an AOpen All-in-one and hasn't fouled
up LVDS detection for the laptops I have.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--


[ message continues ]
[view original message]
From: Linus Torvalds
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 1:26 pm

[ related, but independent, issue ]


Hmm. That sounds like something that would be worth fixing regardless
and independently of this. I'd expect that a lot of users would care
whether there was an actual protocol error or whether the command got
a NAK. There's a big difference between "those lines don't seem to
even be connected to anything" and "the other end didn't like us".

Even the comments in the bitbanging code seem to say that it should be
returning ETIMEDOUT etc for when there is no answer (and the low-level
"i2c_outb()" seems to do that), but then the code does seem to ignore
all that information and turn all errors into EREMOTEIO.

Which sounds bogus.

Added Jean to the cc in case he has some input (or knows who we should
bug about algo-bit.c). Also David Brownell, because he touched an
error code in that file two and a half years ago, so he now owns it
forever ;)

                         Linus
--


[ message continues ]
[view original message]
From: Knut Petersen
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 4:09 pm

Am 03.01.2011 20:59, schrieb Chris Wilson:

So I did some additional compiles and tests. The distribution used is
openSuSE 11.3.

openSuSE 11.3 kernel
=================
System locks up while starting X, hard reset is needed.


Kernel 2.6.31.14
=============

VGA and DVI connectors do work as expected.
xrandr shows VGA1, DVI1, TV1 and TV2. Thats correct, these are the
connectors
present on the i915GMm-HFS mobo. But read from boot.msg:

agpgart-intel 0000:00:00.0: Intel 915GM Chipset
agpgart-intel 0000:00:00.0: detected 7932K stolen memory
agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xc0000000
[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
[i915_sdvo:intel_sdvo_init], SDVOB device VID/DID: 02:3C.06, clock range
25MHz - 200MHz, input 1: Y, input 2: N, output 1: Y, output 2: N
[i915_sdvo:intel_sdvo_init], SDVOC device VID/DID: 02:C2.01, clock range
25MHz - 166MHz, input 1: Y, input 2: N, output 1: Y, output 2: N
[drm] TV-12: set mode NTSC 480i 0
render error detected, EIR: 0x00000010
page table error
PGTBL_ER: 0x00000010
[drm:i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
render error detected, EIR: 0x00000010
page table error
PGTBL_ER: 0x00000010
[drm] DAC-6: set mode 1280x1024 2c
[drm] TMDS-8: set mode 1280x1024 2d
Console: switching to colour frame buffer device 160x64
[drm] fb0: inteldrmfb frame buffer device
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0


Kernel 2.6.37-rc8-git2
=================

text mode console: ok, resolution 1280x1024, fully used by framebuffer
output
X: first device detected is LVDS with resolution 1024x768. VGA and DVI
connector work in X,
but X switches to 1024x768 for both of them. xrandr reports the four
physical connectors but
also LVDS, VGA2 and TV3 connectors.


Kernel 2.6.37-rc8-git2 + patch Chris Wilson
=================================

VGA connector broken for both framebuffer ...
[ message continues ]
[view original message]
From: Chris Wilson
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 4:22 pm

A false detection of the LVDS would appear to be a minor issue compared to
all the trouble you have. Can you add drm.debug=0xe to your boot
commandline and attach the resulting dmesg?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
--


[ message continues ]
[view original message]
From: Knut Petersen
Subject: Re: [PATCH] Fix i915 drm regression on AOpen i915GMm-HFS motherboard
Date: Monday, January 3, 2011 - 5:35 pm

Am 04.01.2011 00:22, schrieb Chris Wilson:

Well, here are the kernel messages from boot.msg.

dmesg output did not work ... there were 200000+  messages like
"[drm:intel_prepare_page_flip], preparing flip with no unpin work?" that
filled the
syslog until X had started up. A really verbose log. It's 1:27 CET, I'll
have to
take a nap now.

BTW: "All the trouble"? Not really. It believe that I have a special
talent to buy the
least supported hardware ... for my previous mobo I had to write a
working framebuffer
driver (cyblafb, now dropped from the kernel), and the PC I used before
that refused
to boot from CD until I hacked isolinux to patch BIOS pointers at
runtime ;-)

cu,


[ message continues ]
Previous thread: [PATCH] new UDPCP Communication Protocol by stefani on Monday, January 3, 2011 - 7:34 am. (1 message)

Next thread: [PATCH] x86: fix section mismatch in LAPIC initialization by Jan Beulich on Monday, January 3, 2011 - 8:03 am. (3 messages)