Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp935569ybl; Fri, 6 Dec 2019 08:34:12 -0800 (PST) X-Google-Smtp-Source: APXvYqxuJH3K7LrKR8VsgCwnIi6zHt+vT6eNln0sZXzIcudUx4N/YGyPhlD9QsYzui8kiVcQiXLI X-Received: by 2002:aca:a949:: with SMTP id s70mr13471002oie.80.1575650051913; Fri, 06 Dec 2019 08:34:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575650051; cv=none; d=google.com; s=arc-20160816; b=btpvY33gyoZo4dhloliyGh9S/OcIk4tpT2yBwcwdz1QgC/SS3r+23fDJ5KiCgmZiRp fA0VrdcfTw8T3ZnVOmavh8BmH/FMxqt/uSEWCQ7qZyO5IUz88rIOVGozWNRtvr5OyQnR rKIXlBMrI6jENVGpuagCuJz8/TtYi287yAND+22KLwhqysdNQwPnAGH/TkZR8Pl/69Hp IOKqielFgz5Yyq34quxyhSoIrB/oWagIM86rTtO0sWV07LC/214RaIpJ+0wVvk2C7WO1 Dj4cm/YEuMIb3MhrpjuuO1klJ7Of9sm9vMAP9d3GQjyF3ftIlcQ11Fk21pkzkOo7GDiD vXaA== 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; bh=3s48lfWR78HyurmcnieOL7Nl/J9qYvb1iAXXIrMkpMs=; b=UqTGDAfYmdHTuUAxkQ7xlcLpHzeqpHBFLaL/ruC5yTAJguATgk0HiZhv8NyOTb4n9b QXwhrQwPA+Ucwj0aAiUuwbyKwz5Y3VtzW3k+0cjSoRO1IAX4PIkwzP1LAKehk2ZWgncz ssDFdccjDaHd8tS3lKLkphk29+VDL09siuJmTkAPO7i//4LcVB3e/w3oAh7lgAGTwbDY pQjYcek/S+TVc8khfm/Qma0gabVLBFEnhoCgaT81QqOAEmP3iGDJRWkzPb20flw3Pjk0 FooGRzqqsVlb/9SEitAEam5Gn9D9epPHRLgqve2XGqXOgedxgFMuKv4zSRsQU3DeFqTA h6HA== 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 r65si7054732oig.69.2019.12.06.08.33.59; Fri, 06 Dec 2019 08:34:11 -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 S1726534AbfLFQdV (ORCPT + 99 others); Fri, 6 Dec 2019 11:33:21 -0500 Received: from relmlor1.renesas.com ([210.160.252.171]:55948 "EHLO relmlie5.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726258AbfLFQdV (ORCPT ); Fri, 6 Dec 2019 11:33:21 -0500 X-IronPort-AV: E=Sophos;i="5.69,285,1571670000"; d="scan'208";a="33693117" Received: from unknown (HELO relmlir5.idc.renesas.com) ([10.200.68.151]) by relmlie5.idc.renesas.com with ESMTP; 07 Dec 2019 01:33:20 +0900 Received: from fabrizio-dev.ree.adwin.renesas.com (unknown [10.226.36.196]) by relmlir5.idc.renesas.com (Postfix) with ESMTP id 2DA3B400D0EC; Sat, 7 Dec 2019 01:33:14 +0900 (JST) From: Fabrizio Castro To: Laurent Pinchart , Geert Uytterhoeven , David Airlie , Daniel Vetter , Rob Herring , Mark Rutland , Thierry Reding , Maarten Lankhorst , Maxime Ripard , Sean Paul , Andrzej Hajda Cc: Fabrizio Castro , Sam Ravnborg , Simon Horman , Magnus Damm , Kieran Bingham , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Chris Paterson , Biju Das , Laurent Pinchart , Jacopo Mondi , ebiharaml@si-linux.co.jp Subject: [PATCH v4 3/7] drm: rcar-du: lvds: Get dual link configuration from DT Date: Fri, 6 Dec 2019 16:32:50 +0000 Message-Id: <1575649974-31472-4-git-send-email-fabrizio.castro@bp.renesas.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1575649974-31472-1-git-send-email-fabrizio.castro@bp.renesas.com> References: <1575649974-31472-1-git-send-email-fabrizio.castro@bp.renesas.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org For dual-LVDS configurations, it is now possible to mark the DT port nodes for the sink with boolean properties (like dual-lvds-even-pixels and dual-lvds-odd-pixels) to let drivers know the encoders need to be configured in dual-LVDS mode. Rework the implementation of rcar_lvds_parse_dt_companion to make use of the DT markers while keeping backward compatibility. Signed-off-by: Fabrizio Castro --- v3->v4: * New patch extracted from patch: "drm: rcar-du: lvds: Add dual-LVDS panels support" --- drivers/gpu/drm/rcar-du/rcar_lvds.c | 56 +++++++++++++++++++++++++++++++------ 1 file changed, 47 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 3cb0a83..6c1f171 100644 --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c @@ -669,8 +669,10 @@ EXPORT_SYMBOL_GPL(rcar_lvds_dual_link); static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds) { const struct of_device_id *match; - struct device_node *companion; + struct device_node *companion, *p0, *p1; + struct rcar_lvds *companion_lvds; struct device *dev = lvds->dev; + int dual_link; int ret = 0; /* Locate the companion LVDS encoder for dual-link operation, if any. */ @@ -689,13 +691,55 @@ static int rcar_lvds_parse_dt_companion(struct rcar_lvds *lvds) goto done; } + /* + * We need to work out if the sink is expecting us to function in + * dual-link mode. We do this by looking at the DT port nodes we are + * connected to, if they are marked as expecting even pixels and + * odd pixels than we need to enable vertical stripe output. + */ + p0 = of_graph_get_port_by_id(dev->of_node, 1); + p1 = of_graph_get_port_by_id(companion, 1); + dual_link = drm_of_lvds_get_dual_link_pixel_order(p0, p1); + of_node_put(p0); + of_node_put(p1); + if (dual_link >= DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS) { + lvds->dual_link = true; + } else if (lvds->next_bridge && lvds->next_bridge->timings) { + /* + * Early dual-link bridge specific implementations populate the + * timings field of drm_bridge, read the dual_link flag off the + * bridge directly for backward compatibility. + */ + lvds->dual_link = lvds->next_bridge->timings->dual_link; + } + + if (!lvds->dual_link) { + dev_dbg(dev, "Single-link configuration detected\n"); + goto done; + } + lvds->companion = of_drm_find_bridge(companion); if (!lvds->companion) { ret = -EPROBE_DEFER; goto done; } - dev_dbg(dev, "Found companion encoder %pOF\n", companion); + dev_dbg(dev, + "Dual-link configuration detected (companion encoder %pOF)\n", + companion); + + companion_lvds = bridge_to_rcar_lvds(lvds->companion); + + /* + * FIXME: We should not be messing with the companion encoder private + * data from the primary encoder, we should rather let the companion + * encoder work things out on its own. However, the companion encoder + * doesn't hold a reference to the primary encoder, and + * drm_of_lvds_get_dual_link_pixel_order needs to be given references + * to the output ports of both encoders, therefore leave it like this + * for the time being. + */ + companion_lvds->dual_link = true; done: of_node_put(companion); @@ -739,13 +783,7 @@ static int rcar_lvds_parse_dt(struct rcar_lvds *lvds) if (ret) goto done; - if ((lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) && - lvds->next_bridge) - lvds->dual_link = lvds->next_bridge->timings - ? lvds->next_bridge->timings->dual_link - : false; - - if (lvds->dual_link) + if (lvds->info->quirks & RCAR_LVDS_QUIRK_DUAL_LINK) ret = rcar_lvds_parse_dt_companion(lvds); done: -- 2.7.4