[Intel-gfx] [PATCH] drm/i915: Don't rmw PIPESTAT enable bits

[Chris Wilson]

Quoting Ville Syrjälä (2017-09-25 15:05:51)
> On Fri, Sep 15, 2017 at 01:03:36PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 14, 2017 at 09:37:37PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjala (2017-09-14 16:17:31)
> > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > i830 seems to occasionally forget the PIPESTAT enable bits when
> > > > we read the register. These aren't the only registers on i830 that
> > > > have problems with RMW, as reading the double buffered plane
> > > > registers returns the latched value rather than the last written
> > > > value. So something similar is perhaps going on with PIPESTAT.
> > > > 
> > > > This corruption results on vblank interrupts occasionally turning off
> > > > on their own, which leads to vblank timeouts and generally a stuck
> > > > display subsystem.
> > > > 
> > > > So let's not RMW the pipestat enable bits, and instead use the cached
> > > > copy we have around.
> > > > 
> > > > Cc: Imre Deak <imre.deak at intel.com>
> > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > 
> > > Well it didn't make my 845g any worse. Still has
> > > 
> > > [  245.683349] [drm:pipe_config_err] *ERROR* mismatch in base.adjusted_mode.flags (2) (expected 0, found 2)
> > > [  245.683382] [drm:pipe_config_err] *ERROR* mismatch in base.adjusted_mode.flags (8) (expected 0, found 8)
> > > [  245.683427] pipe state doesn't match!
> > > 
> > > if you are interested.
> > 
> > That's a bit odd. Even if the mode originally doesn't have any
> > hsync/vsync flags intel_modeset_pipe_config() should give it some.
> > So I can't immediately see how we could manage to get there with
> > expected==0.
> 
> Hmm. Does you 845g have DVO encoders? That could potentially explain if
> it ends up using intel_crtc_mode_get(). That one fails to read out the
> sync flags correctly, and it has other issues as well.

CRTC info
---------
CRTC 31: pipe: A, active=yes, (size=1024x768), dither=no, bpp=24
	fb: 39, pos: 0x0, size: 1024x768
	encoder 34: type: DVO C, connectors:
		connector 35: type: LVDS-1, status: connected, mode:
		id 0:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x8 flags 0x0
	cursor visible? no, position (0, 0), size 0x0, addr 0x00000000
	No scalers available on this platform
	--Plane id 27: type=PRI, crtc_pos=   0x   0, crtc_size=1024x 768, src_pos=0.0000x0.0000, src_size=1024.0000x768.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001)
	--Plane id 29: type=CUR, crtc_pos=   0x   0, crtc_size=   0x   0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001)
	underrun reporting: cpu=yes pch=yes 

Connector info
--------------
connector 35: type LVDS-1, status: connected
	name: 
	physical dimensions: 0x0mm
	subpixel order: Horizontal RGB
	CEA rev: 0
	modes:
		id 37:"1024x768" freq 60 clock 65000 hdisp 1024 hss 1048 hse 1184 htot 1344 vdisp 768 vss 771 vse 777 vtot 806 type 0x8 flags 0x0
connector 32: type VGA-1, status: unknown
	modes:

So yes, it appears LVDS is attached via DVO.

> https://patchwork.freedesktop.org/series/5183/ but not sure it applies
> cleanly anymore.

It has two chances...
-Chris