Re: [PATCH 2/3] Revert "drm/i915: set TRANSCODER_EDP even earlier"

From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Cc: Takashi Iwai <tiwai@suse.de>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: Re: [PATCH 2/3] Revert "drm/i915: set TRANSCODER_EDP even earlier"
Date: Fri, 22 Mar 2013 14:43:03 +0100	[thread overview]
Message-ID: <CAKMK7uEanSxwuAwNPSO7iza6+zji+Lyfb2_e0yQHEqtn=kQLVQ@mail.gmail.com> (raw)
In-Reply-To: <1363946021-26651-2-git-send-email-daniel.vetter@ffwll.ch>

On Fri, Mar 22, 2013 at 10:53 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> This reverts commit cc464b2a17c59adedbdc02cc54341d630354edc3.
>
> The reason is that Takashi Iwai reported a regression bisected to this
> commit:
>
> http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
>
> His machine has eDP on port D (usual desktop all-in-on setup), which
> intel_dp.c identifies as an eDP panel, but the hsw ddi code
> mishandles.

Closer inspection of the code reveals that haswell_crtc_mode_set also
checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell
that doesn't make much sense (since there's no edp on the pch), but
what this function _really_ checks is whether that edp connector is on
port A or port D. It's just that on ilk-ivb port D was on the pch ...

So that explains why this seemingly innocent change killed eDP on port
D. Furthermore it looks like everything else accidentally works, since
we've never enabled eDP on port D support for hsw intentionally (e.g.
we still register the HDMI output for port D in that case).

I'll add that to the commit message when merging.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch