From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ED8BC4363A for ; Mon, 5 Oct 2020 14:18:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BEFAA2085B for ; Mon, 5 Oct 2020 14:18:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725936AbgJEOS2 (ORCPT ); Mon, 5 Oct 2020 10:18:28 -0400 Received: from new4-smtp.messagingengine.com ([66.111.4.230]:49737 "EHLO new4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725932AbgJEOS2 (ORCPT ); Mon, 5 Oct 2020 10:18:28 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 71C67580333; Mon, 5 Oct 2020 10:18:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 05 Oct 2020 10:18:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=6wsLdnF0Lcj4VRsQV0kAmaPfVtC x6J2lDHDdjPu+HyI=; b=qEf14hR9GLWy2VYGK0g4RItIG6bSVGLVfyck9C/MtYK 8QojfuokJjmy3jNrqw0QbShD5V37P4bhDNMyH1k87xvZAHRb++uD1Q/1F6MOTRBP DlaDa2+CQA3IzxmfPJKvvpD/Y7r3uEICJUatd4zgWHZgQDAX/lK0BzlT7yKLbeHg CNdldgGtoIb0jhGG7YRbPx3XUCqJyZ+NsH3oHR5XTXDxlvTDUV3RElsI3aChgiOp fPufdD373MI8kbPfKYe75WjXx45v+1zjZB9BDb7M75ykDKJ41NQ/OYscMSuXFHKk MIX6o6R7JccBjBLvLY6rvIxwI/wcRJJbHJfvzyMnjAw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=6wsLdn F0Lcj4VRsQV0kAmaPfVtCx6J2lDHDdjPu+HyI=; b=o9jZWd/ynS7GLOdyWQCj+m rEctlEU2QqL3K2BEK37+O9DiRY2JSM6vC/nGDXSI/KZkAnkDFYH9aRXvwA6st8IE 6Fni0N9Sx4WK0pJetFjGY+4QzrnkLB8Gqj6cy2RLKGF+afuu+2RYg8BujsbAJdV4 9thcnZtcy2NrDLnd3uSaHUmj8nsSxu7Wu9obcGZ3xyrrR4IG+KPKYQwBmUesuOm0 JCkdT+fdz69g1b3r9pY7ZPu23cG9BCE8dOEF01lN4elyDJQcNn6+UhYE6ilNrmxd 8E/JG+3CufRvYMmdLGl9HZCk1GL7i6ic9InU7KeLfMh0+cdAoRDtKfCqI8kgJEiQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedvgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomhepofgrgihimhgv ucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrghtth gvrhhnpeelkeeghefhuddtleejgfeljeffheffgfeijefhgfeufefhtdevteegheeiheeg udenucfkphepledtrdekledrieekrdejieenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmrgigihhmvgestggvrhhnohdrthgvtghh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 9A796328005D; Mon, 5 Oct 2020 10:18:19 -0400 (EDT) Date: Mon, 5 Oct 2020 16:18:17 +0200 From: Maxime Ripard To: Chen-Yu Tsai Cc: dri-devel , Maarten Lankhorst , Thomas Zimmermann , Daniel Vetter , David Airlie , devicetree , Mark Rutland , Rob Herring , Frank Rowand , Laurent Pinchart , linux-arm-kernel Subject: Re: [PATCH v2 2/4] drm/sun4i: tcon: Refactor the LVDS and panel probing Message-ID: <20201005141817.rsj7d6wwnsgdrydo@gilmour.lan> References: <1df5a7bcafa091e008edb439ee9de4262ae4d5d1.1596101672.git-series.maxime@cerno.tech> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="k233jlwaazxqabpi" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org --k233jlwaazxqabpi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Chen-Yu, Sorry for the delay On Sat, Aug 29, 2020 at 02:43:53PM +0800, Chen-Yu Tsai wrote: > > +static int sun4i_tcon_register_panel(struct drm_device *drm, > > + struct sun4i_tcon *tcon) > > +{ > > + struct device_node *companion; > > + struct device_node *remote; > > + struct device *dev =3D tcon->dev; > > + bool has_lvds_alt; > > + bool has_lvds_rst; > > + int ret; > > + > > + /* > > + * If we have an LVDS panel connected to the TCON, we should > > + * just probe the LVDS connector. Otherwise, let's just register > > + * an RGB panel. > > + */ > > + remote =3D of_graph_get_remote_node(dev->of_node, 1, 0); > > + if (!tcon->quirks->supports_lvds || > > + !of_device_is_compatible(remote, "panel-lvds")) > > + return sun4i_rgb_init(drm, tcon); >=20 > Slightly related: IIRC there are a few LVDS panels supported in panel-sim= ple > so they don't use the panel-lvds compatible. Any idea how to deal with th= ose? I agree that this is an issue, I'm not entirely sure how to fix it. The proper fix would be to have multiple output ports, one for each output type, but given how our current binding looks like I'm not sure how we could retro-fit that without some horror-looking code. Maybe we can add a property on the endpoint? Maxime --k233jlwaazxqabpi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX3srKQAKCRDj7w1vZxhR xW3UAP9LhISLvgGCp85tX5q7sVKwegF/hpc+qmUEDuDHFUfNxAD/TgzPFraDdq+R cptbFzYYVHyTjiKe1IYyDHx6x0BdTgA= =n+wt -----END PGP SIGNATURE----- --k233jlwaazxqabpi--