| Message ID | 20230903214150.2877023-1-dmitry.baryshkov@linaro.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm,usb/typec: uABI for USB-C DisplayPort connectors | expand |
On Mon, Sep 04, 2023 at 12:41:38AM +0300, Dmitry Baryshkov wrote: > During the discussion regarding DisplayPort wrapped in the USB-C > connectors (via the USB-C altmode) it was pointed out that currently > there is no good way to let userspace know if the DRM connector in > question is the 'native' DP connector or if it is the USB-C connector. > > An attempt to use DRM_MODE_CONNECTOR_USB for such connectors was > declined, as existing DP drivers (i915, AMD) use > DRM_MODE_CONNECTOR_DisplayPort. New drivers should behave in the same > way. > Sorry, didn't see the commit message before posting my complaint about USB -> DisplayPort. > An attempt to use subconnector property was also declined. It is defined > to the type of the DP dongle connector rather than the host connector. > > This attempt targets reusing the connector's PATH property. Currently > this property is only used for the DP MST connectors. This patchset > reuses it to point out to the corresponding registered typec port > device. > Still interested in understanding how the path string should look like. Is the path expected to be consumed by machine, or is it only there for human convenience? Regards, Bjorn
On 04/09/2023 18:46, Bjorn Andersson wrote: > On Mon, Sep 04, 2023 at 12:41:38AM +0300, Dmitry Baryshkov wrote: >> During the discussion regarding DisplayPort wrapped in the USB-C >> connectors (via the USB-C altmode) it was pointed out that currently >> there is no good way to let userspace know if the DRM connector in >> question is the 'native' DP connector or if it is the USB-C connector. >> >> An attempt to use DRM_MODE_CONNECTOR_USB for such connectors was >> declined, as existing DP drivers (i915, AMD) use >> DRM_MODE_CONNECTOR_DisplayPort. New drivers should behave in the same >> way. >> > > Sorry, didn't see the commit message before posting my complaint about > USB -> DisplayPort. > >> An attempt to use subconnector property was also declined. It is defined >> to the type of the DP dongle connector rather than the host connector. >> >> This attempt targets reusing the connector's PATH property. Currently >> this property is only used for the DP MST connectors. This patchset >> reuses it to point out to the corresponding registered typec port >> device. >> > > Still interested in understanding how the path string should look like. As wrote in the other letter, on RB5 it is 'typec:port0'. If the machine has two Type-C ports and two connected DP blocks, one of them will have 'typec:port0', another one 'typec:port1'. This way one can further look under /sys/class/typec/portN/physical_localtion/ and find corresponding location, etc. > Is the path expected to be consumed by machine, or is it only there for > human convenience? As with DP MST it is expected that userspace will consume this information, possibly renaming the connector. For example, on my laptop I have DP-1, ... DP-5 connectors (with DP-2 -- DP-5 being DP MST ones). Xorg renames them to DP-1, DP-2, DP-1-1, DP-1-2, DP-1-3, because the MST ones are branches for the DP-1.
During the discussion regarding DisplayPort wrapped in the USB-C connectors (via the USB-C altmode) it was pointed out that currently there is no good way to let userspace know if the DRM connector in question is the 'native' DP connector or if it is the USB-C connector. An attempt to use DRM_MODE_CONNECTOR_USB for such connectors was declined, as existing DP drivers (i915, AMD) use DRM_MODE_CONNECTOR_DisplayPort. New drivers should behave in the same way. An attempt to use subconnector property was also declined. It is defined to the type of the DP dongle connector rather than the host connector. This attempt targets reusing the connector's PATH property. Currently this property is only used for the DP MST connectors. This patchset reuses it to point out to the corresponding registered typec port device. Dmitry Baryshkov (12): Revert "drm/sysfs: Link DRM connectors to corresponding Type-C connectors" drm/sysfs: link DRM connector device to the connector's fw nodes drm/connector: extend PATH property to covert Type-C case drm/bridge-connector: set the PATH property for the connector drm/bridge: remove conditionals around devicetree pointers soc: qcom: pmic_glink_altmode: fix DRM connector type soc: qcom: pmic_glink_altmode: report that this is a Type-C connector usb: typec: support generating Type-C port names for userspace usb: typec: tcpm: support generating Type-C port names for userspace usb: typec: qcom: implement proper error path in probe() usb: typec: qcom: extract DRM bridge functionality to separate file usb: typec: qcom: define the bridge's path drivers/gpu/drm/bridge/panel.c | 2 - drivers/gpu/drm/drm_bridge_connector.c | 14 ++++- drivers/gpu/drm/drm_connector.c | 10 +++- drivers/gpu/drm/drm_sysfs.c | 42 +------------- drivers/soc/qcom/pmic_glink_altmode.c | 3 +- drivers/usb/typec/class.c | 14 +++++ drivers/usb/typec/tcpm/qcom/Makefile | 4 ++ drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 56 ++++++------------- .../usb/typec/tcpm/qcom/qcom_pmic_typec_drm.c | 40 +++++++++++++ .../usb/typec/tcpm/qcom/qcom_pmic_typec_drm.h | 22 ++++++++ drivers/usb/typec/tcpm/tcpm.c | 14 +++++ include/drm/drm_bridge.h | 9 ++- include/linux/usb/tcpm.h | 2 + include/linux/usb/typec.h | 2 + 14 files changed, 146 insertions(+), 88 deletions(-) create mode 100644 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_drm.c create mode 100644 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_drm.h