From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Duwe Subject: Re: [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I Date: Fri, 7 Jun 2019 11:40:30 +0200 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-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190607062802.m5wslx3imiqooq5a@flea> Sender: linux-kernel-owner@vger.kernel.org To: Maxime Ripard Cc: Harald Geyer , Vasily Khoruzhick , Chen-Yu Tsai , Rob Herring , Mark Rutland , Thierry Reding , David Airlie , Daniel Vetter , Andrzej Hajda , Laurent Pinchart , Icenowy Zheng , Sean Paul , Greg Kroah-Hartman , Thomas Gleixner , dri-devel , devicetree , arm-linux , linux-kernel List-Id: devicetree@vger.kernel.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