From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Barnes Subject: Re: [PATCH 1/4] drm/i915: rip out intel_disable_pch_ports Date: Thu, 13 Sep 2012 13:37:52 -0700 Message-ID: <20120913133752.35ab1d63@jbarnes-desktop> References: <1346962115-7267-1-git-send-email-daniel.vetter@ffwll.ch> <1346962115-7267-2-git-send-email-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by gabe.freedesktop.org (Postfix) with SMTP id 360709E732 for ; Thu, 13 Sep 2012 13:37:38 -0700 (PDT) In-Reply-To: <1346962115-7267-2-git-send-email-daniel.vetter@ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: Intel Graphics Development List-Id: intel-gfx@lists.freedesktop.org On Thu, 6 Sep 2012 22:08:32 +0200 Daniel Vetter wrote: > Even with the old crtc helper code we should have disabled all > encoders on that pipe by now, and with the new code this would > definitely paper over a bug. We already have the necessary checks > in place in intel_disable_transcoder, so if we accidentally leave > a pch port on, this will be caught. > > Hence just rip this all out. > > Note that up to the patch in this giant modeset series that removes > the LVDS special case to avoid disabling LVDS in the encoder->prepare > callback ("drm/i915/lvds: ditch ->prepare special case"), this was not > the case for all outputs. > > Also note that in > > commit 1b3c7a47f993bf9ab6c4c7cc3bbf5588052b58f4 > Author: Zhenyu Wang > Date: Wed Nov 25 13:09:38 2009 +0800 > > drm/i915: Fix LVDS stability issue on Ironlake > > this was already discovered independently and worked around. How I > bloody hate this entire mess of cludges piled on top of other cludges. Yes this was always an ugly layering violation too. I think I was worried about a mode set on one crtc getting stale config bits from another that hadn't been touched... Anyway now we've fixed it properly. Reviewed-by: Jesse Barnes -- Jesse Barnes, Intel Open Source Technology Center