From: Rob Herring <robh@kernel.org> To: Doug Anderson <dianders@chromium.org> Cc: Andrzej Hajda <a.hajda@samsung.com>, Neil Armstrong <narmstrong@baylibre.com>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Jonas Karlman <jonas@kwiboo.se>, Sam Ravnborg <sam@ravnborg.org>, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>, Lyude Paul <lyude@redhat.com>, Thierry Reding <treding@nvidia.com>, Stephen Boyd <swboyd@chromium.org>, Bjorn Andersson <bjorn.andersson@linaro.org>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Linus W <linus.walleij@linaro.org>, dri-devel <dri-devel@lists.freedesktop.org>, Rob Clark <robdclark@chromium.org>, Steev Klimaszewski <steev@kali.org>, Daniel Vetter <daniel@ffwll.ch>, David Airlie <airlied@linux.ie>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v7 03/10] dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child Date: Thu, 20 May 2021 08:25:06 -0500 [thread overview] Message-ID: <CAL_JsqL9p1nOQs5V5xN167E860Gm+3dTRaOwpv2X+AP=cM1Q_g@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=XNaB8fVvwwHPgo8wPmG3EmJ68u_3o8qpPXn4YobNokAA@mail.gmail.com> On Wed, May 19, 2021 at 4:06 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, May 19, 2021 at 1:02 PM Rob Herring <robh@kernel.org> wrote: > > > > On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote: > > > We want to be able to list an eDP panel as a child of a ti-sn65dsi86 > > > node to represent the fact that the panel is connected to the bridge's > > > DP AUX bus. Though the panel and the bridge chip are connected in > > > several ways, the DP AUX bus is the primary control interface between > > > the two and thus makes the most sense to model in device tree > > > hierarchy. > > > > > > Listing a panel in this way makes it possible for the panel driver to > > > easily get access to the DP AUX bus that it resides on, which can be > > > useful to help in auto-detecting the panel and for turning on various > > > bits. > > > > > > NOTE: it's still possible to continue using the bridge chip and point > > > to a panel that _isn't_ listed as a child of the bridge chip (since > > > it's worked that way previously), but that should be deprecated since > > > there is no downside to listing the panel under the bridge chip. > > > > > > The idea for this bus's design was hashed out over IRC [1]. > > > > > > [1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-05-11 > > > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > --- > > > Possibly we might want something fancier that could be included by > > > other eDP controller bindings. If we want to do this, I'd love to be > > > pointed at a good example to follow. > > > > > > Changes in v7: > > > - ti-sn65dsi86: Add aux-bus child patch new for v7. > > > > > > .../bindings/display/bridge/ti,sn65dsi86.yaml | 22 ++++++++++++++++++- > > > 1 file changed, 21 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > index 26932d2e86ab..51f5a29e216c 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > @@ -70,6 +70,11 @@ properties: > > > const: 1 > > > description: See ../../pwm/pwm.yaml for description of the cell formats. > > > > > > + aux-bus: > > > > As this is a node: > > > > type: object > > > > > + description: > > > + It is recommended that you place your panel under the aux-bus node > > > + here to represent the control hierarchy. > > > + > > > ports: > > > $ref: /schemas/graph.yaml#/properties/ports > > > > > > @@ -201,11 +206,26 @@ examples: > > > > > > port@1 { > > > reg = <1>; > > > - endpoint { > > > + sn65dsi86_out: endpoint { > > > remote-endpoint = <&panel_in_edp>; > > > }; > > > }; > > > }; > > > + > > > + aux-bus { > > > + panel { > > > > We should perhaps have a separate aux-bus schema. > > Yeah. Before spending lots of time digging into how to do this I > wanted to see if anyone was going to give me a big-old NAK on the > whole approach. ;-) > > I guess I'd make a file called "dp-aux-bus.yaml" (maybe right under > bindings/display?) and then I'd include it like this: > > aux-bus: > $ref: "../dp-aux-bus.yaml#" Right. > > Something should > > define the child node is 'panel' and nothing else. > > At the moment the code also requires that the node name is 'aux-bus'. > Any objections to that? No. There's 2 ways to do that. The above does and adding $nodename in dp-aux-bus.yaml will. The latter also means the schema will be applied automatically to any node named 'aux-bus'. That means the schema will be applied twice unless you have 'select: false'. The main advantage of the latter case is it gets applied even without all the users converted to schema. > > Though perhaps > > connectors are valid too? > > They might be. We could always add it later? Sure. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh@kernel.org> To: Doug Anderson <dianders@chromium.org> Cc: Rob Clark <robdclark@chromium.org>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, Jonas Karlman <jonas@kwiboo.se>, David Airlie <airlied@linux.ie>, linux-arm-msm <linux-arm-msm@vger.kernel.org>, Neil Armstrong <narmstrong@baylibre.com>, LKML <linux-kernel@vger.kernel.org>, dri-devel <dri-devel@lists.freedesktop.org>, Stephen Boyd <swboyd@chromium.org>, Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>, Andrzej Hajda <a.hajda@samsung.com>, Bjorn Andersson <bjorn.andersson@linaro.org>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Thierry Reding <treding@nvidia.com>, Sam Ravnborg <sam@ravnborg.org>, Steev Klimaszewski <steev@kali.org> Subject: Re: [PATCH v7 03/10] dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child Date: Thu, 20 May 2021 08:25:06 -0500 [thread overview] Message-ID: <CAL_JsqL9p1nOQs5V5xN167E860Gm+3dTRaOwpv2X+AP=cM1Q_g@mail.gmail.com> (raw) In-Reply-To: <CAD=FV=XNaB8fVvwwHPgo8wPmG3EmJ68u_3o8qpPXn4YobNokAA@mail.gmail.com> On Wed, May 19, 2021 at 4:06 PM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, May 19, 2021 at 1:02 PM Rob Herring <robh@kernel.org> wrote: > > > > On Mon, May 17, 2021 at 01:09:00PM -0700, Douglas Anderson wrote: > > > We want to be able to list an eDP panel as a child of a ti-sn65dsi86 > > > node to represent the fact that the panel is connected to the bridge's > > > DP AUX bus. Though the panel and the bridge chip are connected in > > > several ways, the DP AUX bus is the primary control interface between > > > the two and thus makes the most sense to model in device tree > > > hierarchy. > > > > > > Listing a panel in this way makes it possible for the panel driver to > > > easily get access to the DP AUX bus that it resides on, which can be > > > useful to help in auto-detecting the panel and for turning on various > > > bits. > > > > > > NOTE: it's still possible to continue using the bridge chip and point > > > to a panel that _isn't_ listed as a child of the bridge chip (since > > > it's worked that way previously), but that should be deprecated since > > > there is no downside to listing the panel under the bridge chip. > > > > > > The idea for this bus's design was hashed out over IRC [1]. > > > > > > [1] https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2021-05-11 > > > > > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > > > --- > > > Possibly we might want something fancier that could be included by > > > other eDP controller bindings. If we want to do this, I'd love to be > > > pointed at a good example to follow. > > > > > > Changes in v7: > > > - ti-sn65dsi86: Add aux-bus child patch new for v7. > > > > > > .../bindings/display/bridge/ti,sn65dsi86.yaml | 22 ++++++++++++++++++- > > > 1 file changed, 21 insertions(+), 1 deletion(-) > > > > > > diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > index 26932d2e86ab..51f5a29e216c 100644 > > > --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml > > > @@ -70,6 +70,11 @@ properties: > > > const: 1 > > > description: See ../../pwm/pwm.yaml for description of the cell formats. > > > > > > + aux-bus: > > > > As this is a node: > > > > type: object > > > > > + description: > > > + It is recommended that you place your panel under the aux-bus node > > > + here to represent the control hierarchy. > > > + > > > ports: > > > $ref: /schemas/graph.yaml#/properties/ports > > > > > > @@ -201,11 +206,26 @@ examples: > > > > > > port@1 { > > > reg = <1>; > > > - endpoint { > > > + sn65dsi86_out: endpoint { > > > remote-endpoint = <&panel_in_edp>; > > > }; > > > }; > > > }; > > > + > > > + aux-bus { > > > + panel { > > > > We should perhaps have a separate aux-bus schema. > > Yeah. Before spending lots of time digging into how to do this I > wanted to see if anyone was going to give me a big-old NAK on the > whole approach. ;-) > > I guess I'd make a file called "dp-aux-bus.yaml" (maybe right under > bindings/display?) and then I'd include it like this: > > aux-bus: > $ref: "../dp-aux-bus.yaml#" Right. > > Something should > > define the child node is 'panel' and nothing else. > > At the moment the code also requires that the node name is 'aux-bus'. > Any objections to that? No. There's 2 ways to do that. The above does and adding $nodename in dp-aux-bus.yaml will. The latter also means the schema will be applied automatically to any node named 'aux-bus'. That means the schema will be applied twice unless you have 'select: false'. The main advantage of the latter case is it gets applied even without all the users converted to schema. > > Though perhaps > > connectors are valid too? > > They might be. We could always add it later? Sure. Rob
next prev parent reply other threads:[~2021-05-20 13:25 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-17 20:08 [PATCH v7 00/10] drm: Fix EDID reading on ti-sn65dsi86 by introducing the DP AUX bus Douglas Anderson 2021-05-17 20:08 ` Douglas Anderson 2021-05-17 20:08 ` [PATCH v7 01/10] drm/panel: panel-simple: Add missing pm_runtime_dont_use_autosuspend() calls Douglas Anderson 2021-05-17 20:08 ` Douglas Anderson 2021-05-24 20:22 ` Laurent Pinchart 2021-05-24 20:22 ` Laurent Pinchart 2021-05-24 21:08 ` Doug Anderson 2021-05-24 21:08 ` Doug Anderson 2021-05-17 20:08 ` [PATCH v7 02/10] dt-bindings: display: simple: List hpd properties in panel-simple Douglas Anderson 2021-05-17 20:08 ` Douglas Anderson 2021-05-18 12:41 ` Rob Herring 2021-05-18 12:41 ` Rob Herring 2021-05-18 13:58 ` Doug Anderson 2021-05-18 13:58 ` Doug Anderson 2021-05-22 10:38 ` Linus Walleij 2021-05-22 10:38 ` Linus Walleij 2021-05-17 20:09 ` [PATCH v7 03/10] dt-bindings: drm/bridge: ti-sn65dsi86: Add aux-bus child Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-19 20:01 ` Rob Herring 2021-05-19 20:01 ` Rob Herring 2021-05-19 21:06 ` Doug Anderson 2021-05-19 21:06 ` Doug Anderson 2021-05-20 13:25 ` Rob Herring [this message] 2021-05-20 13:25 ` Rob Herring 2021-05-17 20:09 ` [PATCH v7 04/10] drm: Introduce the DP AUX bus Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-22 10:34 ` Linus Walleij 2021-05-22 10:34 ` Linus Walleij 2021-05-17 20:09 ` [PATCH v7 05/10] drm/panel: panel-simple: Allow panel-simple be a DP AUX endpoint device Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-17 20:09 ` [PATCH v7 06/10] drm/panel: panel-simple: Stash DP AUX bus; allow using it for DDC Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-17 20:09 ` [PATCH v7 07/10] drm/bridge: ti-sn65dsi86: Promote the AUX channel to its own sub-dev Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-17 20:09 ` [PATCH v7 08/10] drm/bridge: ti-sn65dsi86: Add support for the DP AUX bus Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-22 10:35 ` Linus Walleij 2021-05-22 10:35 ` Linus Walleij 2021-05-24 20:29 ` Lyude Paul 2021-05-24 20:29 ` Lyude Paul 2021-05-17 20:09 ` [PATCH v7 09/10] drm/bridge: ti-sn65dsi86: Don't read EDID blob over DDC Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-17 20:09 ` [PATCH v7 10/10] arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip Douglas Anderson 2021-05-17 20:09 ` Douglas Anderson 2021-05-22 10:40 ` Linus Walleij 2021-05-22 10:40 ` Linus Walleij 2021-05-19 21:41 ` [PATCH v7 00/10] drm: Fix EDID reading on ti-sn65dsi86 by introducing the DP AUX bus Lyude Paul 2021-05-19 21:41 ` Lyude Paul 2021-05-21 23:07 ` Lyude Paul 2021-05-21 23:07 ` Lyude Paul 2021-05-24 15:14 ` Doug Anderson 2021-05-24 15:14 ` Doug Anderson
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='CAL_JsqL9p1nOQs5V5xN167E860Gm+3dTRaOwpv2X+AP=cM1Q_g@mail.gmail.com' \ --to=robh@kernel.org \ --cc=Laurent.pinchart@ideasonboard.com \ --cc=a.hajda@samsung.com \ --cc=airlied@linux.ie \ --cc=bjorn.andersson@linaro.org \ --cc=daniel@ffwll.ch \ --cc=devicetree@vger.kernel.org \ --cc=dianders@chromium.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=jonas@kwiboo.se \ --cc=linus.walleij@linaro.org \ --cc=linux-arm-msm@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lyude@redhat.com \ --cc=maarten.lankhorst@linux.intel.com \ --cc=narmstrong@baylibre.com \ --cc=robdclark@chromium.org \ --cc=sam@ravnborg.org \ --cc=stanislav.lisovskiy@intel.com \ --cc=steev@kali.org \ --cc=swboyd@chromium.org \ --cc=treding@nvidia.com \ /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: linkBe 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.