linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Torsten Duwe <duwe@lst.de>
To: Maxime Ripard <maxime.ripard@bootlin.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>,
	David Airlie <airlied@linux.ie>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Andrzej Hajda <a.hajda@samsung.com>, Chen-Yu Tsai <wens@csie.org>,
	Rob Herring <robh+dt@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Daniel Vetter <daniel@ffwll.ch>, Harald Geyer <harald@ccbib.org>,
	Sean Paul <seanpaul@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	arm-linux <linux-arm-kernel@lists.infradead.org>,
	Icenowy Zheng <icenowy@aosc.io>
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	[thread overview]
Message-ID: <20190607094030.GA12373@lst.de> (raw)
In-Reply-To: <20190607062802.m5wslx3imiqooq5a@flea>

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

  reply	other threads:[~2019-06-07  9:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-04 12:21 [PATCH v2 0/7] Add anx6345 DP/eDP bridge for Olimex Teres-I Torsten Duwe
2019-06-04 12:22 ` [PATCH v2 1/7] drm/bridge: move ANA78xx driver to analogix subdirectory Torsten Duwe
2019-06-12 10:16   ` Andrzej Hajda
2019-06-04 12:22 ` [PATCH v2 2/7] drm/bridge: split some definitions of ANX78xx to dedicated headers Torsten Duwe
2019-06-12  7:40   ` Andrzej Hajda
2019-06-04 12:22 ` [PATCH v2 3/7] drm/bridge: extract some Analogix I2C DP common code Torsten Duwe
2019-06-12  7:41   ` Andrzej Hajda
2019-06-04 12:22 ` [PATCH v2 4/7] drm/bridge: Prepare Analogix anx6345 support Torsten Duwe
2019-06-12  7:43   ` Andrzej Hajda
2019-06-04 12:23 ` [PATCH v2 5/7] drm/bridge: Add " Torsten Duwe
2019-06-12  9:13   ` Andrzej Hajda
2019-07-18 16:42     ` Torsten Duwe
2019-06-04 12:23 ` [PATCH v2 6/7] dt-bindings: Add ANX6345 DP/eDP transmitter binding Torsten Duwe
2019-06-12  8:16   ` Andrzej Hajda
2019-06-12 14:59     ` Torsten Duwe
2019-06-04 12:23 ` [PATCH v2 7/7] arm64: dts: allwinner: a64: enable ANX6345 bridge on Teres-I Torsten Duwe
2019-06-04 15:08   ` Vasily Khoruzhick
2019-06-05 10:13     ` Torsten Duwe
2019-06-05 12:02       ` Maxime Ripard
2019-06-06 13:59         ` Harald Geyer
2019-06-07  6:28           ` Maxime Ripard
2019-06-07  9:40             ` Torsten Duwe [this message]
2019-06-12 10:00               ` Andrzej Hajda
2019-06-12 15:20                 ` Maxime Ripard
2019-06-28 10:39                   ` Andrzej Hajda
2019-07-01  9:58                     ` Maxime Ripard
2019-07-01 12:27                       ` Andrzej Hajda
2019-07-02  8:13                         ` Maxime Ripard
2019-07-09  0:49                       ` Vasily Khoruzhick
2019-07-09  8:55                         ` Maxime Ripard
2019-07-09  8:58                           ` Icenowy Zheng
2019-07-09 14:21                             ` Maxime Ripard
2019-07-09 20:30                           ` Vasily Khoruzhick
2019-07-10 11:40                             ` Maxime Ripard
2019-07-10 22:11                               ` Vasily Khoruzhick
2019-07-12 20:15                                 ` Maxime Ripard
2019-07-16  0:28                                   ` Vasily Khoruzhick
2019-07-24 13:58                                     ` Maxime Ripard
2019-06-12 15:34               ` Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190607094030.GA12373@lst.de \
    --to=duwe@lst.de \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=harald@ccbib.org \
    --cc=icenowy@aosc.io \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maxime.ripard@bootlin.com \
    --cc=robh+dt@kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).