| Message ID | 20240901040658.157425-1-swboyd@chromium.org |
|---|---|
| Headers | show |
| Series | platform/chrome: Add DT USB/DP muxing/topology support | expand |
On Sat, Aug 31, 2024 at 09:06:41PM -0700, Stephen Boyd wrote: > Ease driver development by adding stubs for the typec_switch APIs when > CONFIG_TYPEC=n. Copy the same method used for the typec_mux APIs to be > consistent. > > Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > Cc: <linux-usb@vger.kernel.org> > Cc: Pin-yen Lin <treapking@chromium.org> > Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> > --- > include/linux/usb/typec_mux.h | 43 +++++++++++++++++++++++++++++++---- > 1 file changed, 38 insertions(+), 5 deletions(-) > > diff --git a/include/linux/usb/typec_mux.h b/include/linux/usb/typec_mux.h > index 2489a7857d8e..efb5ed32b813 100644 > --- a/include/linux/usb/typec_mux.h > +++ b/include/linux/usb/typec_mux.h > @@ -3,6 +3,7 @@ > #ifndef __USB_TYPEC_MUX > #define __USB_TYPEC_MUX > > +#include <linux/err.h> > #include <linux/property.h> > #include <linux/usb/typec.h> > > @@ -24,16 +25,13 @@ struct typec_switch_desc { > void *drvdata; > }; > > +#if IS_ENABLED(CONFIG_TYPEC) > + > struct typec_switch *fwnode_typec_switch_get(struct fwnode_handle *fwnode); > void typec_switch_put(struct typec_switch *sw); > int typec_switch_set(struct typec_switch *sw, > enum typec_orientation orientation); > > -static inline struct typec_switch *typec_switch_get(struct device *dev) > -{ > - return fwnode_typec_switch_get(dev_fwnode(dev)); > -} > - > struct typec_switch_dev * > typec_switch_register(struct device *parent, > const struct typec_switch_desc *desc); > @@ -42,6 +40,41 @@ void typec_switch_unregister(struct typec_switch_dev *sw); > void typec_switch_set_drvdata(struct typec_switch_dev *sw, void *data); > void *typec_switch_get_drvdata(struct typec_switch_dev *sw); > > +#else > + > +static inline struct typec_switch * > +fwnode_typec_switch_get(struct fwnode_handle *fwnode) > +{ > + return NULL; > +} > +static inline void typec_switch_put(struct typec_switch *sw) {} > +static inline int typec_switch_set(struct typec_switch *sw, > + enum typec_orientation orientation) > +{ > + return 0; > +} > + > +static inline struct typec_switch_dev * > +typec_switch_register(struct device *parent, > + const struct typec_switch_desc *desc) > +{ > + return ERR_PTR(-EOPNOTSUPP); > +} > +static inline void typec_switch_unregister(struct typec_switch_dev *sw) {} > + > +static inline void typec_switch_set_drvdata(struct typec_switch_dev *sw, void *data) {} > +static inline void *typec_switch_get_drvdata(struct typec_switch_dev *sw) > +{ > + return ERR_PTR(-EOPNOTSUPP); > +} > + > +#endif /* CONFIG_TYPEC */ > + > +static inline struct typec_switch *typec_switch_get(struct device *dev) > +{ > + return fwnode_typec_switch_get(dev_fwnode(dev)); > +} > + > struct typec_mux_state { > struct typec_altmode *alt; > unsigned long mode;
On Sat, 31 Aug 2024, Stephen Boyd wrote: > Add a DT graph binding to google,cros-ec-typec so that it can combine > DisplayPort (DP) and USB SuperSpeed (SS) data into a USB type-c endpoint > that is connected to the usb-c-connector node's SS endpoint. This also > allows us to connect the DP and USB nodes in the graph to the USB type-c > connectors, providing the full picture of the USB type-c data flows in > the system. > > Allow there to be multiple typec nodes underneath the EC node so that > one DT graph exists per DP bridge. The EC is actually controlling TCPCs > and redrivers that combine the DP and USB signals together so this more > accurately reflects the hardware design without introducing yet another > DT node underneath the EC for USB type-c. > > If the type-c ports are being shared between a single DP controller then > the ports need to know about each other and determine a policy to drive > DP to one type-c port. If the type-c ports each have their own dedicated > DP controller then they're able to operate independently and enter/exit > DP altmode independently as well. We can't connect the DP controller's > endpoint to one usb-c-connector port@1 endpoint and the USB controller's > endpoint to another usb-c-connector port@1 endpoint either because the > DP muxing case would have DP connected to two usb-c-connector endpoints > which the graph binding doesn't support. > > Therefore, one typec node is required per the capabilities of the type-c > port(s) being managed. This also lets us indicate which type-c ports the > DP controller is wired to. For example, if DP was connected to ports 0 > and 2, while port 1 was connected to another DP controller we wouldn't > be able to implement that without having some other DT property to > indicate which output ports are connected to the DP endpoint. > > Reviewed-by: Rob Herring (Arm) <robh@kernel.org> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> > Cc: Conor Dooley <conor+dt@kernel.org> > Acked-by: Lee Jones <lee@kernel.org> > Cc: Benson Leung <bleung@chromium.org> > Cc: Guenter Roeck <groeck@chromium.org> > Cc: Prashant Malani <pmalani@chromium.org> > Cc: Tzung-Bi Shih <tzungbi@kernel.org> > Cc: <devicetree@vger.kernel.org> > Cc: <chrome-platform@lists.linux.dev> > Cc: Pin-yen Lin <treapking@chromium.org> > Signed-off-by: Stephen Boyd <swboyd@chromium.org> > --- > .../bindings/mfd/google,cros-ec.yaml | 7 +- Acked-by: Lee Jones <lee@kernel.org> > .../bindings/usb/google,cros-ec-typec.yaml | 229 ++++++++++++++++++ > 2 files changed, 233 insertions(+), 3 deletions(-)
Quoting Andy Shevchenko (2024-09-02 04:12:49) > On Sat, Aug 31, 2024 at 09:06:49PM -0700, Stephen Boyd wrote: > > Is it possible to move these Cc:s after --- line below? Ok. > > > /** > > * devcon_match_fn_t - device connection match function > > * @fwnode: Remote connection's device node > > + * @endpoint: Remote connection's endpoint node > > * @con_id: Identifier for the connection > > * @data: Match function caller specific data > > * > > * Implement a callback with this function signature to search a fwnode's > > * connections for a match with a function like device_connection_find_match(). > > * This function will be called possibly multiple times, once for each > > - * connection. The match function should inspect the @fwnode to look for a > > - * match. The @con_id and @data provided are the same as the @con_id and @data > > - * arguments passed to the functions that take a devcon_match_fn_t argument. > > + * connection. The match function should inspect the connection's @fwnode > > + * and/or @endpoint to look for a match. The @con_id and @data provided are the > > + * same as the @con_id and @data arguments passed to the functions that take a > > + * devcon_match_fn_t argument. > > So, struct fwnode_handle is a single-linked list. Can we utilise that instead > of adding a new parameter? I.o.w. do those objects (@fwnode and @endpoint) have > anything in common and can be chained? No, we can't use that. We need to know which endpoint in the remote fwnode is connected to the fwnode we're searching from. This is how we know which typec mux structure is associated with which type-c port so we can drive DP there. We might have two endpoints connected to the same fwnode and then we wouldn't be able to differentiate the endpoint and the typec mux to configure. > > > * Note: This function can be called multiple times. > > What does this mean? Is it idempotent? Or what is the effect of being called > multiple times? I've removed this note now.
On Sat, Aug 31, 2024 at 09:06:55PM -0700, Stephen Boyd wrote: > Most ARM based chromebooks with two usb-c-connector nodes and one DP > controller are muxing the DP lanes between the two USB ports. This is > done so that the type-c ports are at least equal in capability if not > functionality. Either an analog mux is used to steer the DP signal to > one or the other port, or a DP bridge chip has two lanes (e.g. DP > ML0/ML1) wired to one type-c port while the other two (e.g. DP ML2/ML3) > are wired to another type-c port. > > [...] > > Cc: Prashant Malani <pmalani@chromium.org> > Cc: Benson Leung <bleung@chromium.org> > Cc: Tzung-Bi Shih <tzungbi@kernel.org> > Cc: <chrome-platform@lists.linux.dev> > Cc: Pin-yen Lin <treapking@chromium.org> > Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
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. Type-c core patches: These add some devm helpers so that the next patches in the series can skip open-coding devres helpers for unregistering typec switches and muxes. 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. It also registers a typec mux and switch (if applicable) so that the DP altmode pin assignment and port orientation can be passed to the switch callbacks. We'll still need to implement logic in the phy layer to handle configuration. 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. Changes from v3: https://lore.kernel.org/r/20240819223834.2049862-1-swboyd@chromium.org * Use devm_add_action_or_reset() for typec patches * Fix kernel-doc * Document devcon_match_fn_t before extending it * Include err.h in typec header * Document devm_typec_switch_register() * Remove struct cros_typec_dp_bridge and fold it into parent * Drop unevaluatedProperties in some places * Change name of registered typec switches to include dev_name of parent to avoid collisions Changes from v2: https://lore.kernel.org/r/20240815003417.1175506-1-swboyd@chromium.org * Move most of the binding bits to usb-switch.yaml * Move google,cros-ec-typec binding to usb/ * Implement mode-switch and orientation-switch typec controls in drm_dp_typec_bridge driver * Get rid of public APIs that would be used to assign pins or orientation of the port * Add devm helpers for typec mux and switch registration * Add a way to match fwnodes while walking the graph based on the endpoint 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 (18): drm/atomic-helper: Introduce lane remapping support to bridges drm/bridge: Verify lane assignment is going to work during atomic_check usb: typec: Stub out typec_switch APIs when CONFIG_TYPEC=n usb: typec: Add device managed typec_mux_register() usb: typec: Add device managed typec_switch_register() 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 devcon property: Document devcon_match_fn_t device property: Add remote endpoint to devcon matcher dt-bindings: usb-switch: Extract endpoints to defs dt-bindings: usb-switch: Extend for DisplayPort altmode dt-bindings: Move google,cros-ec-typec binding to usb dt-bindings: usb: 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 platform/chrome: cros_ec_typec: Handle lack of HPD information .../bindings/chrome/google,cros-ec-typec.yaml | 66 -- .../bindings/mfd/google,cros-ec.yaml | 7 +- .../bindings/usb/google,cros-ec-typec.yaml | 295 +++++++++ .../devicetree/bindings/usb/usb-switch.yaml | 163 ++++- drivers/base/property.c | 7 +- drivers/gpu/drm/bridge/aux-hpd-bridge.c | 575 +++++++++++++++++- drivers/gpu/drm/drm_atomic_state_helper.c | 2 + drivers/gpu/drm/drm_bridge.c | 51 ++ drivers/platform/chrome/Kconfig | 1 + drivers/platform/chrome/cros_ec_typec.c | 136 ++++- drivers/platform/chrome/cros_ec_typec.h | 4 + drivers/usb/roles/class.c | 4 +- drivers/usb/typec/mux.c | 79 +++ drivers/usb/typec/retimer.c | 7 +- include/drm/bridge/aux-bridge.h | 26 + include/drm/drm_atomic.h | 31 + include/drm/drm_bridge.h | 4 + include/linux/property.h | 24 +- include/linux/usb/typec_mux.h | 59 +- 19 files changed, 1433 insertions(+), 108 deletions(-) delete mode 100644 Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml create mode 100644 Documentation/devicetree/bindings/usb/google,cros-ec-typec.yaml base-commit: 8400291e289ee6b2bf9779ff1c83a291501f017b