Received: by 10.223.185.116 with SMTP id b49csp2876859wrg; Mon, 5 Mar 2018 10:05:21 -0800 (PST) X-Google-Smtp-Source: AG47ELvagTQo6CuaRsJmzM7/kFTzBF8XKcHErrWnKMtin2kO7KaBfAT59ZG+wL2b0f8o03b5iPCG X-Received: by 10.99.114.80 with SMTP id c16mr12851205pgn.436.1520273121092; Mon, 05 Mar 2018 10:05:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520273121; cv=none; d=google.com; s=arc-20160816; b=TDYWq3hA7snVZlTNfrR73CAINMz1jgSrkgCBmalyFOQMjbC1COYJHMQDGWX9REiTDC g9Mo7v/iWITsdd0mY5J7uDU1WLl1vqnX0M5nknxir0xWR0ZuOW7p3UVGxz8Su2PW0RFe 56Nj/BWGDTLp34BpG3bN06BgKHYDw+NUpl9m7f8Kvy3gy+Dcn6PJXbz8kVXyl29RuHm0 6gvc894QlL5NrYFlYXfBHw9FSz+NY9hRofsioQY/S3mx8439NM+U8WVUn8/4sgwbuNDr TVKN5442ehG68B4gCR+nGKc4YlMDMYz9WKAmon1oeppyEZ/+pYXgiwBfa+046+90QCT/ gZYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=hPlhtLXG8JecEROfxWEqPMMqnbmbxA6LtWfMNzRCJoc=; b=vDFuYWCykxxMKbiYBzjdeFTycajsvM4wqACMbQ2Pfy28EC74LMSQVZ+fsD3hLgTCIo KIXTi8YWL4VSEs/JqepZyReaA873K2SQ7beYV8WHYHVxdbeIlMa1iA1a1P7l67shktcX 6dg1G0jNWT1/kVO/47Z6Aa5hO1lU6yEU8it3W/zxNhVwRs7HxcUs8EpyrhdjIz2Sayt/ XUkHMrLb02P5QT4v2mjYA+V4Zpcf9D1XlhDH6aIGFNyc5vzXoROPf0OaHDrxB24jbeqw mbyhXDAyghBlLvm1cr82RFh7GeZ630uQp+XWWNQ/mjOLLUbYrKjV9ACbRG/gr6ei7H7K SzBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g15si10410757pfi.330.2018.03.05.10.05.07; Mon, 05 Mar 2018 10:05:21 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752823AbeCESDX (ORCPT + 99 others); Mon, 5 Mar 2018 13:03:23 -0500 Received: from fw-tnat.cambridge.arm.com ([217.140.96.140]:58726 "EHLO cam-smtp0.cambridge.arm.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751935AbeCESDV (ORCPT ); Mon, 5 Mar 2018 13:03:21 -0500 Received: from e110455-lin.cambridge.arm.com (e110455-lin.cambridge.arm.com [10.2.131.15]) by cam-smtp0.cambridge.arm.com (8.13.8/8.13.8) with ESMTP id w25I3Gh4023406; Mon, 5 Mar 2018 18:03:16 GMT From: Liviu Dudau To: Brian Starkey Cc: Mali DP Maintainers , Alexandru-Cosmin Gheorghe , DRI devel , LKML , Liviu Dudau Subject: [PATCH v3] drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending. Date: Mon, 5 Mar 2018 18:03:16 +0000 Message-Id: <20180305180316.12654-1-Liviu.Dudau@arm.com> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180301174913.10875-1-Liviu.Dudau@arm.com> References: <20180301174913.10875-1-Liviu.Dudau@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mali DP hardware has a 'go' bit (config_valid) for making the new scene parameters active at the next page flip. The problem with the current code is that the driver first sets this bit and then proceeds to wait for confirmation from the hardware that the configuration has been updated before arming the vblank event. As config_valid is actually asserted by the hardware after the vblank event, during the prefetch phase, when we get to arming the vblank event we are going to send it at the next vblank, in effect halving the vblank rate from the userspace perspective. Fix it by sending the userspace event from the IRQ handler, when we handle the config_valid interrupt, which syncs with the time when the hardware is active with the new parameters. v2: Brian reminded me that interrupts won't fire when CRTC is off, so we need to do the sending ourselves. v3: crtc->enabled is the wrong flag to use here, as when we get an atomic commit that turns off the CRTC it will still be enabled until after the commit is done. Use the crtc->state->active for test. Reported-by: Alexandru-Cosmin Gheorghe Signed-off-by: Liviu Dudau --- drivers/gpu/drm/arm/malidp_drv.c | 32 +++++++++++++++++--------------- drivers/gpu/drm/arm/malidp_drv.h | 1 + drivers/gpu/drm/arm/malidp_hw.c | 12 +++++++++--- 3 files changed, 27 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c index d88a3b9d59cc..3c628e43bf25 100644 --- a/drivers/gpu/drm/arm/malidp_drv.c +++ b/drivers/gpu/drm/arm/malidp_drv.c @@ -185,25 +185,29 @@ static int malidp_set_and_wait_config_valid(struct drm_device *drm) static void malidp_atomic_commit_hw_done(struct drm_atomic_state *state) { - struct drm_pending_vblank_event *event; struct drm_device *drm = state->dev; struct malidp_drm *malidp = drm->dev_private; - if (malidp->crtc.enabled) { - /* only set config_valid if the CRTC is enabled */ - if (malidp_set_and_wait_config_valid(drm)) - DRM_DEBUG_DRIVER("timed out waiting for updated configuration\n"); - } + malidp->event = malidp->crtc.state->event; + malidp->crtc.state->event = NULL; - event = malidp->crtc.state->event; - if (event) { - malidp->crtc.state->event = NULL; + if (malidp->crtc.state->active) { + /* + * if we have an event to deliver to userspace, make sure + * the vblank is enabled as we are sending it from the IRQ + * handler. + */ + if (malidp->event) + drm_crtc_vblank_get(&malidp->crtc); + /* only set config_valid if the CRTC is enabled */ + if (malidp_set_and_wait_config_valid(drm) < 0) + DRM_DEBUG_DRIVER("timed out waiting for updated configuration\n"); + } else if (malidp->event) { + /* CRTC inactive means vblank IRQ is disabled, send event directly */ spin_lock_irq(&drm->event_lock); - if (drm_crtc_vblank_get(&malidp->crtc) == 0) - drm_crtc_arm_vblank_event(&malidp->crtc, event); - else - drm_crtc_send_vblank_event(&malidp->crtc, event); + drm_crtc_send_vblank_event(&malidp->crtc, malidp->event); + malidp->event = NULL; spin_unlock_irq(&drm->event_lock); } drm_atomic_helper_commit_hw_done(state); @@ -232,8 +236,6 @@ static void malidp_atomic_commit_tail(struct drm_atomic_state *state) malidp_atomic_commit_hw_done(state); - drm_atomic_helper_wait_for_vblanks(drm, state); - pm_runtime_put(drm->dev); drm_atomic_helper_cleanup_planes(drm, state); diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h index e0d12c9fc6b8..c2375bb49619 100644 --- a/drivers/gpu/drm/arm/malidp_drv.h +++ b/drivers/gpu/drm/arm/malidp_drv.h @@ -22,6 +22,7 @@ struct malidp_drm { struct malidp_hw_device *dev; struct drm_crtc crtc; wait_queue_head_t wq; + struct drm_pending_vblank_event *event; atomic_t config_valid; u32 core_id; }; diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c index 2bfb542135ac..8abd335ec313 100644 --- a/drivers/gpu/drm/arm/malidp_hw.c +++ b/drivers/gpu/drm/arm/malidp_hw.c @@ -782,9 +782,15 @@ static irqreturn_t malidp_de_irq(int irq, void *arg) /* first handle the config valid IRQ */ dc_status = malidp_hw_read(hwdev, hw->map.dc_base + MALIDP_REG_STATUS); if (dc_status & hw->map.dc_irq_map.vsync_irq) { - /* we have a page flip event */ - atomic_set(&malidp->config_valid, 1); malidp_hw_clear_irq(hwdev, MALIDP_DC_BLOCK, dc_status); + /* do we have a page flip event? */ + if (malidp->event != NULL) { + spin_lock(&drm->event_lock); + drm_crtc_send_vblank_event(&malidp->crtc, malidp->event); + malidp->event = NULL; + spin_unlock(&drm->event_lock); + } + atomic_set(&malidp->config_valid, 1); ret = IRQ_WAKE_THREAD; } @@ -794,7 +800,7 @@ static irqreturn_t malidp_de_irq(int irq, void *arg) mask = malidp_hw_read(hwdev, MALIDP_REG_MASKIRQ); status &= mask; - if (status & de->vsync_irq) + if ((status & de->vsync_irq) && malidp->crtc.enabled) drm_crtc_handle_vblank(&malidp->crtc); malidp_hw_clear_irq(hwdev, MALIDP_DE_BLOCK, status); -- 2.16.2