Re: Bug/Patch : resolved i830 black screen

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Jan 05, 2014 at 10:48:18PM +0100, Thomas Richter wrote:
> Dear intel-experts,
> 
> a while ago I reported that the latest kernel from intel-drm-nightly 
> broke operations on i830 completely. In the meantime,
> I found the reason. The trouble is in intel_crtcl_init():
> 
> static void intel_crtc_init(struct drm_device *dev, int pipe)
> {
> 
>      ....
> 
>      /*
>       * On gen2/3 only plane A can do fbc, but the panel fitter and lvds 
> port
>       * is hooked to plane B. Hence we want plane A feeding pipe B.
>       */
>      intel_crtc->pipe = pipe;
>      intel_crtc->plane = pipe;
>      if (IS_MOBILE(dev) && IS_GEN3(dev)) {
>          DRM_DEBUG_KMS("swapping pipes & planes for FBC\n");
>          intel_crtc->plane = !pipe;
>      }
> 
> The new code has here the condition "IS_MOBILE(dev) && 
> INTEL_INFO(dev)->gen < 4", which however, gives a nonworking
> display on my Fujitsu-Siemens. Apparently, this swap is not correct. It 
> might do the right thing on gen3 (I do not have a
> gen3-based system so I cannot verify), but it does not work on GEN2. The 
> check (as above) conditioned on IS_GEN3() only
> restores a working display on this system.

I got my hands on a 830M laptop as well and found the same thing. The
real issue seems to be that that pipe B must be also be enabled when
moving plane B from pipe B to A, even if the plane is already disabled.
As a quick fix I have a patch to limit the plane swapping to FBC
capabable platforms (which 830M is not). I'll post that ASAP.

> 
> Two additional observations:
> 
> 1) Panning did not work on i830 due to an incorrect watermark setting. 
> The watermark register must be at least 6 *on this specific machine*. On 
> the R31, it had to be at least four.

I noticed we're slightly miscalculating the plane A FIFO size, but I'm
not sure that can explain the panning issues. I'll have to test it on
my 830M machine at some point.

> 
> 2) I do not seem to need the PIPE_A workaround on this Fujitsu laptop. 
> It also boots with disabling the quirk. I have not tested suspend to 
> ram, but it did not work before, and it likely does not work now. 
> Probably the pipe A quirk is only required for suspend to ram?

Acocrding to folk lore DPLL B is somehow slaved to DPLL A, so if you
want to use pipe B you need DPLL A still running. I've not found any
note about this in the docs though. There are a few other DPLL related
problems noted in the docs however, and I'm not sure we handle all of
them properly.

> 
> Even without the pipe A quirk, the bios seems to keep pipe A busy. At 
> least this is what I get from xrandr:
> 
> Screen 0: minimum 320 x 200, current 2048 x 1536, maximum 2048 x 2048
> VGA1 unknown connection (normal left inverted right x axis y axis)
>     1360x768       59.8
>     1152x864       60.0
>     1024x768       60.0
>     800x600        60.3
>     640x480        59.9
> DVI1 connected 2048x1536+0+0 (normal left inverted right x axis y axis) 
> 0mm x 0mm panning 2048x1536+0+0
>     1024x768       60.0*
>     800x600        60.3     56.2
>     640x480        59.9
> 
> Greetings and Happy New Year,
> 
> Thomas
> 
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux