public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Thomas Richter <thor@math.tu-berlin.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: Bug/Patch : resolved i830 black screen
Date: Tue, 7 Jan 2014 15:53:12 +0200	[thread overview]
Message-ID: <20140107135312.GB4800@intel.com> (raw)
In-Reply-To: <52C9D322.7020304@math.tu-berlin.de>

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@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC

      reply	other threads:[~2014-01-07 13:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-05 21:48 Bug/Patch : resolved i830 black screen Thomas Richter
2014-01-07 13:53 ` Ville Syrjälä [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140107135312.GB4800@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=thor@math.tu-berlin.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox