From patchwork Wed Oct 26 08:55:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Starkey X-Patchwork-Id: 37787 Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bzK2K-0007mx-A3; Wed, 26 Oct 2016 08:58:16 +0000 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.84_2/mailfrontend-8) with esmtp id 1bzK2I-0006TM-kH; Wed, 26 Oct 2016 10:58:16 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754099AbcJZI4I (ORCPT + 1 other); Wed, 26 Oct 2016 04:56:08 -0400 Received: from foss.arm.com ([217.140.101.70]:34216 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752976AbcJZI4G (ORCPT ); Wed, 26 Oct 2016 04:56:06 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 783D71478; Wed, 26 Oct 2016 01:55:31 -0700 (PDT) Received: from e106950-lin.cambridge.arm.com (e106950-lin.cambridge.arm.com [10.2.133.193]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAC9F3F220; Wed, 26 Oct 2016 01:55:30 -0700 (PDT) From: Brian Starkey To: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org Subject: [RFC PATCH v2 2/9] drm: mali-dp: Clear CVAL when leaving config mode Date: Wed, 26 Oct 2016 09:55:01 +0100 Message-Id: <1477472108-27222-3-git-send-email-brian.starkey@arm.com> X-Mailer: git-send-email 1.7.9.5 In-Reply-To: <1477472108-27222-1-git-send-email-brian.starkey@arm.com> References: <1477472108-27222-1-git-send-email-brian.starkey@arm.com> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.10.26.85116 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1600_1699 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, IN_REP_TO 0, LEGITIMATE_NEGATE 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_URI_HTTPS 0, REFERENCES 0, SINGLE_URI_IN_BODY 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MULTIPLE_RCPTS_CC_X2 0, __REFERENCES 0, __SANE_MSGID 0, __SINGLE_URI_TEXT 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0' It's possible for CVAL to get set whilst we are in config mode. If this happens, afer we leave config mode the HW will latch whatever configuration is in the registers at the next vsync. Most likely this will be a partial configuration, as we'll be racing against the ongoing atomic_commit. To avoid this, clear CVAL before leaving config mode. Signed-off-by: Brian Starkey --- drivers/gpu/drm/arm/malidp_hw.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index 7f4a0bd..65e667b 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -125,6 +125,7 @@ static void malidp500_leave_config_mode(struct malidp_hw_device *hwdev) { u32 status, count = 100; + malidp_hw_clearbits(hwdev, MALIDP_CFG_VALID, MALIDP500_CONFIG_VALID); malidp_hw_clearbits(hwdev, MALIDP500_DC_CONFIG_REQ, MALIDP500_DC_CONTROL); while (count) { status = malidp_hw_read(hwdev, hwdev->map.dc_base + MALIDP_REG_STATUS); @@ -271,6 +272,7 @@ static void malidp550_leave_config_mode(struct malidp_hw_device *hwdev) { u32 status, count = 100; + malidp_hw_clearbits(hwdev, MALIDP_CFG_VALID, MALIDP550_CONFIG_VALID); malidp_hw_clearbits(hwdev, MALIDP550_DC_CONFIG_REQ, MALIDP550_DC_CONTROL); while (count) { status = malidp_hw_read(hwdev, hwdev->map.dc_base + MALIDP_REG_STATUS);