| Message ID | 20210524165920.v8.2.Id3c048d22e72a9f90084a543b5b4e3f43bc9ab62@changeid |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
| Series | drm: Fix EDID reading on ti-sn65dsi86 by introducing the DP AUX bus | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | warning | total: 0 errors, 1 warnings, 37 lines checked |
| robh/dt-meta-schema | success | |
| robh/dtbs-check | success |
On Mon, 24 May 2021 17:01:50 -0700, Douglas Anderson wrote: > We want to be able to list an eDP panel as a child of an eDP > controller node to represent the fact that the panel is connected to > the controller's DP AUX bus. Though the panel and the controller 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: historically eDP panels were _not_ listed under their controller > but were listed at the top level of the device tree. This will still > be supported for backward compatibility (and while DP controller > drivers are adapted to support the new DT syntax) but should be > considered deprecated since there is no downside to listing the panel > under the controller. > > For now, the DP AUX bus bindings will only support an eDP panel > underneath. It's possible it could be extended to allow having a DP > connector under it in the future. > > 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> > --- > My DT yaml-fu is still weak. If I did something stupid, please help me > learn how to do this better! > > NOTE: there is no "Example" in this bindings file. Yikes! This is > because I wanted to keep this patch separate from the one that enables > the first eDP controller. See the patch ("dt-bindings: drm/aux-bus: > Add an example") for the example. > > ALSO: if anyone else would like to be listed as a "Maintainer" in this > file then please shout! > > Changes in v8: > - Separate DP AUX bus binding is new for v8. > > .../bindings/display/dp-aux-bus.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/dp-aux-bus.yaml > Reviewed-by: Rob Herring <robh@kernel.org>
diff --git a/Documentation/devicetree/bindings/display/dp-aux-bus.yaml b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml new file mode 100644 index 000000000000..5e4afe9f98fb --- /dev/null +++ b/Documentation/devicetree/bindings/display/dp-aux-bus.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/dp-aux-bus.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DisplayPort AUX bus + +maintainers: + - Douglas Anderson <dianders@chromium.org> + +description: + DisplayPort controllers provide a control channel to the sinks that + are hooked up to them. This is the DP AUX bus. Over the DP AUX bus + we can query properties about a sink and also configure it. In + particular, DP sinks support DDC over DP AUX which allows tunneling + a standard I2C DDC connection over the AUX channel. + + To model this relationship, DP sinks should be placed as children + of the DP controller under the "aux-bus" node. + + At the moment, this binding only handles the eDP case. It is + possible it will be extended in the future to handle the DP case. + For DP, presumably a connector would be listed under the DP AUX + bus instead of a panel. + +properties: + $nodename: + const: "aux-bus" + + panel: + $ref: panel/panel-common.yaml# + +additionalProperties: false + +required: + - panel
We want to be able to list an eDP panel as a child of an eDP controller node to represent the fact that the panel is connected to the controller's DP AUX bus. Though the panel and the controller 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: historically eDP panels were _not_ listed under their controller but were listed at the top level of the device tree. This will still be supported for backward compatibility (and while DP controller drivers are adapted to support the new DT syntax) but should be considered deprecated since there is no downside to listing the panel under the controller. For now, the DP AUX bus bindings will only support an eDP panel underneath. It's possible it could be extended to allow having a DP connector under it in the future. 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> --- My DT yaml-fu is still weak. If I did something stupid, please help me learn how to do this better! NOTE: there is no "Example" in this bindings file. Yikes! This is because I wanted to keep this patch separate from the one that enables the first eDP controller. See the patch ("dt-bindings: drm/aux-bus: Add an example") for the example. ALSO: if anyone else would like to be listed as a "Maintainer" in this file then please shout! Changes in v8: - Separate DP AUX bus binding is new for v8. .../bindings/display/dp-aux-bus.yaml | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/dp-aux-bus.yaml