Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4746600yba; Wed, 10 Apr 2019 04:10:52 -0700 (PDT) X-Google-Smtp-Source: APXvYqzfgJeOD4jS4NJf2JJZ9swSTHSNrUriwCy204NsGmX6NKDiCB37IOYLRENZ+/zjN+L2DUxq X-Received: by 2002:a17:902:4501:: with SMTP id m1mr14518356pld.290.1554894652654; Wed, 10 Apr 2019 04:10:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554894652; cv=none; d=google.com; s=arc-20160816; b=YtpkOSYB9dc4Unyle9QwSzyU/QCEkqI1q8ZSeHbjBxZkoP5cqmmwWPCVTpqZGMOXLe rB/u1V4P8db1C7RVii6jiEmsBpU0V1fVe7uIcZzHtwjnUKnV+RH5IhNkMCRwBL4nGudR 2orA8RivU935TFddV/Yy5W+Ujnyr66WidSu07Yixd6lTH46HYCulUbdLF/98lF5Bblf7 T5NrI5HrnrMoI9mq1kRMLCuUWdB4pi/7ErExAn24i8hq6rKCsGiJI8jQIdOpSMLwIZbW rbRWMzJMeABONNLMsgZRr/ZgW7ayEnwVYQvKlDPAItG2IAudR3MsTaCzXzeSIKCg8RVJ fmsQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=JbnKEVFFIiu+8E2oh/BaDrp2Mk8b5FrSDm2iG+6lWNQ=; b=Tdmx5tlmxmD6Q0RIRXS6YlsB9OB85tLeusMkjVD7fExISjR3ihNhRiDyFA3GC7r1pD uzzExBPQnFJ9KDohwewMdkgwX2pr4TFYXoNTau6tcuMvLVI5iqv7d8yZ4f0SlvRdgAj+ q7vvsr066KrGfRk8RfkQ+2C0KyT8O1iBWvQzQA+8nGWosQoFX6bgBrJQJxAWB1DpOTgU m/eF2hztDF2ykv4CNBqgcKrPBeA4hsYrsP/Qal4mRyQqzeA8N/i0gd/M1lmtQn6hDJ3e rqTyPtWkgliuSdrk5ylnCwr+QgiWm8OIT4LX5En+ce1Ww0NPDZYombZo12rMFAkaWjB3 P31w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p1si27065734pls.64.2019.04.10.04.10.36; Wed, 10 Apr 2019 04:10: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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729503AbfDJK5a (ORCPT + 99 others); Wed, 10 Apr 2019 06:57:30 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:53912 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727223AbfDJK53 (ORCPT ); Wed, 10 Apr 2019 06:57:29 -0400 Received: from [IPv6:2a02:2450:102f:3e0:9891:9d6a:3d2f:24f2] (unknown [IPv6:2a02:2450:102f:3e0:9891:9d6a:3d2f:24f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: robertfoss) by bhuna.collabora.co.uk (Postfix) with ESMTPSA id 18CD627F6D6; Wed, 10 Apr 2019 11:57:27 +0100 (BST) Subject: Re: [PATCH] ARM: dts: imx6qdl-nitrogen6_max: Disable LVDS channels To: Gary Bisson Cc: Mark Rutland , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Fabio Estevam , Sascha Hauer , linux-kernel , Troy Kisky , Rob Herring , NXP Linux Team , Sascha Hauer , Fabio Estevam , Shawn Guo , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" References: <20190408175319.9106-1-robert.foss@collabora.com> <4fd506a1-c961-0569-6d39-283758f363d9@collabora.com> From: Robert Foss Message-ID: <550afae6-8dd8-39aa-c7a2-01b27557aa53@collabora.com> Date: Wed, 10 Apr 2019 12:57:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey Gary, On 4/10/19 9:35 AM, Gary Bisson wrote: > Hi, > > On Tue, Apr 9, 2019 at 2:07 AM Robert Foss wrote: >> >> Hey Fabio, >> >> On 4/8/19 10:37 PM, Fabio Estevam wrote: >>> Hi Robert, >>> >>> [Adding Gary] > > Adding Troy, I'm no longer a full-time employee at Boundary Devices. > >>> On Mon, Apr 8, 2019 at 2:54 PM Robert Foss wrote: >>>> >>>> If a LVDS device is not connected, having the LVDS channels >>>> enabled will prevent imx-ldb from probing correctly even >>>> if other CRTCs are connected. >>>> >>>> Signed-off-by: Robert Foss >>>> --- >>>> arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi | 4 ++-- >>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi >>>> index 39200e5dc896..5b413cf4c250 100644 >>>> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi >>>> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6_max.dtsi >>>> @@ -703,7 +703,7 @@ >>>> status = "okay"; >>>> >>>> lvds-channel@0 { >>>> - status = "okay"; >>>> + status = "disabled"; >>>> >>>> port@4 { >>>> reg = <4>; >>>> @@ -715,7 +715,7 @@ >>>> }; >>>> >>>> lvds-channel@1 { >>>> - status = "okay"; >>>> + status = "disabled"; >>> >>> I am not sure I understood what you are trying to fix. >> >> If CONFIG_DRM_IMX_LDB is enabled, LVDS DT channels are enabled >> and no LVDS-panels are connected the imx-ldb driver will >> fail to bind. >> >> This is a problem, since it will prevent other actually connected >> display output from being used, even if they bind properly. >> >>> >>> Could you please share some logs when imx-ldb fails to probe correctly? >> >> >> [ 2.119563] component_bind_all() trying to bind: ldb >> [ 2.124600] imx-drm display-subsystem: binding ldb (ops imx_ldb_ops) >> [ 2.146169] drm_of_find_panel_or_bridge() np->name=lvds-channel np->type= >> [ 2.153709] drm_of_find_panel_or_bridge() no panel found for remote >> [ 2.160081] drm_of_find_panel_or_bridge() bridge needed >> [ 2.162043] drm_of_find_panel_or_bridge() bridge not found >> [ 2.165331] drm_of_find_panel_or_bridge() failed >> [ 2.170023] imx-drm display-subsystem: failed to bind ldb (ops imx_ldb_ops): -517 >> >> This at the same time as HDMI binds properly: >> >> [ 4.458954] dwhdmi-imx 120000.hdmi: Detected HDMI TX controller v1.30a with >> HDCP (DWC HDMI 3D TX PHY) >> [ 4.469633] imx-drm display-subsystem: bound 120000.hdmi (ops dw_hdmi_imx_ops) >> >> Which in the end causes the IMX driver to not initialize properly >> and ignore the HDMI connection that bound properly. >> This in turn prevents us from having any graphical output while there >> is no LVDS panel connected. > > Does this happen if the LVDS is disabled in cmdline? (adding "video=LVDS-1:d") I hadn't tried this before, but is seems yo yield the same results # cat /proc/cmdline video=LVDS-1:d enforcing=0 ip=dhcp rw rootwait root=/dev/mmcblk1p1 log_buf_len=16M cma=512M vmalloc=512M # dmesg imx-drm display-subsystem: failed to bind disp0 (ops imx_pd_ops): -517 imx-drm display-subsystem: master bind failed: -517 This dmesg log is failing to bind disp0 at another point than what I was seeing before, yet the result is the same. The connected HDMI output is not brought online correctly. > > Note that a bootscript was written for mainline kernel that takes care > of display configuration [1]. > > Currently this bootscript disables all the displays that aren't used. > It was tested with HDMI, where LVDS and LCD display are disabled, and > it *used to* work. > > If this doesn't work then there's most likely a regression somewhere. > > Regards, > Gary > > [1] https://github.com/boundarydevices/u-boot-imx6/blob/boundary-v2018.07/board/boundary/bootscripts/bootscript-mainline.txt#L90 > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >