Stable kernel 3.8.3 appears to break displayport on intel gen4

Stable kernel 3.8.3 appears to break displayport on intel gen4

[Sergio Callegari]

Hi,

     hope sending this message here is OK. In case it is not please take my 
apology.

This is just a short note to let you know that after installing 3.8.3, display 
port stopped working on my laptop. Going back to 3.8.2 brought it back to life.
This has been tested with the ubuntu mainline kernels that should be vanilla 
stable kernels. Hope this is not an incorrect report due to something wrong on 
their side. Laptop is a DELL E6500 with intel gen4 integrated graphics (Intel 
Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)).
With 3.8.3, xrandr does not report anymore the external monitor when it is 
actually attached via displayport.

Thanks for the attention and best regards,

Sergio Callegari

Re: Stable kernel 3.8.3 appears to break displayport on intel gen4

[Bjørn Mork]

Sergio Callegari <sergio.callegari@gmail.com> writes:

> This is just a short note to let you know that after installing 3.8.3,
> display port stopped working on my laptop. Going back to 3.8.2 brought
> it back to life.
> This has been tested with the ubuntu mainline kernels that should be
> vanilla stable kernels. Hope this is not an incorrect report due to
> something wrong on their side. Laptop is a DELL E6500 with intel gen4
> integrated graphics (Intel Corporation Mobile 4 Series Chipset
> Integrated Graphics Controller (rev 07)).
> With 3.8.3, xrandr does not report anymore the external monitor when
> it is actually attached via displayport.

I can confirm seeing this bug on:

# lspci -nnvvvs 00:02.0
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
        Subsystem: Lenovo Device [17aa:20e4]
        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 45
        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: fee0300c  Data: 4152
        Capabilities: [d0] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: i915



Looking through the changes from v3.8.2 to v3.8.3, there weren't really
that many suspects.  This partial (to avoid having to change any
following patches) revert of commit 2a98104 ("drm/i915: reorder setup
sequence to have irqs for output setup") fixes the problem for me.  I
have no idea why, so I leave it to Daniel and the other wise men working
on this driver to explain and cleanup :)


---
 drivers/gpu/drm/i915/i915_dma.c |   14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5206f24..b15b65d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device *dev)
 	if (ret)
 		goto cleanup_vga_switcheroo;
 
-	ret = drm_irq_install(dev);
-	if (ret)
-		goto cleanup_gem_stolen;
-
-	/* Important: The output setup functions called by modeset_init need
-	 * working irqs for e.g. gmbus and dp aux transfers. */
 	intel_modeset_init(dev);
 
 	ret = i915_gem_init(dev);
 	if (ret)
-		goto cleanup_irq;
+		goto cleanup_gem_stolen;
+
+	intel_modeset_gem_init(dev);
 
 	INIT_WORK(&dev_priv->console_resume_work, intel_console_resume);
 
-	intel_modeset_gem_init(dev);
+	ret = drm_irq_install(dev);
+	if (ret)
+		goto cleanup_gem;
 
 	/* Always safe in the mode setting case. */
 	/* FIXME: do pre/post-mode set stuff in core KMS code */

Re: Stable kernel 3.8.3 appears to break displayport on intel gen4

[Daniel Vetter]

On Mon, Mar 18, 2013 at 04:59:35PM +0100, Bjørn Mork wrote:
> Sergio Callegari <sergio.callegari@gmail.com> writes:
> 
> > This is just a short note to let you know that after installing 3.8.3,
> > display port stopped working on my laptop. Going back to 3.8.2 brought
> > it back to life.
> > This has been tested with the ubuntu mainline kernels that should be
> > vanilla stable kernels. Hope this is not an incorrect report due to
> > something wrong on their side. Laptop is a DELL E6500 with intel gen4
> > integrated graphics (Intel Corporation Mobile 4 Series Chipset
> > Integrated Graphics Controller (rev 07)).
> > With 3.8.3, xrandr does not report anymore the external monitor when
> > it is actually attached via displayport.
> 
> I can confirm seeing this bug on:
> 
> # lspci -nnvvvs 00:02.0
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller])
>         Subsystem: Lenovo Device [17aa:20e4]
>         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 45
>         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: fee0300c  Data: 4152
>         Capabilities: [d0] Power Management version 3
>                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Kernel driver in use: i915
> 
> 
> 
> Looking through the changes from v3.8.2 to v3.8.3, there weren't really
> that many suspects.  This partial (to avoid having to change any
> following patches) revert of commit 2a98104 ("drm/i915: reorder setup
> sequence to have irqs for output setup") fixes the problem for me.  I
> have no idea why, so I leave it to Daniel and the other wise men working
> on this driver to explain and cleanup :)

Already taken care of hopefully:

http://lists.freedesktop.org/archives/intel-gfx/2013-March/025767.html

My apologies to everyone who's suffering through this breakage, it looks
like I've managed to serious burn myself with an innocent looking stable
backport :(

Yours, Daniel

> 
> 
> ---
>  drivers/gpu/drm/i915/i915_dma.c |   14 ++++++--------
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 5206f24..b15b65d 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1297,21 +1297,19 @@ static int i915_load_modeset_init(struct drm_device *dev)
>  	if (ret)
>  		goto cleanup_vga_switcheroo;
>  
> -	ret = drm_irq_install(dev);
> -	if (ret)
> -		goto cleanup_gem_stolen;
> -
> -	/* Important: The output setup functions called by modeset_init need
> -	 * working irqs for e.g. gmbus and dp aux transfers. */
>  	intel_modeset_init(dev);
>  
>  	ret = i915_gem_init(dev);
>  	if (ret)
> -		goto cleanup_irq;
> +		goto cleanup_gem_stolen;
> +
> +	intel_modeset_gem_init(dev);
>  
>  	INIT_WORK(&dev_priv->console_resume_work, intel_console_resume);
>  
> -	intel_modeset_gem_init(dev);
> +	ret = drm_irq_install(dev);
> +	if (ret)
> +		goto cleanup_gem;
>  
>  	/* Always safe in the mode setting case. */
>  	/* FIXME: do pre/post-mode set stuff in core KMS code */
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch