| Message ID | 20240815003417.1175506-1-swboyd@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | platform/chrome: Add DT USB/DP muxing/topology support | expand |
Quoting Stephen Boyd (2024-08-14 17:34:05) > > I'm thinking of working in changes so that the drm_dp_typec_bridge > registers a 'struct typec_mux_dev' as well. If that is done then we can > register a drm_dp_typec_bridge from the port manager and let the type-c > framework drive the pin assignment and orientation directly instead of > calling it from the port manager layer. To get there I need to add the > ability for a 'struct typec_mux_dev' to associate with more than one > typec_port (technically already done) and then make sure that the > cros_ec_typec driver doesn't try to enable DP altmode on the type-c port > that isn't muxed for DP. I'm working on this now but I'm sending this > out to get some feedback because I've reached a good stopping place. > I've done this now, and it works well. I've extended the usb-switch.yaml file to support a third graph endpoint for DP. And I've moved the hpd notifying and lane remapping to be internal to the drm_dp_typec_bridge code so that any device that registers the auxiliary device can follow the usb-switch binding and connect the endpoint to the usb-c-connector to get hpd notifications and pin assignment basically for free. I'll send a v3 next week.
This series adds support for fully describing the USB/DP topology on ChromeOS Trogdor devices in DT. Trogdor devices have a single DP phy in the AP that is muxed to one of two usb type-c connectors depending on which port asserts HPD first to the EC. We'd like to know which port is connected to an external monitor to provide a better experience to the user about things like which type-c port is displaying DP or which type-c hub is acting up, etc. Describing the connection all the way from the source to the connector will allow us to do this. DRM core patches: These are used to implement lane assignment for DP altmode configurations through the drm_bridge code. The typec code will use this to tell the DP phy how many lanes of DP to drive and which lanes to drive out to the USB type-c connector. Adding support for lane assignment allows us to implement DP muxing as well, physically splitting the DP lanes on the DP phy so that hardware doesn't have to use an analog mux to steer two DP lanes to one or the other type-c port. DRM aux hpd patches: These implement an auxiliary device for USB type-c DP alternate mode. I took Dmitry's suggestion and moved the code that does the remapping into this driver. The existing hpd bridge is wrapped so as to avoid changing the current users. Cros EC typec patches: This ties together everything that comes before it in this series. The EC typec driver registers the drm_dp_typec_bridge that can signal HPD from the type-c connector through the bridge chain, mux the DP phy in software so that we don't have to use an analog mux, and implement orientation control for boards like Kukui that directly connect the DP phy to the type-c port, necessitating lane assignment to flip the lanes to match the cable orientation. I'm thinking of working in changes so that the drm_dp_typec_bridge registers a 'struct typec_mux_dev' as well. If that is done then we can register a drm_dp_typec_bridge from the port manager and let the type-c framework drive the pin assignment and orientation directly instead of calling it from the port manager layer. To get there I need to add the ability for a 'struct typec_mux_dev' to associate with more than one typec_port (technically already done) and then make sure that the cros_ec_typec driver doesn't try to enable DP altmode on the type-c port that isn't muxed for DP. I'm working on this now but I'm sending this out to get some feedback because I've reached a good stopping place. Changes from v1: https://lore.kernel.org/r/20240210070934.2549994-1-swboyd@chromium.org * Too many to count! * Split out the DRM bits into this series * Moved the logic into dp-aux-hpd bridge driver * Drive the bridge from cros_ec_typec driver instead of globbing onto the ACPI centric cros-typec-switch driver * During that process drop a lot of patches that aren't needed anymore * Move the DT graph and other properties to the cros-ec-typec binding * Skip mode-switch/orientation-switch properties because we're not registering typec structs anymore Stephen Boyd (11): drm/atomic-helper: Introduce lane remapping support to bridges drm/bridge: Verify lane assignment is going to work during atomic_check drm/bridge: aux-hpd: Support USB Type-C DP altmodes via DRM lane assignment drm/bridge: dp_typec: Support USB Type-C orientation drm/bridge: dp_typec: Add "no-hpd" support drm/bridge: dp_typec: Allow users to hook hpd notify path dt-bindings: chrome: Add ports to google,cros-ec-typec for DP altmode platform/chrome: cros_ec_typec: Add support for signaling DP HPD via drm_bridge platform/chrome: cros_ec_typec: Support DP muxing via DRM lane assignment platform/chrome: cros_ec_typec: Support DP orientation platform/chrome: cros_ec_typec: Handle lack of HPD information .../bindings/chrome/google,cros-ec-typec.yaml | 260 +++++++++++++ .../bindings/mfd/google,cros-ec.yaml | 7 +- drivers/gpu/drm/bridge/aux-hpd-bridge.c | 368 +++++++++++++++++- drivers/gpu/drm/drm_atomic_state_helper.c | 2 + drivers/gpu/drm/drm_bridge.c | 50 +++ drivers/platform/chrome/Kconfig | 1 + drivers/platform/chrome/cros_ec_typec.c | 208 +++++++++- drivers/platform/chrome/cros_ec_typec.h | 8 +- include/drm/bridge/aux-bridge.h | 62 +++ include/drm/drm_atomic.h | 31 ++ include/drm/drm_bridge.h | 4 + 11 files changed, 983 insertions(+), 18 deletions(-) base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b