From patchwork Thu Dec 19 16:29:43 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paulo Zanoni X-Patchwork-Id: 3383391 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 6BA9B9F314 for ; Thu, 19 Dec 2013 16:30:29 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id B9679206B4 for ; Thu, 19 Dec 2013 16:30:24 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 19523206A5 for ; Thu, 19 Dec 2013 16:30:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3212A10E4DF; Thu, 19 Dec 2013 08:30:18 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by gabe.freedesktop.org (Postfix) with ESMTP id 18AE3FB308 for ; Thu, 19 Dec 2013 08:30:05 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id w7so1106504qcr.25 for ; Thu, 19 Dec 2013 08:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=eQWKsgh+6B7SQu2/KrLL6AwQvYfnuLYU7VKJWPO5KjI=; b=wG7R/9ZjFBfzf9kSxE5n8sA0uxstSXqtKhojFlHZw90M7Z6h15igidJtuEaZcVboc/ tjr9P3zh/Oj+9/O28Me81kYt+fdur35UhaqKemwrNDcLajz74vk/spBvn5+wDDEN2po2 RPMNZkabuR9oyPWvLtzNwvqHjjf5tUorgrtTtBAFpVNwCa4HsK7eprZ2OWWlIFTkadiN V1eh2sptVC7NNL3p463pwy4g3tINktFcIToASN+yZir0x22z6AV5LXUAhuiWevAVgwBl RBXv28D6QA/pCWwkPlmxeQGH88dgj7Vh+K+mJTQJtUpiczz8dzJofYcg4x71TJl2Qo4u s2jw== X-Received: by 10.49.106.37 with SMTP id gr5mr4352392qeb.75.1387470605122; Thu, 19 Dec 2013 08:30:05 -0800 (PST) Received: from localhost.localdomain ([177.40.41.2]) by mx.google.com with ESMTPSA id gf3sm1215892qeb.17.2013.12.19.08.30.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Dec 2013 08:30:04 -0800 (PST) From: Paulo Zanoni To: intel-gfx@lists.freedesktop.org Date: Thu, 19 Dec 2013 14:29:43 -0200 Message-Id: <1387470584-1662-6-git-send-email-przanoni@gmail.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1387470584-1662-1-git-send-email-przanoni@gmail.com> References: <1387470584-1662-1-git-send-email-przanoni@gmail.com> Cc: Paulo Zanoni Subject: [Intel-gfx] [PATCH 5/6] drm/i915: don't wait for power cycle when waiting for power off 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@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Paulo Zanoni Function ironlake_wait_panel_off should just wait for the power off delay, while function ironlake_wait_panel_power_cycle should wait for the panel cycle (that's required after we turn the panel off, before we enable it again). The problem is that, currently, ironlake_wait_panel_off is waiting not just for the panel to be off, but also for the power cycle delay and the backlight off delay. This function relies on the PP_STATUS bits 3:0, which are not documented and not supposed to be used. A quick analysis of the values we get while waiting quickly shows that power off is reached while bits 3:0 are still 0x1, and the time it takes to become 0x0 is the power cycle delay. On my system with backlight off delay of 200ms, power down delay of 50ms and power cycle delay of 500ms, this is what I get: - Start waiting with value 0x80000008, timestamp 6.429364. - Jumps to 0xa0000003, timestamp 6.431360 (time waited: 0.001996) - Jumps to 0xa0000002, timestamp 6.631277 (time waited: 0.201913) - Jumps to 0x08000001, timestamp 6.681258 (time waited: 0.251894) - Jumps to 0x00000000, timestamp 7.192012 (time waited: 0.762648) As you can see, ironlake_wait_panel_off is sleeping 760ms instead of the expected 50ms: the first 200ms matches the backlight off delay (which we should already have waited for!), then the 50ms for the real panel off delay, then the 500ms for the panel power cycle. This patch makes is look just at bits 31 and 29:28, which will ignore the panel power cycle. And just to be clear: this saves 500ms on my system every time we disable the panel. But we can still save 200ms more (the backlight off delay) on the next patches. Signed-off-by: Paulo Zanoni Reviewed-by: Jesse Barnes --- drivers/gpu/drm/i915/intel_dp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index a6a4c4f..69d8f1c 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -1011,8 +1011,8 @@ static void intel_dp_mode_set(struct intel_encoder *encoder) #define IDLE_ON_MASK (PP_ON | PP_SEQUENCE_MASK | 0 | PP_SEQUENCE_STATE_MASK) #define IDLE_ON_VALUE (PP_ON | PP_SEQUENCE_NONE | 0 | PP_SEQUENCE_STATE_ON_IDLE) -#define IDLE_OFF_MASK (PP_ON | PP_SEQUENCE_MASK | 0 | PP_SEQUENCE_STATE_MASK) -#define IDLE_OFF_VALUE (0 | PP_SEQUENCE_NONE | 0 | PP_SEQUENCE_STATE_OFF_IDLE) +#define IDLE_OFF_MASK (PP_ON | PP_SEQUENCE_MASK | 0 | 0) +#define IDLE_OFF_VALUE (0 | PP_SEQUENCE_NONE | 0 | 0) #define IDLE_CYCLE_MASK (PP_ON | PP_SEQUENCE_MASK | PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK) #define IDLE_CYCLE_VALUE (0 | PP_SEQUENCE_NONE | 0 | PP_SEQUENCE_STATE_OFF_IDLE)