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
