Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2360891yba; Fri, 19 Apr 2019 18:13:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqxqskIakl8eBxkulLh6A/aZ1DrczRrSPs1xmXu7MU5spjRh/Q2rgipITKVIgdY1u+TBdiZm X-Received: by 2002:aa7:8e04:: with SMTP id c4mr7119379pfr.48.1555722832913; Fri, 19 Apr 2019 18:13:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1555722832; cv=none; d=google.com; s=arc-20160816; b=jlrZDomzeSxLmAcsni8iJxdxhHUqo7O6wXOEQ9vfIAUF9gaYMDO1Z3/uiKbTnvITSM vQ7jGLl1W0V4HA0wcZSOfvwNAp4pbDG3NfW+GVWCbnxkmKsiS7b8ZueOVN5Mcm7UWYfA mGbF0873yNB/c0oK40M2R0t8hzCKH9tfG4c0T0wrJ2XzdkIx23fT+2R2620s+IT+ZgO5 VXcuVygcG4wBq8s7CAuYAvOEM2NLEMpp9O3kGwrOAhoBQSu+jqyIEWFKN5VDUeNhvIQ0 QYYPQFMADDIifgjMGVieiLZDI1cJJCb/F4BwW4Ot7epplODIihFbsxe2xHzfuiO/eXRj qTVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=83bAsqNuIsXJNaB8sY2UvWhS2HP14+UCPogYzDLG2jo=; b=CteIG4FZLmFLx3KqrcLu9YAV1bL+C/3gzp14y2h4cgq1EAopNgZpQdy2R8IeZjPHbl sfxJcdqsBGUGM3kqYJgY04Nm0s8N2GKFpbG6ls+DVFmlBkTJ0vk8Q3SKT/WEwX4iDLeW nC8ZWiRy0SVH63Xolv07FmaVTEbyOzy+jBXM78G+el5U0KgL4XsX9hNQfdHmNMShdHxI rydgVSmh1CTmwf6Ye2E+3MPvCNrOQh+YdzZ0ohiYc10ptRr6xlVt1uEBtUbx1z1lltxF CFSkCRUH0dm+m0pibJzvfzzKNJZ+Fz2UpkOiyi3ZdgABgjG1WNl0p+H1Co+fZbPCGcxn exEQ== 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 p8si6477784plk.392.2019.04.19.18.13.37; Fri, 19 Apr 2019 18:13:52 -0700 (PDT) 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 S1727385AbfDTBKo (ORCPT + 99 others); Fri, 19 Apr 2019 21:10:44 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:33840 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725858AbfDTBKn (ORCPT ); Fri, 19 Apr 2019 21:10:43 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 95CADB52F90959D4F936; Sat, 20 Apr 2019 09:10:39 +0800 (CST) Received: from [127.0.0.1] (10.57.77.74) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.408.0; Sat, 20 Apr 2019 09:10:29 +0800 Subject: Re: [PATCH] drm: kirin: Fix for hikey620 display offset problem To: John Stultz , lkml References: <1555696800-15961-1-git-send-email-john.stultz@linaro.org> CC: Da Lv , Rongrong Zou , "Xinwei Kong" , Chen Feng , David Airlie , Daniel Vetter , dri-devel , Yidong Lin From: xinliang Message-ID: <5CBA7185.8000900@hisilicon.com> Date: Sat, 20 Apr 2019 09:10:29 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1555696800-15961-1-git-send-email-john.stultz@linaro.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.57.77.74] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019/4/20 2:00, John Stultz wrote: > From: Da Lv > > The original HiKey (620) board has had a long running issue > where when using a 1080p montior, the display would occasionally > blink and come come back with a horizontal offset (usually also > shifting the colors, depending on the value of the offset%4). > > After lots of analysis by HiSi developers, they found the issue > was due to when running at 1080p, it was possible to hit the > device memory bandwidth limits, which could cause the DSI signal > to get out of sync. > > Unfortunately the DSI logic doesn't have the ability to > automatically recover from this situation, but we can get a an > LDI underflow interrupt when it happens. > > To then correct the issue, when we get an LDI underflow irq, we > we can simply suspend and resume the display, which resets the > hardware. > > Thus, this patch enables the ldi underflow interrupt, and > initializes a workqueue that is used to suspend/resume the > display to recover. Then when the irq occurs we clear it and > schedule the workqueue to reset display engine. > > Cc: Xinliang Liu > Cc: Rongrong Zou > Cc: Xinwei Kong > Cc: Chen Feng > Cc: David Airlie > Cc: Daniel Vetter > Cc: dri-devel > Signed-off-by: Da Lv > Signed-off-by: Yidong Lin > [jstultz: Reworded the commit message, checkpatch cleanups] > Signed-off-by: John Stultz Thanks for the patch John, Reviewed-by: Xinliang Liu Xinliang > Change-Id: I792ce0b50a1c941d94d8cbec6b52c0f838d967bd > --- > drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 6 ++++++ > drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 23 +++++++++++++++++++++++ > 2 files changed, 29 insertions(+) > > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h > index 4cf281b7..ced40c6 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h > @@ -87,6 +87,7 @@ > #define VSIZE_OFST 20 > #define LDI_INT_EN 0x741C > #define FRAME_END_INT_EN_OFST 1 > +#define UNDERFLOW_INT_EN_OFST 2 > #define LDI_CTRL 0x7420 > #define BPP_OFST 3 > #define DATA_GATE_EN BIT(2) > @@ -97,6 +98,11 @@ > #define LDI_HDMI_DSI_GT 0x7434 > > /* > + *BIT_LDI_UNFLOW > + */ > +#define BIT_LDI_UNFLOW BIT(2) > + > +/* > * ADE media bus service regs > */ > #define ADE0_QOSGENERATOR_MODE 0x010C > diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > index 73611a9..1d935ab 100644 > --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c > @@ -58,6 +58,7 @@ struct ade_hw_ctx { > struct ade_crtc { > struct drm_crtc base; > struct ade_hw_ctx *ctx; > + struct work_struct drm_device_wq; > bool enable; > u32 out_format; > }; > @@ -176,6 +177,7 @@ static void ade_init(struct ade_hw_ctx *ctx) > */ > ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST, > FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND); > + ade_update_bits(base + LDI_INT_EN, UNDERFLOW_INT_EN_OFST, MASK(1), 1); > } > > static bool ade_crtc_mode_fixup(struct drm_crtc *crtc, > @@ -345,6 +347,18 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc) > MASK(1), 0); > } > > +static void drm_underflow_wq(struct work_struct *work) > +{ > + struct ade_crtc *acrtc = container_of(work, struct ade_crtc, > + drm_device_wq); > + struct drm_device *drm_dev = (&acrtc->base)->dev; > + void __iomem *base = acrtc->ctx->base; > + struct drm_atomic_state *state; > + > + state = drm_atomic_helper_suspend(drm_dev); > + drm_atomic_helper_resume(drm_dev, state); > +} > + > static irqreturn_t ade_irq_handler(int irq, void *data) > { > struct ade_crtc *acrtc = data; > @@ -362,6 +376,12 @@ static irqreturn_t ade_irq_handler(int irq, void *data) > MASK(1), 1); > drm_crtc_handle_vblank(crtc); > } > + if (status & BIT_LDI_UNFLOW) { > + ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST, > + MASK(1), 1); > + DRM_ERROR("LDI underflow!"); > + schedule_work(&acrtc->drm_device_wq); > + } > > return IRQ_HANDLED; > } > @@ -1038,6 +1058,9 @@ static int ade_drm_init(struct platform_device *pdev) > /* vblank irq init */ > ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler, > IRQF_SHARED, dev->driver->name, acrtc); > + > + INIT_WORK(&acrtc->drm_device_wq, drm_underflow_wq); > + > if (ret) > return ret; >