Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp216061pxb; Mon, 13 Sep 2021 17:23:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxuQT/7dnSdXWkDFF46A21TS44Mf8144KI44N/drl0EpBSTTLHCxtmb/Ss03ob20vCaveaH X-Received: by 2002:a5e:c903:: with SMTP id z3mr11344040iol.61.1631579000683; Mon, 13 Sep 2021 17:23:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631579000; cv=none; d=google.com; s=arc-20160816; b=SHKhFPd+Zx4nAvXXFpGxYEVA/wMNAAC+ZHAJqqN5i0PZhsOE9yh4ObYmNyDUqV/yzL 1wZ1u+Pl6cS/ilKF8KK0xr7iJ6urk+8KvsGseNZinEMh4fLw0MX/+XcOYpTXUOB+cIex DuQfsetk1/6atNFpRL4ARpt3Gtlwc9I9wkt/Y4/VQFckw3s9BvJDh/xI2lfFHa6vF3hv YQ0QDsFQdZxIPYadfDTEX3YXVC9Ays0RtQSxMT7U9+cswlsLO4jRiXCbEiIZ6XNa6gaa b50fTyEOuXCBr8UaOiR6kIUW/4EWZ1+oip1eE0tE8owIVaNMKxABroBEqQp4scbs/WF1 q6eA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=4EB6qKyuHdZyWKQkZuNKuM5JMhNydtgkA7kvLomDd7M=; b=0B/+ODXwDD76AJxGDeg40cGmP7YRlDb4XnNh9GUX/HjS6j/OJzeimX2Jozjf9BwrvZ LHQ0BLIuR/2/E5ygPcuG9nrNR+gZnZnIlloSF+2/qDxKIONtkE92TKi1dGOVJpV5zi9s 0pMGz7r2Augasoz6cH+AN/Uqfb2TLeaY/TakD4iubuI+c0qzP4Pv4lpfM8/cDbLVgtel GjLjgp02ByZhxMCoifLAKmQGNxZIm/nJOAL6UXpd/Zti+GSowptZOzg5pevkPvFTMlV8 zW/L/YBwTGkXhMP/x/AHFxiIwHmrodfVw2QMOk5eqQFV9ABxR8hQqNeOaz4OIs7rSyL/ F+0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ym6wIGfD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a3si8004006ioc.79.2021.09.13.17.23.09; Mon, 13 Sep 2021 17:23:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=ym6wIGfD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344785AbhIMOJW (ORCPT + 99 others); Mon, 13 Sep 2021 10:09:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:54738 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344302AbhIMOEo (ORCPT ); Mon, 13 Sep 2021 10:04:44 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4D1F261A7A; Mon, 13 Sep 2021 13:39:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1631540355; bh=IadMZ0pUGcyaAMKR50sje3LsncERJJKFmuooJ5ChcpI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ym6wIGfDL8Jlv53F84M5/tOA12q5/2Rqzhte46660uFzVKnSkEJ1izeGw1rlXDqns 1Luuq6T6R8S/8FiSQyG8YQh/isCvO2yDXJT2Za2bxW56z5N1ebE6xyzRrZQqQlOPb7 zNRE+CVhJpO2erh1WwHmnZW2o1di/BcggzLtQYfw= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Marek Vasut , Daniel Abrecht , Emil Velikov , Laurent Pinchart , Lucas Stach , Stefan Agner , Jagan Teki , Sam Ravnborg , Sasha Levin Subject: [PATCH 5.13 128/300] drm: mxsfb: Enable recovery on underflow Date: Mon, 13 Sep 2021 15:13:09 +0200 Message-Id: <20210913131113.719397585@linuxfoundation.org> X-Mailer: git-send-email 2.33.0 In-Reply-To: <20210913131109.253835823@linuxfoundation.org> References: <20210913131109.253835823@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Marek Vasut [ Upstream commit 0c9856e4edcdcac22d65618e8ceff9eb41447880 ] There is some sort of corner case behavior of the controller, which could rarely be triggered at least on i.MX6SX connected to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS bridged 1920x1080 panel (and likely on other setups too), where the image on the panel shifts to the right and wraps around. This happens either when the controller is enabled on boot or even later during run time. The condition does not correct itself automatically, i.e. the display image remains shifted. It seems this problem is known and is due to sporadic underflows of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow IRQs, neither of the IRQs trigger and neither IRQ status bit is asserted when this condition occurs. All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW bit, which is described in the reference manual since i.MX23 as " Set this bit to enable the LCDIF block to recover in the next field/frame if there was an underflow in the current field/frame. " Enable this bit to mitigate the sporadic underflows. Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller") Signed-off-by: Marek Vasut Cc: Daniel Abrecht Cc: Emil Velikov Cc: Laurent Pinchart Cc: Lucas Stach Cc: Stefan Agner Reviewed-by: Lucas Stach Reviewed-by: Laurent Pinchart Reviewed-by: Jagan Teki Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210620224701.189289-1-marex@denx.de Signed-off-by: Sasha Levin --- drivers/gpu/drm/mxsfb/mxsfb_kms.c | 29 +++++++++++++++++++++++++++++ drivers/gpu/drm/mxsfb/mxsfb_regs.h | 1 + 2 files changed, 30 insertions(+) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 300e7bab0f43..01e0f525360f 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c @@ -115,6 +115,35 @@ static void mxsfb_enable_controller(struct mxsfb_drm_private *mxsfb) reg |= VDCTRL4_SYNC_SIGNALS_ON; writel(reg, mxsfb->base + LCDC_VDCTRL4); + /* + * Enable recovery on underflow. + * + * There is some sort of corner case behavior of the controller, + * which could rarely be triggered at least on i.MX6SX connected + * to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS + * bridged 1920x1080 panel (and likely on other setups too), where + * the image on the panel shifts to the right and wraps around. + * This happens either when the controller is enabled on boot or + * even later during run time. The condition does not correct + * itself automatically, i.e. the display image remains shifted. + * + * It seems this problem is known and is due to sporadic underflows + * of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow + * IRQs, neither of the IRQs trigger and neither IRQ status bit is + * asserted when this condition occurs. + * + * All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW + * bit, which is described in the reference manual since i.MX23 as + * " + * Set this bit to enable the LCDIF block to recover in the next + * field/frame if there was an underflow in the current field/frame. + * " + * Enable this bit to mitigate the sporadic underflows. + */ + reg = readl(mxsfb->base + LCDC_CTRL1); + reg |= CTRL1_RECOVER_ON_UNDERFLOW; + writel(reg, mxsfb->base + LCDC_CTRL1); + writel(CTRL_RUN, mxsfb->base + LCDC_CTRL + REG_SET); } diff --git a/drivers/gpu/drm/mxsfb/mxsfb_regs.h b/drivers/gpu/drm/mxsfb/mxsfb_regs.h index 55d28a27f912..df90e960f495 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_regs.h +++ b/drivers/gpu/drm/mxsfb/mxsfb_regs.h @@ -54,6 +54,7 @@ #define CTRL_DF24 BIT(1) #define CTRL_RUN BIT(0) +#define CTRL1_RECOVER_ON_UNDERFLOW BIT(24) #define CTRL1_FIFO_CLEAR BIT(21) #define CTRL1_SET_BYTE_PACKAGING(x) (((x) & 0xf) << 16) #define CTRL1_GET_BYTE_PACKAGING(x) (((x) >> 16) & 0xf) -- 2.30.2