| Message ID | 20200917055210.22868-1-tomi.valkeinen@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PATCHv2] dt-bindings: dp-connector: add binding for DisplayPort connector | expand |
On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote: > Add binding for DisplayPort connector. A few notes: > > * Similar to hdmi-connector, it has hpd-gpios as an optional property, > as the HPD could also be handled by, e.g., the DP bridge. > > * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it > is not strictly required: standard DP cables do not even have the pin > connected. > > * Connector type. Full size and mini connectors are identical except for > the connector size and form, so I believe there is no functional need > for this property. But similar to 'label' property, it might be used > to present information about the connector to the userspace. > > * No eDP. There's really no "eDP connector", as it's always a custom > made connection between the DP and the DP panel. So possibly there is > no need for edp-connector binding, but even if there is, I don't want > to guess what it could look like, and could it be part of the > dp-connector binding. > > * No DP++. I'm not familiar with DP++, but I think it's all handled by > the DP bridge, and does not need any new properties to the dp-connector. You might need an i2c bus for this. It's up to the source device to either hook up just AUX CH, or both AUX CH and DDC to a DP++ connector. If just AUX CH is wired up you are limited to using only type2 DP dual mode adapters, whereas if you also have DDC the crappier type1 adapters will also work. I guess it's possible some bridges might handle all that for you. But eg. on i915 we always set up both AUX CH and DDC, and some extra circuitry on the board will isolate one or the other depending on what kind of dongle/cable gets plugged in (identified via the CONFIG pins).
On 17/09/2020 14:22, Ville Syrjälä wrote: > On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote: >> Add binding for DisplayPort connector. A few notes: >> >> * Similar to hdmi-connector, it has hpd-gpios as an optional property, >> as the HPD could also be handled by, e.g., the DP bridge. >> >> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it >> is not strictly required: standard DP cables do not even have the pin >> connected. >> >> * Connector type. Full size and mini connectors are identical except for >> the connector size and form, so I believe there is no functional need >> for this property. But similar to 'label' property, it might be used >> to present information about the connector to the userspace. >> >> * No eDP. There's really no "eDP connector", as it's always a custom >> made connection between the DP and the DP panel. So possibly there is >> no need for edp-connector binding, but even if there is, I don't want >> to guess what it could look like, and could it be part of the >> dp-connector binding. >> >> * No DP++. I'm not familiar with DP++, but I think it's all handled by >> the DP bridge, and does not need any new properties to the dp-connector. > > You might need an i2c bus for this. It's up to the source device > to either hook up just AUX CH, or both AUX CH and DDC to a DP++ > connector. If just AUX CH is wired up you are limited to using > only type2 DP dual mode adapters, whereas if you also have DDC > the crappier type1 adapters will also work. Ok, thanks for the clarifications on this. > I guess it's possible some bridges might handle all that for you. > But eg. on i915 we always set up both AUX CH and DDC, and some > extra circuitry on the board will isolate one or the other > depending on what kind of dongle/cable gets plugged in > (identified via the CONFIG pins). Is that automatic on i915? I could imagine a gpio-controlled mux doing the isolation, and then we need some driver controlling the gpio. I could add the ddc bus the same way as on hdmi-connector.yaml, but perhaps it's better to leave that for someone with a DP++ board. Afaics, there should be no problems adding this later. Tomi
On Thu, Sep 17, 2020 at 03:39:38PM +0300, Tomi Valkeinen wrote: > On 17/09/2020 14:22, Ville Syrjälä wrote: > > On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote: > >> Add binding for DisplayPort connector. A few notes: > >> > >> * Similar to hdmi-connector, it has hpd-gpios as an optional property, > >> as the HPD could also be handled by, e.g., the DP bridge. > >> > >> * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it > >> is not strictly required: standard DP cables do not even have the pin > >> connected. > >> > >> * Connector type. Full size and mini connectors are identical except for > >> the connector size and form, so I believe there is no functional need > >> for this property. But similar to 'label' property, it might be used > >> to present information about the connector to the userspace. > >> > >> * No eDP. There's really no "eDP connector", as it's always a custom > >> made connection between the DP and the DP panel. So possibly there is > >> no need for edp-connector binding, but even if there is, I don't want > >> to guess what it could look like, and could it be part of the > >> dp-connector binding. > >> > >> * No DP++. I'm not familiar with DP++, but I think it's all handled by > >> the DP bridge, and does not need any new properties to the dp-connector. > > > > You might need an i2c bus for this. It's up to the source device > > to either hook up just AUX CH, or both AUX CH and DDC to a DP++ > > connector. If just AUX CH is wired up you are limited to using > > only type2 DP dual mode adapters, whereas if you also have DDC > > the crappier type1 adapters will also work. > > Ok, thanks for the clarifications on this. > > > I guess it's possible some bridges might handle all that for you. > > But eg. on i915 we always set up both AUX CH and DDC, and some > > extra circuitry on the board will isolate one or the other > > depending on what kind of dongle/cable gets plugged in > > (identified via the CONFIG pins). > > Is that automatic on i915? I could imagine a gpio-controlled mux doing the isolation, and then we > need some driver controlling the gpio. Yeah, we don't even get the state of that pin in the driver. We just blindly probe both DDC and AUX CH. Due to the isolation only one goes through, the other other just times out. > > I could add the ddc bus the same way as on hdmi-connector.yaml, but perhaps it's better to leave > that for someone with a DP++ board. Afaics, there should be no problems adding this later. Another option might be to declare both dp and hdmi connectors for the same physical connector. That's the approach we use for drm_connectors in i915. But dunno if that's a good idea for dt.
On Thu, Sep 17, 2020 at 08:52:10AM +0300, Tomi Valkeinen wrote: > Add binding for DisplayPort connector. A few notes: > > * Similar to hdmi-connector, it has hpd-gpios as an optional property, > as the HPD could also be handled by, e.g., the DP bridge. > > * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it > is not strictly required: standard DP cables do not even have the pin > connected. > > * Connector type. Full size and mini connectors are identical except for > the connector size and form, so I believe there is no functional need > for this property. But similar to 'label' property, it might be used > to present information about the connector to the userspace. > > * No eDP. There's really no "eDP connector", as it's always a custom > made connection between the DP and the DP panel. So possibly there is > no need for edp-connector binding, but even if there is, I don't want > to guess what it could look like, and could it be part of the > dp-connector binding. I don't think that's true. Do an image search for 'edp pinout'. AFAICT, there's 2 lane 30 pin and 4 lane 40 pin. One image says 'Table 5-3 in eDP v1.2'. Of course, I'm sure there's custom ones too. From a binding perspective, we probably don't care about the differences, but just need to be able to describe HPD, backlight power, enable, and pwm, and LCD power. That said, it's fine to not handle eDP here. > > * No DP++. I'm not familiar with DP++, but I think it's all handled by > the DP bridge, and does not need any new properties to the dp-connector. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> > --- > > Changes in v2: Add connector type. > > > .../display/connector/dp-connector.yaml | 55 +++++++++++++++++++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/connector/dp-connector.yaml > > diff --git a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml > new file mode 100644 > index 000000000000..b5fc3e52899e > --- /dev/null > +++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml > @@ -0,0 +1,55 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/display/connector/dp-connector.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: DisplayPort Connector > + > +maintainers: > + - Tomi Valkeinen <tomi.valkeinen@ti.com> > + > +properties: > + compatible: > + const: dp-connector > + > + label: true > + > + type: > + enum: > + - full-size > + - mini > + > + hpd-gpios: > + description: A GPIO line connected to HPD > + maxItems: 1 > + > + dp-pwr-supply: > + description: Power supply for the DP_PWR pin > + maxItems: 1 > + > + port: > + description: Connection to controller providing DP signals > + > +required: > + - compatible > + - type > + - port > + > +additionalProperties: false > + > +examples: > + - | > + connector { > + compatible = "dp-connector"; > + label = "dp0"; > + type = "full-size"; > + > + port { > + dp_connector_in: endpoint { > + remote-endpoint = <&dp_out>; > + }; > + }; > + }; > + > +... > -- > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. > Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >
Hi Rob, On 23/09/2020 19:17, Rob Herring wrote: >> * No eDP. There's really no "eDP connector", as it's always a custom >> made connection between the DP and the DP panel. So possibly there is >> no need for edp-connector binding, but even if there is, I don't want >> to guess what it could look like, and could it be part of the >> dp-connector binding. > > I don't think that's true. Do an image search for 'edp pinout'. AFAICT, > there's 2 lane 30 pin and 4 lane 40 pin. One image says 'Table 5-3 in > eDP v1.2'. Of course, I'm sure there's custom ones too. From a binding > perspective, we probably don't care about the differences, but just need > to be able to describe HPD, backlight power, enable, and pwm, and LCD > power. That's true. The eDP spec lists 4 different standard pinouts (how strictly those are followed, I have no idea). But it does not define a connector or a cable. And afaik eDP is defined to be not user-detachable. I think from the binding perspective the connectors present in the dts files are user-visible connectors, meant for plugging in and out. The connector node is the "end of the chain". And non user-detachable ones (like MIPI DPI) do not have a connector in the dts, but just the video source and the panel linked together, and the panel is the end of the chain. My thinking was that eDP is similar to MIPI DPI, and that we always define the eDP panel in the dts too. But I guess that might not be the case, as eDP does have all the bells and whistles to fully detect the panel. Although can it do all the probing needed for backlight and touch... And even then, should we have a generic-epd-panel present in the dts, or just a connector... I don't know. So as I said, I'd rather leave eDP out for now (and you agreed, so no disagreement =). I think we can later extend this binding, or if eDP just doesn't seem to fit into this, we can create a fully separate binding for eDP. Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On Wed, Sep 23, 2020 at 11:15 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: > > Hi Rob, > > On 23/09/2020 19:17, Rob Herring wrote: > > >> * No eDP. There's really no "eDP connector", as it's always a custom > >> made connection between the DP and the DP panel. So possibly there is > >> no need for edp-connector binding, but even if there is, I don't want > >> to guess what it could look like, and could it be part of the > >> dp-connector binding. > > > > I don't think that's true. Do an image search for 'edp pinout'. AFAICT, > > there's 2 lane 30 pin and 4 lane 40 pin. One image says 'Table 5-3 in > > eDP v1.2'. Of course, I'm sure there's custom ones too. From a binding > > perspective, we probably don't care about the differences, but just need > > to be able to describe HPD, backlight power, enable, and pwm, and LCD > > power. > > That's true. The eDP spec lists 4 different standard pinouts (how > strictly those are followed, I have no idea). But it does not define a > connector or a cable. And afaik eDP is defined to be not user-detachable. Yes, but HPD is still used (or sometimes broken). We could just put that all in panel nodes, but IIRC the last time this came up the issue was handling devices with different panels stuffed by the manufacturer. An eDP connector binding would be one way to handle that as it is somewhat standardized while panel connections aren't at all. Rob
On 23/09/2020 23:00, Rob Herring wrote: > On Wed, Sep 23, 2020 at 11:15 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote: >> >> Hi Rob, >> >> On 23/09/2020 19:17, Rob Herring wrote: >> >>>> * No eDP. There's really no "eDP connector", as it's always a custom >>>> made connection between the DP and the DP panel. So possibly there is >>>> no need for edp-connector binding, but even if there is, I don't want >>>> to guess what it could look like, and could it be part of the >>>> dp-connector binding. >>> >>> I don't think that's true. Do an image search for 'edp pinout'. AFAICT, >>> there's 2 lane 30 pin and 4 lane 40 pin. One image says 'Table 5-3 in >>> eDP v1.2'. Of course, I'm sure there's custom ones too. From a binding >>> perspective, we probably don't care about the differences, but just need >>> to be able to describe HPD, backlight power, enable, and pwm, and LCD >>> power. >> >> That's true. The eDP spec lists 4 different standard pinouts (how >> strictly those are followed, I have no idea). But it does not define a >> connector or a cable. And afaik eDP is defined to be not user-detachable. > > Yes, but HPD is still used (or sometimes broken). We could just put > that all in panel nodes, but IIRC the last time this came up the issue > was handling devices with different panels stuffed by the > manufacturer. An eDP connector binding would be one way to handle that > as it is somewhat standardized while panel connections aren't at all. HPD in DisplayPort, and especially in eDP, is not strictly speaking "cable inserted or removed", but rather signaling that the monitor/panel is ready (e.g. after powering it up), or there has been a link issue, or there has been a major change in settings, or signaling DP interrupt, etc. And HPD (and EDID and some other things) are optional with eDP. I don't think those rule out an edp-connector, but just things to consider. Tomi
diff --git a/Documentation/devicetree/bindings/display/connector/dp-connector.yaml b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml new file mode 100644 index 000000000000..b5fc3e52899e --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/dp-connector.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/connector/dp-connector.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DisplayPort Connector + +maintainers: + - Tomi Valkeinen <tomi.valkeinen@ti.com> + +properties: + compatible: + const: dp-connector + + label: true + + type: + enum: + - full-size + - mini + + hpd-gpios: + description: A GPIO line connected to HPD + maxItems: 1 + + dp-pwr-supply: + description: Power supply for the DP_PWR pin + maxItems: 1 + + port: + description: Connection to controller providing DP signals + +required: + - compatible + - type + - port + +additionalProperties: false + +examples: + - | + connector { + compatible = "dp-connector"; + label = "dp0"; + type = "full-size"; + + port { + dp_connector_in: endpoint { + remote-endpoint = <&dp_out>; + }; + }; + }; + +...
Add binding for DisplayPort connector. A few notes: * Similar to hdmi-connector, it has hpd-gpios as an optional property, as the HPD could also be handled by, e.g., the DP bridge. * dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it is not strictly required: standard DP cables do not even have the pin connected. * Connector type. Full size and mini connectors are identical except for the connector size and form, so I believe there is no functional need for this property. But similar to 'label' property, it might be used to present information about the connector to the userspace. * No eDP. There's really no "eDP connector", as it's always a custom made connection between the DP and the DP panel. So possibly there is no need for edp-connector binding, but even if there is, I don't want to guess what it could look like, and could it be part of the dp-connector binding. * No DP++. I'm not familiar with DP++, but I think it's all handled by the DP bridge, and does not need any new properties to the dp-connector. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> --- Changes in v2: Add connector type. .../display/connector/dp-connector.yaml | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/connector/dp-connector.yaml