All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasily Khoruzhick <anarsoul@gmail.com>
To: Torsten Duwe <duwe@lst.de>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Chen-Yu Tsai <wens@csie.org>, Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Icenowy Zheng <icenowy@aosc.io>,
	Sean Paul <seanpaul@chromium.org>,
	Harald Geyer <harald@ccbib.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	devicetree <devicetree@vger.kernel.org>,
	arm-linux <linux-arm-kernel@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I
Date: Fri, 17 May 2019 08:25:53 -0700	[thread overview]
Message-ID: <CA+E=qVcpMeFfC0EEZRpp3Hc_yBGFMv6cGKGSQENpUTw_ZH7UwQ@mail.gmail.com> (raw)
In-Reply-To: <20190517094708.GA16858@lst.de>

On Fri, May 17, 2019 at 2:47 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> > >
> > > So for all current practical purposes, we can assume the Teres-I panel
> > > to be powered properly and providing valid EDID; nothing to worry about
> > > in software.
> >
> > You're creating a generic binding for all the users of that bridge,
> > while considering only the specific case of the Teres-I.
>
> All I'm saying is that _this_ usage is also valid. Nothing keeps other
> users from defining the output panel; on the contrary: the driver at hand
> already considers an _optional_ panel and handles it, conditionally. So
> driver and binding spec are 100% in sync here.

Well, endpoint is not necessarily a panel. It can be another bridge or
connector - that's why panel can be optional in driver. But it don't
think that you can just omit an endpoint.

> This is much more straightforward than requiring an output and making up
> some dummy code and params because it cannot reasonably be handled.
> (Remember, if there is an output, the driver will make calls to the
> "attached device" driver.)

They aren't dummy. Moreover you have to attach backlight somewhere (to
panel) so it can be disabled when output is disabled.

Try 'xrandr --output eDP-1 --off' on teres with your current code and
see that backlight stays on.

>
>         Torsten
>

WARNING: multiple messages have this Message-ID (diff)
From: Vasily Khoruzhick <anarsoul@gmail.com>
To: Torsten Duwe <duwe@lst.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>, Chen-Yu Tsai <wens@csie.org>,
	Rob Herring <robh+dt@kernel.org>,
	Thierry Reding <thierry.reding@gmail.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Harald Geyer <harald@ccbib.org>,
	Sean Paul <seanpaul@chromium.org>,
	arm-linux <linux-arm-kernel@lists.infradead.org>,
	Icenowy Zheng <icenowy@aosc.io>
Subject: Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I
Date: Fri, 17 May 2019 08:25:53 -0700	[thread overview]
Message-ID: <CA+E=qVcpMeFfC0EEZRpp3Hc_yBGFMv6cGKGSQENpUTw_ZH7UwQ@mail.gmail.com> (raw)
In-Reply-To: <20190517094708.GA16858@lst.de>

On Fri, May 17, 2019 at 2:47 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> > >
> > > So for all current practical purposes, we can assume the Teres-I panel
> > > to be powered properly and providing valid EDID; nothing to worry about
> > > in software.
> >
> > You're creating a generic binding for all the users of that bridge,
> > while considering only the specific case of the Teres-I.
>
> All I'm saying is that _this_ usage is also valid. Nothing keeps other
> users from defining the output panel; on the contrary: the driver at hand
> already considers an _optional_ panel and handles it, conditionally. So
> driver and binding spec are 100% in sync here.

Well, endpoint is not necessarily a panel. It can be another bridge or
connector - that's why panel can be optional in driver. But it don't
think that you can just omit an endpoint.

> This is much more straightforward than requiring an output and making up
> some dummy code and params because it cannot reasonably be handled.
> (Remember, if there is an output, the driver will make calls to the
> "attached device" driver.)

They aren't dummy. Moreover you have to attach backlight somewhere (to
panel) so it can be disabled when output is disabled.

Try 'xrandr --output eDP-1 --off' on teres with your current code and
see that backlight stays on.

>
>         Torsten
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Vasily Khoruzhick <anarsoul@gmail.com>
To: Torsten Duwe <duwe@lst.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree <devicetree@vger.kernel.org>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	David Airlie <airlied@linux.ie>, 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>,
	arm-linux <linux-arm-kernel@lists.infradead.org>,
	Icenowy Zheng <icenowy@aosc.io>
Subject: Re: [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge on Teres-I
Date: Fri, 17 May 2019 08:25:53 -0700	[thread overview]
Message-ID: <CA+E=qVcpMeFfC0EEZRpp3Hc_yBGFMv6cGKGSQENpUTw_ZH7UwQ@mail.gmail.com> (raw)
In-Reply-To: <20190517094708.GA16858@lst.de>

On Fri, May 17, 2019 at 2:47 AM Torsten Duwe <duwe@lst.de> wrote:
>
> On Fri, May 17, 2019 at 11:08:45AM +0200, Maxime Ripard wrote:
> > >
> > > So for all current practical purposes, we can assume the Teres-I panel
> > > to be powered properly and providing valid EDID; nothing to worry about
> > > in software.
> >
> > You're creating a generic binding for all the users of that bridge,
> > while considering only the specific case of the Teres-I.
>
> All I'm saying is that _this_ usage is also valid. Nothing keeps other
> users from defining the output panel; on the contrary: the driver at hand
> already considers an _optional_ panel and handles it, conditionally. So
> driver and binding spec are 100% in sync here.

Well, endpoint is not necessarily a panel. It can be another bridge or
connector - that's why panel can be optional in driver. But it don't
think that you can just omit an endpoint.

> This is much more straightforward than requiring an output and making up
> some dummy code and params because it cannot reasonably be handled.
> (Remember, if there is an output, the driver will make calls to the
> "attached device" driver.)

They aren't dummy. Moreover you have to attach backlight somewhere (to
panel) so it can be disabled when output is disabled.

Try 'xrandr --output eDP-1 --off' on teres with your current code and
see that backlight stays on.

>
>         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-05-17 15:26 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 15:59 [PATCH 0/4] Add missing device nodes for Olimex Teres-I Torsten Duwe
2019-05-14 15:59 ` Torsten Duwe
2019-05-14 16:02 ` [PATCH 1/4] arm64: DTS: allwinner: a64: Add pinmux for RGB666 LCD Torsten Duwe
2019-05-14 16:02   ` Torsten Duwe
2019-05-14 16:02   ` Torsten Duwe
2019-05-16  8:54   ` Maxime Ripard
2019-05-16  8:54     ` Maxime Ripard
2019-05-14 16:02 ` [PATCH 2/4] dt-bindings: Add ANX6345 DP/eDP transmitter binding Torsten Duwe
2019-05-14 16:02   ` Torsten Duwe
2019-05-14 16:02 ` [PATCH 3/4] arm64: DTS: allwinner: a64: Enable audio on Teres-I Torsten Duwe
2019-05-14 16:02   ` Torsten Duwe
2019-05-14 16:02 ` [PATCH 4/4] arm64: DTS: allwinner: a64: enable ANX6345 bridge " Torsten Duwe
2019-05-14 16:02   ` Torsten Duwe
2019-05-14 17:48   ` Vasily Khoruzhick
2019-05-14 17:48     ` Vasily Khoruzhick
2019-05-14 17:48     ` Vasily Khoruzhick
2019-05-15  7:31     ` Torsten Duwe
2019-05-15  7:31       ` Torsten Duwe
2019-05-15 15:08       ` Vasily Khoruzhick
2019-05-15 15:08         ` Vasily Khoruzhick
2019-05-16 15:48         ` Torsten Duwe
2019-05-16 15:48           ` Torsten Duwe
2019-05-16 16:06           ` Vasily Khoruzhick
2019-05-16 16:06             ` Vasily Khoruzhick
2019-05-16 16:48             ` Torsten Duwe
2019-05-16 16:48               ` Torsten Duwe
2019-05-16 18:26               ` Vasily Khoruzhick
2019-05-16 18:26                 ` Vasily Khoruzhick
2019-05-17  7:27               ` Maxime Ripard
2019-05-17  7:27                 ` Maxime Ripard
2019-05-17  7:27                 ` Maxime Ripard
2019-05-17  8:14                 ` Torsten Duwe
2019-05-17  8:14                   ` Torsten Duwe
2019-05-17  9:08                   ` Maxime Ripard
2019-05-17  9:08                     ` Maxime Ripard
2019-05-17  9:08                     ` Maxime Ripard
2019-05-17  9:47                     ` Torsten Duwe
2019-05-17  9:47                       ` Torsten Duwe
2019-05-17 15:25                       ` Vasily Khoruzhick [this message]
2019-05-17 15:25                         ` Vasily Khoruzhick
2019-05-17 15:25                         ` Vasily Khoruzhick

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='CA+E=qVcpMeFfC0EEZRpp3Hc_yBGFMv6cGKGSQENpUTw_ZH7UwQ@mail.gmail.com' \
    --to=anarsoul@gmail.com \
    --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=duwe@lst.de \
    --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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.