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=-2.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, T_DKIMWL_WL_HIGH,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 D97E6C468BC for ; Fri, 7 Jun 2019 09:41:05 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AE4DD2133D for ; Fri, 7 Jun 2019 09:41:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nxYKdX9Z" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AE4DD2133D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fXx4euySFIv18Xz8rsLR/gZtD1chozhiuTaFt5Wg9qc=; b=nxYKdX9ZWiU0Sk dgCAfMXH3foOpHiPnkYRLntiXlEsnS5QBJ3kgfqxQyiAvTnIyLAn8YQT3C+MyUw42FrDEqaI5fZXq oNpEtkxIZqi5QiGv1bLKWeh0eIhb81d/byILfPxJxNW0TbXPPtxHpWXps4sjaBM5ukjWnOvKzkIJC v70M7X0mcvNBl6j8lqCTuc5eyuD6V019rkNdAM5v7d3pbpJbJOQqAfCA4OnRmJAtBgepm8lTnksq1 gjnS7vxJLwvwBsInAVUaia8HWumGucBJhQ2fU+bWupjwqTnweaTtVwf3bu/gwY4GNG+SEl3Fg17oa RZ257XpugMj00N08zixw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hZBMv-0002VN-4k; Fri, 07 Jun 2019 09:41:05 +0000 Received: from verein.lst.de ([213.95.11.211] helo=newverein.lst.de) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hZBMr-0002UR-Lw for linux-arm-kernel@lists.infradead.org; Fri, 07 Jun 2019 09:41:03 +0000 Received: by newverein.lst.de (Postfix, from userid 2005) id 931BF68C65; Fri, 7 Jun 2019 11:40:30 +0200 (CEST) Date: Fri, 7 Jun 2019 11:40:30 +0200 From: Torsten Duwe To: Maxime Ripard Subject: Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I Message-ID: <20190607094030.GA12373@lst.de> References: <20190604122150.29D6468B05@newverein.lst.de> <20190604122308.98D4868B20@newverein.lst.de> <20190605101317.GA9345@lst.de> <20190605120237.ekmytfxcwbjaqy3x@flea> <20190607062802.m5wslx3imiqooq5a@flea> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190607062802.m5wslx3imiqooq5a@flea> User-Agent: Mutt/1.5.17 (2007-11-01) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190607_024102_014339_760EDA12 X-CRM114-Status: GOOD ( 21.32 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , devicetree , David Airlie , Greg Kroah-Hartman , linux-kernel , dri-devel , Andrzej Hajda , Chen-Yu Tsai , Rob Herring , Thierry Reding , Laurent Pinchart , Daniel Vetter , Harald Geyer , Sean Paul , Thomas Gleixner , arm-linux , Icenowy Zheng Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 07, 2019 at 08:28:02AM +0200, Maxime Ripard wrote: > On Thu, Jun 06, 2019 at 03:59:27PM +0200, Harald Geyer wrote: > > > > If think valid compatible properties would be: > > compatible = "innolux,n116bge", "simple-panel"; > > compatible = "edp-connector", "simple-panel"; > > A connector isn't a panel. > > > compatible = "innolux,n116bge", "edp-connector", "simple-panel"; > > And the innolux,n116bge is certainly not a connector either. > > > compatible = "edp-connector", "innolux,n116bge", "simple-panel"; > > > > I can't make up my mind which one I prefere. However neither of these > > variants requires actually implmenting an edp-connector driver. > > No-one asked to do an edp-connector driver. You should use it in your > DT, but if you want to have some code in your driver that parses the > DT directly, I'm totally fine with that. I must admit I fail to understand what that extra node would be good for. Logically, the eDP far side is connected to the well-known n116bge. Inside the laptop case it might as well be a flat ribbon cable or soldered directly. In good intention, that's all I wanted to express in the DT. I don't know whether the relevant mechanical dimensions of the panel and the connector are standardised, so whether one could in theory assemble it with a different panel than the one it came with. OTOH, as I checked during the discussion with anarsoul, the panel's supply voltage is permanently connected to the main 3.3V rail. We already agreed that the eDP output port must not neccessarily be specified, this setup is a good example why: because the panel is always powered, the anx6345 can always pull valid EDID data from it so at this stage there's no need for any OS driver to reach beyond the bridge. IIRC even the backlight got switched off for the blank screen without. All I wanted to say is that "there's usually an n116bge behind it"; but this is mostly redundant. So, shall we just drop the output port specification (along with the panel node) in order to get one step further? > I guess you should describe why do you think it's "clear", because I'm > not sure this is obvious for everyone here. eDP allows to discover > which device is on the other side and its supported timings, just like > HDMI for example (or regular DP, for that matter). Would you think > it's clearly preferable to ship a DT with the DP/HDMI monitor > connected on the other side exposed as a panel as well? Well, as I wrote: "in good intention". That's the panel that comes with the kit but it is very well detected automatically, just like you describe. So, just leave it out? Torsten _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel