From patchwork Sun Dec 9 20:44:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laurent Pinchart X-Patchwork-Id: 10720369 X-Patchwork-Delegate: kieran@bingham.xyz Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 343BC1731 for ; Sun, 9 Dec 2018 20:43:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1A29F2A0FD for ; Sun, 9 Dec 2018 20:43:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 09B082A109; Sun, 9 Dec 2018 20:43:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 845A92A0FD for ; Sun, 9 Dec 2018 20:43:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726237AbeLIUny (ORCPT ); Sun, 9 Dec 2018 15:43:54 -0500 Received: from perceval.ideasonboard.com ([213.167.242.64]:52432 "EHLO perceval.ideasonboard.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726219AbeLIUny (ORCPT ); Sun, 9 Dec 2018 15:43:54 -0500 Received: from avalon.bb.dnainternet.fi (dfj612ybrt5fhg77mgycy-3.rev.dnainternet.fi [IPv6:2001:14ba:21f5:5b00:2e86:4862:ef6a:2804]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id 7301C508; Sun, 9 Dec 2018 21:43:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1544388232; bh=FEIp8CU5W45AgG48tHlnnDgdrBuJEEZmCdDfdRncVV4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nBhz80ZnngLL/XqTYGdtZ938Zd6lBy/QB21bxaABSHdpVpIx3bjJuxIAicJ/yIFIk SJWRczX9AYrbyPbJMxapaf7VSY6lYyUL1RVxGKrtS10c3BS/ePqKjZ/5UTuazN8ydu eM1NDR8xHsSt9dvv6f0jeGMSVBlIndpBJfvXNu2w= From: Laurent Pinchart To: dri-devel@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org, kieran.bingham@ideasonboard.com Subject: [PATCH v1.1 3/5] drm: rcar-du: Disable unused DPAD outputs Date: Sun, 9 Dec 2018 22:44:28 +0200 Message-Id: <20181209204428.13392-1-laurent.pinchart+renesas@ideasonboard.com> X-Mailer: git-send-email 2.19.2 In-Reply-To: <20181125144031.4407-4-laurent.pinchart+renesas@ideasonboard.com> References: <20181125144031.4407-4-laurent.pinchart+renesas@ideasonboard.com> MIME-Version: 1.0 Sender: linux-renesas-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP DU channels are routed to DPAD outputs in an SoC-dependent way. The routing can be fixed (e.g. DU3 to DPAD0 on H3) or configurable (e.g. DU0 or DU1 to DPAD0 on D3/E3). The hardware offers no option to disconnect DPAD outputs, which are thus always driven by a DU channel. On SoCs that have less DU channels than DU outputs, such as D3 and E3, the DPAD output is always driven when all channels are in use by other outputs (such as the internal LVDS and HDMI encoders). This creates an unwanted clone on the DPAD output. However, the parallel output of the DU channels routed to DPAD can be set to fixed levels in the DU channels themselves through the DOFLR group register. Use this to turn the DPAD on or off by driving fixed signals at the output of any DU channel not routed to a DPAD output. This doesn't affect the DU output signals going to other outputs. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- Changes since v1: - Renamed rcar_du_group_set_output_levels() to rcar_du_group_set_dpad_levels() - Clarify that fixed DPAD outputs are low-level --- drivers/gpu/drm/rcar-du/rcar_du_group.c | 43 +++++++++++++++++++++++++ 1 file changed, 43 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c b/drivers/gpu/drm/rcar-du/rcar_du_group.c index 7e440f61977f..9eee47969e77 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_group.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c @@ -287,6 +287,47 @@ int rcar_du_set_dpad0_vsp1_routing(struct rcar_du_device *rcdu) return 0; } +static void rcar_du_group_set_dpad_levels(struct rcar_du_group *rgrp) +{ + static const u32 doflr_values[2] = { + DOFLR_HSYCFL0 | DOFLR_VSYCFL0 | DOFLR_ODDFL0 | + DOFLR_DISPFL0 | DOFLR_CDEFL0 | DOFLR_RGBFL0, + DOFLR_HSYCFL1 | DOFLR_VSYCFL1 | DOFLR_ODDFL1 | + DOFLR_DISPFL1 | DOFLR_CDEFL1 | DOFLR_RGBFL1, + }; + static const u32 dpad_mask = BIT(RCAR_DU_OUTPUT_DPAD1) + | BIT(RCAR_DU_OUTPUT_DPAD0); + struct rcar_du_device *rcdu = rgrp->dev; + u32 doflr = DOFLR_CODE; + unsigned int i; + + if (rcdu->info->gen < 2) + return; + + /* + * The DPAD outputs can't be controlled directly. However, the parallel + * output of the DU channels routed to DPAD can be set to fixed levels + * through the DOFLR group register. Use this to turn the DPAD on or off + * by driving fixed low-level signals at the output of any DU channel + * not routed to a DPAD output. This doesn't affect the DU output + * signals going to other outputs, such as the internal LVDS and HDMI + * encoders. + */ + + for (i = 0; i < rgrp->num_crtcs; ++i) { + struct rcar_du_crtc_state *rstate; + struct rcar_du_crtc *rcrtc; + + rcrtc = &rcdu->crtcs[rgrp->index * 2 + i]; + rstate = to_rcar_crtc_state(rcrtc->crtc.state); + + if (!(rstate->outputs & dpad_mask)) + doflr |= doflr_values[i]; + } + + rcar_du_group_write(rgrp, DOFLR, doflr); +} + int rcar_du_group_set_routing(struct rcar_du_group *rgrp) { struct rcar_du_device *rcdu = rgrp->dev; @@ -306,5 +347,7 @@ int rcar_du_group_set_routing(struct rcar_du_group *rgrp) rcar_du_group_write(rgrp, DORCR, dorcr); + rcar_du_group_set_dpad_levels(rgrp); + return rcar_du_set_dpad0_vsp1_routing(rgrp->dev); }