From patchwork Thu Jul 26 18:49:07 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 1245101 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork1.kernel.org (Postfix) with ESMTP id C384F3FC33 for ; Thu, 26 Jul 2012 20:33:42 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 81FD39E9FE for ; Thu, 26 Jul 2012 13:33:42 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id AB9C69ED88 for ; Thu, 26 Jul 2012 12:57:05 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id dr1so1724686wgb.12 for ; Thu, 26 Jul 2012 12:57:05 -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=H4TxjGZXMrCyDj35pyVo/Upsm/apzT6LF0/g4w4Nccg=; b=bA4ZinIOneolKfjSNbHO2LOCZkm8sAnNJDtP5P2KrxxN7m8B6mw1sqkjU8vdYxT2UU H2pPyLvruxzvP3k/QnlASLzX7r1CGvsu+Qn60rcUc1ppoDS6dcrcMHbh/Ki3w4ZQawIJ FwTBG6woRrYLcGuiezODptrNDrOhOTwaoz6UA= 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=H4TxjGZXMrCyDj35pyVo/Upsm/apzT6LF0/g4w4Nccg=; b=XXk0gE6OebxZL35bRrTiBYoiutbSIofophD5tVMwJCVmHslneRtfac9rkv97oIl1wc NQNaEz9SnQh7qBRF4c806G8xQDnDWEyJXpyB7247tDOLZxANr7hlnstT88ePmsDPVZoE I2IJPhC4gi+bhDleZKbOjy7Ws373KnVLLWyn8pt8mZkMre0st5IfwTl0FrlVRGw3goZv Fz+uKPPgjZTaUHKQ5vJeSTBW3ShOfUuEX0f1NxjzknsrZ/q9dY0qsnMlW9QSa42A8T/9 yf1Rgn9xqKzw2sAaN5SimPpoWDaCQ5d6A0k+BSa58Szq+AWC/+Cqx7R73sVa8f5kg4Qp xqEQ== Received: by 10.216.243.10 with SMTP id j10mr6468320wer.211.1343332625426; Thu, 26 Jul 2012 12:57:05 -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 fr4sm391403wib.8.2012.07.26.12.57.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 Jul 2012 12:57:04 -0700 (PDT) From: Daniel Vetter To: Intel Graphics Development Date: Thu, 26 Jul 2012 20:49:07 +0200 Message-Id: <1343328581-2324-43-git-send-email-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 1.7.10.4 In-Reply-To: <1343328581-2324-1-git-send-email-daniel.vetter@ffwll.ch> References: <1343328581-2324-1-git-send-email-daniel.vetter@ffwll.ch> X-Gm-Message-State: ALoCoQlL8yVyC+d/04uUfPAqtN4hDIhew229L2UOskRdfN0UWYD2caM1GyruU7+d7Honakg1R3G9 Cc: Daniel Vetter Subject: [Intel-gfx] [PATCH 42/76] 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 file changed, 38 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 4375e6d..9f3a153 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -7546,6 +7546,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; @@ -7592,6 +7621,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);