From patchwork Wed Jul 11 14:28:29 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 1183971 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork2.kernel.org (Postfix) with ESMTP id 9254ADF25A for ; Wed, 11 Jul 2012 16:12:05 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5D1F7A0EA5 for ; Wed, 11 Jul 2012 09:12:05 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) by gabe.freedesktop.org (Postfix) with ESMTP id 775FE9ED8F for ; Wed, 11 Jul 2012 08:36:11 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id r3so960506wey.36 for ; Wed, 11 Jul 2012 08:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references; bh=v7Ut51RhXQCAO7zDfutcOOrJBXHN85JmVBoaV3uWiKs=; b=QmyeztTq+C9xVILgNmXYK8929Jd+lSl6l2DJSoMr1h3H+tUfFRymiHsfhRm+nkJiOZ SmGZaQONW1zbXFGkCNEBF1181tSxnaKbEOdxCthnBrYFY1sCxtVG3eyD8KL4wtU6UoFm j2bdSWTjIdb6eDUzubVxIp8RxRtzIwh3gub7Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references :x-gm-message-state; bh=v7Ut51RhXQCAO7zDfutcOOrJBXHN85JmVBoaV3uWiKs=; b=UUzQndOBltsgHzp4jDu5lbyWAFruXA7P7srYnbyGOe48AgKJav97iTtVYKGVlJ4rGT DopVnZCSmxdDkjW5WmBvRJTBb8i5WL9R6J4libJC+Z6XuW7r/Q+K9jSoaI72/dqSbeXy zf/Y0gwLsHAG3aL0hzyCcL8I7nAKZbcATmu2qhjdyX1runOGwYNPaE2B/Vw/rP4NjcvB GXZHjoC7fo46kH+JB+5uuOZvb41p3djpAYq6kJj+2HmmHprL+muByAqcsZ8duk+Vn+yG RHdfx5FS7FWfU0NZ9tH/vGoufYSbsqGOh3a7Pv2WWSZUtSX+qGr7QUzVc2IQcnQaVil4 HG4Q== Received: by 10.216.236.38 with SMTP id v38mr10157638weq.222.1342020971133; Wed, 11 Jul 2012 08:36:11 -0700 (PDT) Received: from wespe.ffwll.local (178-83-130-250.dynamic.hispeed.ch. [178.83.130.250]) by mx.google.com with ESMTPS id bc2sm5777080wib.0.2012.07.11.08.36.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Jul 2012 08:36:10 -0700 (PDT) From: Daniel Vetter To: Intel Graphics Development Date: Wed, 11 Jul 2012 16:28:29 +0200 Message-Id: <1342016944-23395-47-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.7.7.6 In-Reply-To: <1342016944-23395-1-git-send-email-daniel.vetter@ffwll.ch> References: <1342016944-23395-1-git-send-email-daniel.vetter@ffwll.ch> X-Gm-Message-State: ALoCoQlqo+N0rSHzeX6FM5X41pLeGFQEsib6LUT97fCbrEra+Hfg78DXN5jO5zPX9KTyXXjsldTb Cc: Daniel Vetter Subject: [Intel-gfx] [PATCH 46/81] drm/i915: ensure the force pipe A quirk is actually followed X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+patchwork-intel-gfx=patchwork.kernel.org@lists.freedesktop.org Many BIOSen forget to turn on the pipe A after resume (because they actually don't turn on anything), so we have to do that ourselves when sanitizing the hw state. I've discovered this due to the recent addition of a pipe WARN that takes the force quirk into account. v2: Actually try to enable the pipe with a proper configuration instead of simpyl switching it on with whatever random state the bios left it in after resume. Signed-Off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_display.c | 38 ++++++++++++++++++++++++++++++++++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 649d327..08d3684 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7630,6 +7630,35 @@ intel_connector_break_all_links(struct intel_connector *connector) connector->encoder->base.crtc = NULL; } +static void intel_enable_pipe_a(struct drm_device *dev) +{ + struct intel_connector *connector; + struct drm_connector *crt = NULL; + struct intel_load_detect_pipe load_detect_temp; + + /* We can't just switch on the pipe A, we need to set things up with a + * proper mode and output configuration. As a gross hack, enable pipe A + * by enabling the load detect pipe once. */ + list_for_each_entry(connector, + &dev->mode_config.connector_list, + base.head) { + if (connector->encoder->type == INTEL_OUTPUT_ANALOG) { + crt = &connector->base; + break; + } + } + + if (!crt) + return; + + if (intel_get_load_detect_pipe(intel_attached_encoder(crt), + crt, NULL, &load_detect_temp)) + intel_release_load_detect_pipe(intel_attached_encoder(crt), + crt, &load_detect_temp); + + +} + static void intel_sanitize_crtc(struct intel_crtc *crtc) { struct drm_device *dev = crtc->base.dev; @@ -7676,6 +7705,15 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc) } ok: + if (dev_priv->quirks & QUIRK_PIPEA_FORCE && + crtc->pipe == PIPE_A && !crtc->active) { + /* BIOS forgot to enable pipe A, this mostly happens after + * resume. Force-enable the pipe to fix this, the update_dpms + * call below we restore the pipe to the right state, but leave + * the required bits on. */ + intel_enable_pipe_a(dev); + } + /* Adjust the state of the output pipe according to whether we * have active connectors/encoders. */ intel_crtc_update_dpms(&crtc->base);