* [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support
@ 2024-08-15 0:34 Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 01/11] drm/atomic-helper: Introduce lane remapping support to bridges Stephen Boyd
` (11 more replies)
0 siblings, 12 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
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
--
https://chromeos.dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v2 01/11] drm/atomic-helper: Introduce lane remapping support to bridges
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 02/11] drm/bridge: Verify lane assignment is going to work during atomic_check Stephen Boyd
` (10 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
Add support to the DRM atomic logic to support lane remapping between
bridges, encoders and connectors. Typically lane mapping is handled
statically in firmware, e.g. on DT we use the data-lanes property to
assign lanes when connecting display bridges. Lane assignment is dynamic
with USB-C DisplayPort altmodes, e.g. pin conf D assigns 2 lanes of DP
to pins on the USB-C connector while pin conf C assigns 4 lanes of DP to
pins on the USB-C connector. The lane assignment can't be set statically
because the DP altmode repurposes USB-C pins for the DP lanes while also
limiting the number of DP lanes or their pin assignment at runtime.
Bridge drivers should point their 'struct drm_bus_cfg::lanes' pointer to
an allocated array of 'struct drm_lane_cfg' structures and indicate the
size of this allocated array with 'struct drm_bus_cfg::num_lanes' in
their atomic_check() callback. The previous bridge in the bridge chain
can look at this information by calling
drm_bridge_next_bridge_lane_cfg() in their atomic_check() callback to
figure out what lanes need to be logically assigned to the physical
output lanes to satisfy the next bridge's lane assignment.
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Robert Foss <rfoss@kernel.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: <dri-devel@lists.freedesktop.org>
Cc: Pin-yen Lin <treapking@chromium.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 2 ++
drivers/gpu/drm/drm_bridge.c | 34 +++++++++++++++++++++++
include/drm/drm_atomic.h | 31 +++++++++++++++++++++
include/drm/drm_bridge.h | 4 +++
4 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index 519228eb1095..12d574458e7b 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -779,6 +779,8 @@ EXPORT_SYMBOL(drm_atomic_helper_bridge_duplicate_state);
void drm_atomic_helper_bridge_destroy_state(struct drm_bridge *bridge,
struct drm_bridge_state *state)
{
+ kfree(state->input_bus_cfg.lanes);
+ kfree(state->output_bus_cfg.lanes);
kfree(state);
}
EXPORT_SYMBOL(drm_atomic_helper_bridge_destroy_state);
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index d44f055dbe3e..bd18c1e91dee 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -822,6 +822,40 @@ void drm_atomic_bridge_chain_enable(struct drm_bridge *bridge,
}
EXPORT_SYMBOL(drm_atomic_bridge_chain_enable);
+/**
+ * drm_bridge_next_bridge_lane_cfg - get the lane configuration of the next bridge
+ * @bridge: bridge control structure
+ * @state: new atomic state
+ * @num_lanes: will contain the size of the returned array
+ *
+ * This function is typically called from &drm_bridge_funcs.atomic_check().
+ * The @bridge driver calls this function to determine what the next bridge in
+ * the bridge chain requires for the physical to logical lane assignments.
+ *
+ * Return: Lane configuration array of size @num_lanes for the next bridge
+ * after @bridge in the bridge chain, or NULL if the lane configuration is
+ * unchanged from the default.
+ */
+const struct drm_lane_cfg *
+drm_bridge_next_bridge_lane_cfg(struct drm_bridge *bridge,
+ struct drm_atomic_state *state,
+ u8 *num_lanes)
+{
+ const struct drm_bridge_state *next_bridge_state;
+ struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
+
+ next_bridge_state = drm_atomic_get_new_bridge_state(state, next_bridge);
+ if (!next_bridge_state) {
+ *num_lanes = 0;
+ return NULL;
+ }
+
+ *num_lanes = next_bridge_state->input_bus_cfg.num_lanes;
+
+ return next_bridge_state->input_bus_cfg.lanes;
+}
+EXPORT_SYMBOL(drm_bridge_next_bridge_lane_cfg);
+
static int drm_atomic_bridge_check(struct drm_bridge *bridge,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index 4d7f4c5f2001..e1a38d0742f1 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -1122,6 +1122,27 @@ drm_atomic_crtc_effectively_active(const struct drm_crtc_state *state)
return state->active || state->self_refresh_active;
}
+/**
+ * struct drm_lane_cfg - lane configuration
+ *
+ * This structure stores the lane configuration of a physical bus between
+ * two components in an output pipeline, usually between two bridges, an
+ * encoder and a bridge, or a bridge and a connector.
+ *
+ * The lane configuration is stored in &drm_bus_cfg.
+ */
+struct drm_lane_cfg {
+ /**
+ * @logical: Logical lane number
+ */
+ u8 logical;
+
+ /**
+ * @inverted: True if lane polarity is inverted, false otherwise
+ */
+ bool inverted;
+};
+
/**
* struct drm_bus_cfg - bus configuration
*
@@ -1152,6 +1173,16 @@ struct drm_bus_cfg {
* @flags: DRM_BUS_* flags used on this bus
*/
u32 flags;
+
+ /**
+ * @lanes: Lane mapping for this bus
+ */
+ struct drm_lane_cfg *lanes;
+
+ /**
+ * @num_lanes: Number of lanes in @lanes
+ */
+ u8 num_lanes;
};
/**
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 75019d16be64..064d3c8600a9 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -963,6 +963,10 @@ drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge,
struct drm_connector_state *conn_state,
u32 output_fmt,
unsigned int *num_input_fmts);
+const struct drm_lane_cfg *
+drm_bridge_next_bridge_lane_cfg(struct drm_bridge *bridge,
+ struct drm_atomic_state *state,
+ u8 *num_lanes);
enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge);
int drm_bridge_get_modes(struct drm_bridge *bridge,
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 02/11] drm/bridge: Verify lane assignment is going to work during atomic_check
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 01/11] drm/atomic-helper: Introduce lane remapping support to bridges Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 03/11] drm/bridge: aux-hpd: Support USB Type-C DP altmodes via DRM lane assignment Stephen Boyd
` (9 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
Verify during drm_atomic_bridge_check() that the lane assignment set in
a bridge's atomic_check() callback is going to be satisfied by the
previous bridge. If the next bridge is requiring something besides the
default 1:1 lane assignment on its input then there must be an output
lane assignment on the previous bridge's output. Otherwise the next
bridge won't get the lanes assigned that it needs.
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Robert Foss <rfoss@kernel.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: <dri-devel@lists.freedesktop.org>
Cc: Pin-yen Lin <treapking@chromium.org>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/gpu/drm/drm_bridge.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index bd18c1e91dee..68c7a321b9b3 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -860,6 +860,10 @@ static int drm_atomic_bridge_check(struct drm_bridge *bridge,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ u8 num_input_lanes, num_output_lanes = 0;
+ const struct drm_lane_cfg *input_lanes;
+ int i;
+
if (bridge->funcs->atomic_check) {
struct drm_bridge_state *bridge_state;
int ret;
@@ -873,12 +877,24 @@ static int drm_atomic_bridge_check(struct drm_bridge *bridge,
crtc_state, conn_state);
if (ret)
return ret;
+ num_output_lanes = bridge_state->output_bus_cfg.num_lanes;
} else if (bridge->funcs->mode_fixup) {
if (!bridge->funcs->mode_fixup(bridge, &crtc_state->mode,
&crtc_state->adjusted_mode))
return -EINVAL;
}
+ input_lanes = drm_bridge_next_bridge_lane_cfg(bridge,
+ crtc_state->state,
+ &num_input_lanes);
+ /*
+ * Ensure this bridge is aware that the next bridge wants to
+ * reassign lanes.
+ */
+ for (i = 0; i < num_input_lanes; i++)
+ if (i != input_lanes[i].logical && !num_output_lanes)
+ return -ENOTSUPP;
+
return 0;
}
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 03/11] drm/bridge: aux-hpd: Support USB Type-C DP altmodes via DRM lane assignment
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 01/11] drm/atomic-helper: Introduce lane remapping support to bridges Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 02/11] drm/bridge: Verify lane assignment is going to work during atomic_check Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 04/11] drm/bridge: dp_typec: Support USB Type-C orientation Stephen Boyd
` (8 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
Extend the aux-hpd bridge driver to support assigning DP lanes to USB
Type-C pins. Existing users of this driver only need the HPD signaling
support, so leave that in place and wrap the code with a variant that
supports more features of USB Type-C DP altmode, i.e. pin
configurations. Prefix that code with 'drm_dp_typec_bridge' to
differentiate it from the existing 'drm_aux_hpd_bridge' code.
Users allocate the bridge by passing a struct drm_dp_typec_bridge_desc
to devm_drm_dp_typec_bridge_alloc() and then use the returned pointer
for further operations like notifying HPD to the bridge chain or setting
the DP altmode pin configuration. All these APIs take an opaque struct
drm_dp_typec_bridge_dev pointer so that the wrong 'struct device' can't
be mistakenly used.
Note: The pin assignment function doesn't actively change the lane
configuration. Instead it stashes the lane assignment and requests the
assignment on the previous bridge in the chain during the atomic check
phase. Assume the USB Type-C pins are in the normal orientation for now.
A future patch will support type-c port orientation.
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>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 319 +++++++++++++++++++++++-
include/drm/bridge/aux-bridge.h | 52 ++++
2 files changed, 359 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
index 6886db2d9e00..716b2220bdd5 100644
--- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -7,8 +7,11 @@
#include <linux/auxiliary_bus.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/usb/typec_dp.h>
+#include <drm/drm_atomic_state_helper.h>
#include <drm/drm_bridge.h>
+#include <drm/drm_print.h>
#include <drm/bridge/aux-bridge.h>
static DEFINE_IDA(drm_aux_hpd_bridge_ida);
@@ -18,6 +21,48 @@ struct drm_aux_hpd_bridge_data {
struct device *dev;
};
+enum dp_lane {
+ DP_ML0 = 0, /* DP pins 1/3 */
+ DP_ML1 = 1, /* DP pins 4/6 */
+ DP_ML2 = 2, /* DP pins 7/9 */
+ DP_ML3 = 3, /* DP pins 10/12 */
+};
+
+struct drm_dp_typec_bridge_data {
+ u8 dp_lanes[DP_ML3 + 1];
+ size_t num_lanes;
+ struct drm_aux_hpd_bridge_data hpd_bridge;
+};
+
+static inline struct drm_dp_typec_bridge_data *
+hpd_bridge_to_typec_bridge_data(struct drm_aux_hpd_bridge_data *hpd_data)
+{
+ return container_of(hpd_data, struct drm_dp_typec_bridge_data, hpd_bridge);
+}
+
+static inline struct drm_dp_typec_bridge_data *
+to_drm_dp_typec_bridge_data(struct drm_bridge *bridge)
+{
+ struct drm_aux_hpd_bridge_data *hpd_data;
+
+ hpd_data = container_of(bridge, struct drm_aux_hpd_bridge_data, bridge);
+
+ return hpd_bridge_to_typec_bridge_data(hpd_data);
+}
+
+struct drm_dp_typec_bridge_dev {
+ struct auxiliary_device adev;
+ size_t max_lanes;
+};
+
+static inline struct drm_dp_typec_bridge_dev *
+to_drm_dp_typec_bridge_dev(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ return container_of(adev, struct drm_dp_typec_bridge_dev, adev);
+}
+
static void drm_aux_hpd_bridge_release(struct device *dev)
{
struct auxiliary_device *adev = to_auxiliary_dev(dev);
@@ -30,6 +75,22 @@ static void drm_aux_hpd_bridge_release(struct device *dev)
kfree(adev);
}
+static void drm_dp_typec_bridge_release(struct device *dev)
+{
+ struct drm_dp_typec_bridge_dev *typec_bridge_dev;
+ struct auxiliary_device *adev;
+
+ typec_bridge_dev = to_drm_dp_typec_bridge_dev(dev);
+ adev = &typec_bridge_dev->adev;
+
+ ida_free(&drm_aux_hpd_bridge_ida, adev->id);
+
+ of_node_put(adev->dev.platform_data);
+ of_node_put(adev->dev.of_node);
+
+ kfree(typec_bridge_dev);
+}
+
static void drm_aux_hpd_bridge_free_adev(void *_adev)
{
auxiliary_device_uninit(_adev);
@@ -133,6 +194,72 @@ struct device *drm_dp_hpd_bridge_register(struct device *parent, struct device_n
}
EXPORT_SYMBOL_GPL(drm_dp_hpd_bridge_register);
+/**
+ * devm_drm_dp_typec_bridge_alloc - Allocate a USB type-C DisplayPort bridge
+ * @parent: device instance providing this bridge
+ * @desc: device node pointer corresponding to this bridge instance
+ *
+ * Creates a DRM bridge with the type set to DRM_MODE_CONNECTOR_DisplayPort,
+ * which terminates the bridge chain and is able to send the HPD events along
+ * with remap DP lanes to match USB type-c DP altmode pin assignments.
+ *
+ * Return: device instance that will handle created bridge or an error code
+ * encoded into the pointer.
+ */
+struct drm_dp_typec_bridge_dev *
+devm_drm_dp_typec_bridge_alloc(struct device *parent, const struct drm_dp_typec_bridge_desc *desc)
+{
+ struct drm_dp_typec_bridge_dev *typec_bridge_dev;
+ struct auxiliary_device *adev;
+ int ret;
+
+ typec_bridge_dev = kzalloc(sizeof(*typec_bridge_dev), GFP_KERNEL);
+ if (!typec_bridge_dev)
+ return ERR_PTR(-ENOMEM);
+ adev = &typec_bridge_dev->adev;
+
+ ret = ida_alloc(&drm_aux_hpd_bridge_ida, GFP_KERNEL);
+ if (ret < 0) {
+ kfree(adev);
+ return ERR_PTR(ret);
+ }
+
+ adev->id = ret;
+ adev->name = "dp_typec_bridge";
+ adev->dev.parent = parent;
+ adev->dev.of_node = of_node_get(parent->of_node);
+ adev->dev.release = drm_dp_typec_bridge_release;
+ adev->dev.platform_data = of_node_get(desc->of_node);
+ typec_bridge_dev->max_lanes = desc->num_dp_lanes;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ of_node_put(adev->dev.platform_data);
+ of_node_put(adev->dev.of_node);
+ ida_free(&drm_aux_hpd_bridge_ida, adev->id);
+ kfree(adev);
+ return ERR_PTR(ret);
+ }
+
+ return typec_bridge_dev;
+}
+EXPORT_SYMBOL_GPL(devm_drm_dp_typec_bridge_alloc);
+
+/**
+ * devm_drm_dp_typec_bridge_add - register a USB type-C DisplayPort bridge
+ * @dev: struct device to tie registration lifetime to
+ * @typec_bridge_dev: USB type-c DisplayPort bridge to be registered
+ *
+ * Returns: zero on success or a negative errno
+ */
+int devm_drm_dp_typec_bridge_add(struct device *dev, struct drm_dp_typec_bridge_dev *typec_bridge_dev)
+{
+ struct auxiliary_device *adev = &typec_bridge_dev->adev;
+
+ return devm_drm_dp_hpd_bridge_add(dev, adev);
+}
+EXPORT_SYMBOL_GPL(devm_drm_dp_typec_bridge_add);
+
/**
* drm_aux_hpd_bridge_notify - notify hot plug detection events
* @dev: device created for the HPD bridge
@@ -155,38 +282,206 @@ void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status sta
}
EXPORT_SYMBOL_GPL(drm_aux_hpd_bridge_notify);
+/**
+ * drm_dp_typec_bridge_notify - notify hot plug detection events
+ * @typec_bridge_dev: device created for the type-C bridge
+ * @status: output connection status
+ *
+ * A wrapper around drm_bridge_hpd_notify() that is used to report hot plug
+ * detection events for bridges created via devm_drm_dp_typec_bridge_alloc().
+ *
+ * This function shall be called in a context that can sleep.
+ */
+void drm_dp_typec_bridge_notify(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
+ enum drm_connector_status status)
+{
+ drm_aux_hpd_bridge_notify(&typec_bridge_dev->adev.dev, status);
+}
+EXPORT_SYMBOL_GPL(drm_dp_typec_bridge_notify);
+
static int drm_aux_hpd_bridge_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
return flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR ? 0 : -EINVAL;
}
+static int dp_lane_to_typec_lane(enum dp_lane lane)
+{
+ switch (lane) {
+ case DP_ML0:
+ return USB_SSTX2;
+ case DP_ML1:
+ return USB_SSRX2;
+ case DP_ML2:
+ return USB_SSTX1;
+ case DP_ML3:
+ return USB_SSRX1;
+ }
+
+ return -EINVAL;
+}
+
+static int typec_to_dp_lane(enum usb_ss_lane lane)
+{
+ switch (lane) {
+ case USB_SSRX1:
+ return DP_ML3;
+ case USB_SSTX1:
+ return DP_ML2;
+ case USB_SSTX2:
+ return DP_ML0;
+ case USB_SSRX2:
+ return DP_ML1;
+ }
+
+ return -EINVAL;
+}
+
+/**
+ * drm_dp_typec_bridge_assign_pins - Assign DisplayPort (DP) lanes to USB type-C pins
+ * @typec_bridge_dev: Device created for the type-c bridge
+ * @conf: DisplayPort altmode configure command VDO content
+ * @lane_mapping: Physical (array index) to logical (array value) USB type-C lane mapping
+ *
+ * Assign DP lanes to the USB type-C pins for the DP altmode configuration
+ * @conf, while taking into account the USB type-C @lane_mapping. Future atomic
+ * checks on this bridge will request the lane assignment from the previous
+ * bridge so that the DP signal is sent to the proper USB type-C pins.
+ *
+ * Return: 0 on success, negative value for failure.
+ */
+int drm_dp_typec_bridge_assign_pins(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
+ u32 conf,
+ enum usb_ss_lane lane_mapping[NUM_USB_SS])
+{
+ struct auxiliary_device *adev = &typec_bridge_dev->adev;
+ struct drm_aux_hpd_bridge_data *hpd_data = auxiliary_get_drvdata(adev);
+ struct drm_dp_typec_bridge_data *data;
+ u8 *dp_lanes;
+ size_t num_lanes, max_lanes;
+ int i, typec_lane;
+ u8 pin_assign;
+
+ if (!hpd_data)
+ return -EINVAL;
+
+ data = hpd_bridge_to_typec_bridge_data(hpd_data);
+ dp_lanes = data->dp_lanes;
+
+ pin_assign = DP_CONF_GET_PIN_ASSIGN(conf);
+ if (pin_assign == DP_PIN_ASSIGN_D)
+ num_lanes = 2;
+ else
+ num_lanes = 4;
+ max_lanes = typec_bridge_dev->max_lanes;
+ data->num_lanes = num_lanes = min(num_lanes, max_lanes);
+
+ for (i = 0; i < num_lanes; i++) {
+ /* Get physical type-c lane for DP lane */
+ typec_lane = dp_lane_to_typec_lane(i);
+ if (typec_lane < 0) {
+ dev_err(&adev->dev, "Invalid type-c lane configuration at DP_ML%d\n", i);
+ return -EINVAL;
+ }
+
+ /* Map physical to logical type-c lane */
+ typec_lane = lane_mapping[typec_lane];
+
+ /* Map logical type-c lane to logical DP lane */
+ dp_lanes[i] = typec_to_dp_lane(typec_lane);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(drm_dp_typec_bridge_assign_pins);
+
+static int drm_dp_typec_bridge_atomic_check(struct drm_bridge *bridge,
+ struct drm_bridge_state *bridge_state,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state)
+{
+ struct drm_dp_typec_bridge_data *data;
+ struct drm_lane_cfg *in_lanes;
+ u8 *dp_lanes;
+ size_t num_lanes;
+ int i;
+
+ data = to_drm_dp_typec_bridge_data(bridge);
+ num_lanes = data->num_lanes;
+ if (!num_lanes)
+ return 0;
+ dp_lanes = data->dp_lanes;
+
+ in_lanes = kcalloc(num_lanes, sizeof(*in_lanes), GFP_KERNEL);
+ if (!in_lanes)
+ return -ENOMEM;
+
+ bridge_state->input_bus_cfg.lanes = in_lanes;
+ bridge_state->input_bus_cfg.num_lanes = num_lanes;
+
+ for (i = 0; i < num_lanes; i++)
+ in_lanes[i].logical = dp_lanes[i];
+
+ return 0;
+}
+
static const struct drm_bridge_funcs drm_aux_hpd_bridge_funcs = {
.attach = drm_aux_hpd_bridge_attach,
};
+static const struct drm_bridge_funcs drm_dp_typec_bridge_funcs = {
+ .attach = drm_aux_hpd_bridge_attach,
+ .atomic_check = drm_dp_typec_bridge_atomic_check,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+};
+
+enum drm_aux_bridge_type {
+ DRM_AUX_HPD_BRIDGE,
+ DRM_AUX_TYPEC_BRIDGE,
+};
+
static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
const struct auxiliary_device_id *id)
{
- struct drm_aux_hpd_bridge_data *data;
+ struct device *dev = &auxdev->dev;
+ struct drm_aux_hpd_bridge_data *hpd_data;
+ struct drm_dp_typec_bridge_data *typec_data;
+ struct drm_bridge *bridge;
+ u8 dp_lanes[] = { DP_ML0, DP_ML1, DP_ML2, DP_ML3 };
- data = devm_kzalloc(&auxdev->dev, sizeof(*data), GFP_KERNEL);
- if (!data)
- return -ENOMEM;
+ if (id->driver_data == DRM_AUX_HPD_BRIDGE) {
+ hpd_data = devm_kzalloc(dev, sizeof(*hpd_data), GFP_KERNEL);
+ if (!hpd_data)
+ return -ENOMEM;
+ bridge = &hpd_data->bridge;
+ bridge->funcs = &drm_aux_hpd_bridge_funcs;
+ } else if (id->driver_data == DRM_AUX_TYPEC_BRIDGE) {
+ typec_data = devm_kzalloc(dev, sizeof(*typec_data), GFP_KERNEL);
+ if (!typec_data)
+ return -ENOMEM;
+ hpd_data = &typec_data->hpd_bridge;
+ bridge = &hpd_data->bridge;
+ bridge->funcs = &drm_dp_typec_bridge_funcs;
+ memcpy(typec_data->dp_lanes, dp_lanes, sizeof(typec_data->dp_lanes));
+ } else {
+ return -ENODEV;
+ }
- data->dev = &auxdev->dev;
- data->bridge.funcs = &drm_aux_hpd_bridge_funcs;
- data->bridge.of_node = dev_get_platdata(data->dev);
- data->bridge.ops = DRM_BRIDGE_OP_HPD;
- data->bridge.type = id->driver_data;
+ hpd_data->dev = dev;
+ bridge->of_node = dev_get_platdata(dev);
+ bridge->ops = DRM_BRIDGE_OP_HPD;
+ bridge->type = DRM_MODE_CONNECTOR_DisplayPort;
- auxiliary_set_drvdata(auxdev, data);
+ auxiliary_set_drvdata(auxdev, hpd_data);
- return devm_drm_bridge_add(data->dev, &data->bridge);
+ return devm_drm_bridge_add(dev, bridge);
}
static const struct auxiliary_device_id drm_aux_hpd_bridge_table[] = {
- { .name = KBUILD_MODNAME ".dp_hpd_bridge", .driver_data = DRM_MODE_CONNECTOR_DisplayPort, },
+ { .name = KBUILD_MODNAME ".dp_hpd_bridge", .driver_data = DRM_AUX_HPD_BRIDGE, },
+ { .name = KBUILD_MODNAME ".dp_typec_bridge", .driver_data = DRM_AUX_TYPEC_BRIDGE, },
{},
};
MODULE_DEVICE_TABLE(auxiliary, drm_aux_hpd_bridge_table);
diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
index c2f5a855512f..aaace808772c 100644
--- a/include/drm/bridge/aux-bridge.h
+++ b/include/drm/bridge/aux-bridge.h
@@ -20,12 +20,40 @@ static inline int drm_aux_bridge_register(struct device *parent)
}
#endif
+struct drm_dp_typec_bridge_dev;
+
+/**
+ * struct drm_dp_typec_bridge_desc - drm_dp_typec_bridge descriptor
+ * @of_node: device node pointer corresponding to this bridge instance
+ * @num_dp_lanes: number of input DP lanes possible (1, 2 or 4)
+ */
+struct drm_dp_typec_bridge_desc {
+ struct device_node *of_node;
+ size_t num_dp_lanes;
+};
+
+enum usb_ss_lane {
+ USB_SSRX1 = 0, /* Type-C pins B11/B10 */
+ USB_SSTX1 = 1, /* Type-C pins A2/A3 */
+ USB_SSTX2 = 2, /* Type-C pins A11/A10 */
+ USB_SSRX2 = 3, /* Type-C pins B2/B3 */
+};
+
+#define NUM_USB_SS (USB_SSRX2 + 1)
+
#if IS_ENABLED(CONFIG_DRM_AUX_HPD_BRIDGE)
struct auxiliary_device *devm_drm_dp_hpd_bridge_alloc(struct device *parent, struct device_node *np);
int devm_drm_dp_hpd_bridge_add(struct device *dev, struct auxiliary_device *adev);
struct device *drm_dp_hpd_bridge_register(struct device *parent,
struct device_node *np);
void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status);
+struct drm_dp_typec_bridge_dev *devm_drm_dp_typec_bridge_alloc(struct device *parent,
+ const struct drm_dp_typec_bridge_desc *desc);
+int devm_drm_dp_typec_bridge_add(struct device *dev, struct drm_dp_typec_bridge_dev *typec_bridge_dev);
+void drm_dp_typec_bridge_notify(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
+ enum drm_connector_status status);
+int drm_dp_typec_bridge_assign_pins(struct drm_dp_typec_bridge_dev *typec_bridge_dev, u32 conf,
+ enum usb_ss_lane lane_mapping[NUM_USB_SS]);
#else
static inline struct auxiliary_device *devm_drm_dp_hpd_bridge_alloc(struct device *parent,
struct device_node *np)
@@ -44,9 +72,33 @@ static inline struct device *drm_dp_hpd_bridge_register(struct device *parent,
return NULL;
}
+static inline struct drm_dp_typec_bridge_dev *
+devm_drm_dp_typec_bridge_alloc(struct device *parent, const struct drm_dp_typec_bridge_desc *desc)
+{
+ return NULL;
+}
+
+static inline int devm_drm_dp_typec_bridge_add(struct device *dev,
+ struct drm_dp_typec_bridge_dev *typec_bridge_dev)
+{
+ return 0;
+}
+
static inline void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status status)
{
}
+
+static inline void drm_dp_typec_bridge_notify(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
+ enum drm_connector_status status)
+{
+}
+
+static inline int drm_dp_typec_bridge_assign_pins(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
+ u32 conf,
+ enum usb_ss_lane lane_mapping[NUM_USB_SS])
+{
+ return 0;
+}
#endif
#endif
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 04/11] drm/bridge: dp_typec: Support USB Type-C orientation
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (2 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 03/11] drm/bridge: aux-hpd: Support USB Type-C DP altmodes via DRM lane assignment Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 05/11] drm/bridge: dp_typec: Add "no-hpd" support Stephen Boyd
` (7 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
Add an orientation parameter to drm_dp_typec_bridge_assign_pins() so
that the DP lanes can be directed to the proper USB type-c pins on the
connector when the cable is flipped. This is mostly useful for the case
where the DP lanes are directly connected to the usb-c-connector and the
device doesn't have an orientation switch wired down on the board
between the connector and the DP controller. Flip the lanes to match the
physical pin locations on the connector when the orientation is reverse.
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>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 44 ++++++++++++++++++-------
include/drm/bridge/aux-bridge.h | 7 ++--
2 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
index 716b2220bdd5..79652d27db40 100644
--- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -7,6 +7,7 @@
#include <linux/auxiliary_bus.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/usb/typec.h>
#include <linux/usb/typec_dp.h>
#include <drm/drm_atomic_state_helper.h>
@@ -321,17 +322,35 @@ static int dp_lane_to_typec_lane(enum dp_lane lane)
return -EINVAL;
}
-static int typec_to_dp_lane(enum usb_ss_lane lane)
+static int typec_to_dp_lane(enum usb_ss_lane lane,
+ enum typec_orientation orientation)
{
- switch (lane) {
- case USB_SSRX1:
- return DP_ML3;
- case USB_SSTX1:
- return DP_ML2;
- case USB_SSTX2:
- return DP_ML0;
- case USB_SSRX2:
- return DP_ML1;
+ switch (orientation) {
+ case TYPEC_ORIENTATION_NONE:
+ case TYPEC_ORIENTATION_NORMAL:
+ switch (lane) {
+ case USB_SSRX1:
+ return DP_ML3;
+ case USB_SSTX1:
+ return DP_ML2;
+ case USB_SSTX2:
+ return DP_ML0;
+ case USB_SSRX2:
+ return DP_ML1;
+ }
+ break;
+ case TYPEC_ORIENTATION_REVERSE:
+ switch (lane) {
+ case USB_SSRX1:
+ return DP_ML0;
+ case USB_SSTX1:
+ return DP_ML1;
+ case USB_SSTX2:
+ return DP_ML3;
+ case USB_SSRX2:
+ return DP_ML2;
+ }
+ break;
}
return -EINVAL;
@@ -341,6 +360,7 @@ static int typec_to_dp_lane(enum usb_ss_lane lane)
* drm_dp_typec_bridge_assign_pins - Assign DisplayPort (DP) lanes to USB type-C pins
* @typec_bridge_dev: Device created for the type-c bridge
* @conf: DisplayPort altmode configure command VDO content
+ * @orientation: Orientation of USB type-c port
* @lane_mapping: Physical (array index) to logical (array value) USB type-C lane mapping
*
* Assign DP lanes to the USB type-C pins for the DP altmode configuration
@@ -351,7 +371,7 @@ static int typec_to_dp_lane(enum usb_ss_lane lane)
* Return: 0 on success, negative value for failure.
*/
int drm_dp_typec_bridge_assign_pins(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
- u32 conf,
+ u32 conf, enum typec_orientation orientation,
enum usb_ss_lane lane_mapping[NUM_USB_SS])
{
struct auxiliary_device *adev = &typec_bridge_dev->adev;
@@ -388,7 +408,7 @@ int drm_dp_typec_bridge_assign_pins(struct drm_dp_typec_bridge_dev *typec_bridge
typec_lane = lane_mapping[typec_lane];
/* Map logical type-c lane to logical DP lane */
- dp_lanes[i] = typec_to_dp_lane(typec_lane);
+ dp_lanes[i] = typec_to_dp_lane(typec_lane, orientation);
}
return 0;
diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
index aaace808772c..258b87c93623 100644
--- a/include/drm/bridge/aux-bridge.h
+++ b/include/drm/bridge/aux-bridge.h
@@ -7,6 +7,8 @@
#ifndef DRM_AUX_BRIDGE_H
#define DRM_AUX_BRIDGE_H
+#include <linux/usb/typec.h>
+
#include <drm/drm_connector.h>
struct auxiliary_device;
@@ -53,7 +55,8 @@ int devm_drm_dp_typec_bridge_add(struct device *dev, struct drm_dp_typec_bridge_
void drm_dp_typec_bridge_notify(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
enum drm_connector_status status);
int drm_dp_typec_bridge_assign_pins(struct drm_dp_typec_bridge_dev *typec_bridge_dev, u32 conf,
- enum usb_ss_lane lane_mapping[NUM_USB_SS]);
+ enum typec_orientation orientation,
+ enum usb_ss_lane lane_mapping[NUM_USB_SS]);
#else
static inline struct auxiliary_device *devm_drm_dp_hpd_bridge_alloc(struct device *parent,
struct device_node *np)
@@ -94,7 +97,7 @@ static inline void drm_dp_typec_bridge_notify(struct drm_dp_typec_bridge_dev *ty
}
static inline int drm_dp_typec_bridge_assign_pins(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
- u32 conf,
+ u32 conf, enum typec_orientation orientation,
enum usb_ss_lane lane_mapping[NUM_USB_SS])
{
return 0;
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 05/11] drm/bridge: dp_typec: Add "no-hpd" support
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (3 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 04/11] drm/bridge: dp_typec: Support USB Type-C orientation Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 06/11] drm/bridge: dp_typec: Allow users to hook hpd notify path Stephen Boyd
` (6 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
Some EC firmwares on Trogdor/Strongbad boards don't properly indicate
the state of the DP HPD level on a type-c port. The EC only indicates
that DP mode is entered or exited for a type-c port. The HPD state is
expressed to the DP controller via a pin on the AP that the EC drives
high or low when the type-c port partner (i.e. monitor) asserts or
deasserts HPD.
TL;DR: These devices don't support HPD signaling from the type-c code
paths.
Add support for HPD coming from somewhere else in the bridge chain.
Callers can set the struct drm_dp_typec_bridge_desc::no_hpd member to
indicate that HPD shouldn't be signaled from this bridge.
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>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 12 +++++++++++-
include/drm/bridge/aux-bridge.h | 2 ++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
index 79652d27db40..a5a434b7d5ec 100644
--- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -20,6 +20,7 @@ static DEFINE_IDA(drm_aux_hpd_bridge_ida);
struct drm_aux_hpd_bridge_data {
struct drm_bridge bridge;
struct device *dev;
+ bool no_hpd;
};
enum dp_lane {
@@ -54,6 +55,7 @@ to_drm_dp_typec_bridge_data(struct drm_bridge *bridge)
struct drm_dp_typec_bridge_dev {
struct auxiliary_device adev;
size_t max_lanes;
+ bool no_hpd;
};
static inline struct drm_dp_typec_bridge_dev *
@@ -232,6 +234,7 @@ devm_drm_dp_typec_bridge_alloc(struct device *parent, const struct drm_dp_typec_
adev->dev.release = drm_dp_typec_bridge_release;
adev->dev.platform_data = of_node_get(desc->of_node);
typec_bridge_dev->max_lanes = desc->num_dp_lanes;
+ typec_bridge_dev->no_hpd = desc->no_hpd;
ret = auxiliary_device_init(adev);
if (ret) {
@@ -278,6 +281,8 @@ void drm_aux_hpd_bridge_notify(struct device *dev, enum drm_connector_status sta
if (!data)
return;
+ if (data->no_hpd)
+ return;
drm_bridge_hpd_notify(&data->bridge, status);
}
@@ -467,6 +472,7 @@ static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
{
struct device *dev = &auxdev->dev;
struct drm_aux_hpd_bridge_data *hpd_data;
+ struct drm_dp_typec_bridge_dev *typec_bridge_dev;
struct drm_dp_typec_bridge_data *typec_data;
struct drm_bridge *bridge;
u8 dp_lanes[] = { DP_ML0, DP_ML1, DP_ML2, DP_ML3 };
@@ -477,6 +483,7 @@ static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
return -ENOMEM;
bridge = &hpd_data->bridge;
bridge->funcs = &drm_aux_hpd_bridge_funcs;
+ bridge->ops = DRM_BRIDGE_OP_HPD;
} else if (id->driver_data == DRM_AUX_TYPEC_BRIDGE) {
typec_data = devm_kzalloc(dev, sizeof(*typec_data), GFP_KERNEL);
if (!typec_data)
@@ -484,6 +491,10 @@ static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
hpd_data = &typec_data->hpd_bridge;
bridge = &hpd_data->bridge;
bridge->funcs = &drm_dp_typec_bridge_funcs;
+ typec_bridge_dev = to_drm_dp_typec_bridge_dev(dev);
+ if (!typec_bridge_dev->no_hpd)
+ bridge->ops = DRM_BRIDGE_OP_HPD;
+ hpd_data->no_hpd = typec_bridge_dev->no_hpd;
memcpy(typec_data->dp_lanes, dp_lanes, sizeof(typec_data->dp_lanes));
} else {
return -ENODEV;
@@ -491,7 +502,6 @@ static int drm_aux_hpd_bridge_probe(struct auxiliary_device *auxdev,
hpd_data->dev = dev;
bridge->of_node = dev_get_platdata(dev);
- bridge->ops = DRM_BRIDGE_OP_HPD;
bridge->type = DRM_MODE_CONNECTOR_DisplayPort;
auxiliary_set_drvdata(auxdev, hpd_data);
diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
index 258b87c93623..13f5e98b4d31 100644
--- a/include/drm/bridge/aux-bridge.h
+++ b/include/drm/bridge/aux-bridge.h
@@ -28,10 +28,12 @@ struct drm_dp_typec_bridge_dev;
* struct drm_dp_typec_bridge_desc - drm_dp_typec_bridge descriptor
* @of_node: device node pointer corresponding to this bridge instance
* @num_dp_lanes: number of input DP lanes possible (1, 2 or 4)
+ * @no_hpd: true if this bridge can't signal HPD state with drm_dp_typec_bridge_notify()
*/
struct drm_dp_typec_bridge_desc {
struct device_node *of_node;
size_t num_dp_lanes;
+ bool no_hpd;
};
enum usb_ss_lane {
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 06/11] drm/bridge: dp_typec: Allow users to hook hpd notify path
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (4 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 05/11] drm/bridge: dp_typec: Add "no-hpd" support Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 07/11] dt-bindings: chrome: Add ports to google, cros-ec-typec for DP altmode Stephen Boyd
` (5 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
The previous patch added support for no-hpd to drm_dp_typec_bridge code.
Allow users of this bridge to hook the HPD notification path of the
bridge chain so that they can be made aware of the connector status
changing. This helps HPD-less users of the bridge inject the HPD state
into their code by using the connector status as a proxy for HPD being
asserted or deasserted.
In particular, this will help Trogdor/Strongbad boards that need to read
the EC's analog mux which steers the DP signal to one or the other USB
type-c ports to figure out which type-c port has HPD asserted.
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>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
drivers/gpu/drm/bridge/aux-hpd-bridge.c | 19 +++++++++++++++++++
include/drm/bridge/aux-bridge.h | 5 +++++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/bridge/aux-hpd-bridge.c b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
index a5a434b7d5ec..32c0171c512c 100644
--- a/drivers/gpu/drm/bridge/aux-hpd-bridge.c
+++ b/drivers/gpu/drm/bridge/aux-hpd-bridge.c
@@ -55,6 +55,9 @@ to_drm_dp_typec_bridge_data(struct drm_bridge *bridge)
struct drm_dp_typec_bridge_dev {
struct auxiliary_device adev;
size_t max_lanes;
+ void (*hpd_notify)(struct drm_dp_typec_bridge_dev *dev,
+ void *data, enum drm_connector_status status);
+ void *hpd_data;
bool no_hpd;
};
@@ -235,6 +238,8 @@ devm_drm_dp_typec_bridge_alloc(struct device *parent, const struct drm_dp_typec_
adev->dev.platform_data = of_node_get(desc->of_node);
typec_bridge_dev->max_lanes = desc->num_dp_lanes;
typec_bridge_dev->no_hpd = desc->no_hpd;
+ typec_bridge_dev->hpd_notify = desc->hpd_notify;
+ typec_bridge_dev->hpd_data = desc->hpd_data;
ret = auxiliary_device_init(adev);
if (ret) {
@@ -305,6 +310,19 @@ void drm_dp_typec_bridge_notify(struct drm_dp_typec_bridge_dev *typec_bridge_dev
}
EXPORT_SYMBOL_GPL(drm_dp_typec_bridge_notify);
+static void drm_dp_typec_bridge_hpd_notify(struct drm_bridge *bridge,
+ enum drm_connector_status status)
+{
+ struct drm_dp_typec_bridge_data *data;
+ struct drm_dp_typec_bridge_dev *typec_bridge_dev;
+
+ data = to_drm_dp_typec_bridge_data(bridge);
+ typec_bridge_dev = to_drm_dp_typec_bridge_dev(data->hpd_bridge.dev);
+
+ if (typec_bridge_dev->hpd_notify)
+ typec_bridge_dev->hpd_notify(typec_bridge_dev, typec_bridge_dev->hpd_data, status);
+}
+
static int drm_aux_hpd_bridge_attach(struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags)
{
@@ -460,6 +478,7 @@ static const struct drm_bridge_funcs drm_dp_typec_bridge_funcs = {
.atomic_reset = drm_atomic_helper_bridge_reset,
.atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .hpd_notify = drm_dp_typec_bridge_hpd_notify,
};
enum drm_aux_bridge_type {
diff --git a/include/drm/bridge/aux-bridge.h b/include/drm/bridge/aux-bridge.h
index 13f5e98b4d31..3229f200f0df 100644
--- a/include/drm/bridge/aux-bridge.h
+++ b/include/drm/bridge/aux-bridge.h
@@ -28,11 +28,16 @@ struct drm_dp_typec_bridge_dev;
* struct drm_dp_typec_bridge_desc - drm_dp_typec_bridge descriptor
* @of_node: device node pointer corresponding to this bridge instance
* @num_dp_lanes: number of input DP lanes possible (1, 2 or 4)
+ * @hpd_notify: callback for bridge hot plug detect events
+ * @hpd_data: data passed to @hpd_notify callback
* @no_hpd: true if this bridge can't signal HPD state with drm_dp_typec_bridge_notify()
*/
struct drm_dp_typec_bridge_desc {
struct device_node *of_node;
size_t num_dp_lanes;
+ void (*hpd_notify)(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
+ void *data, enum drm_connector_status status);
+ void *hpd_data;
bool no_hpd;
};
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 07/11] dt-bindings: chrome: Add ports to google, cros-ec-typec for DP altmode
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (5 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 06/11] drm/bridge: dp_typec: Allow users to hook hpd notify path Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-21 16:12 ` [PATCH v2 07/11] dt-bindings: chrome: Add ports to google,cros-ec-typec " Lee Jones
2024-08-15 0:34 ` [PATCH v2 08/11] platform/chrome: cros_ec_typec: Add support for signaling DP HPD via drm_bridge Stephen Boyd
` (4 subsequent siblings)
11 siblings, 1 reply; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
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.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: 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/chrome/google,cros-ec-typec.yaml | 260 ++++++++++++++++++
.../bindings/mfd/google,cros-ec.yaml | 7 +-
2 files changed, 264 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
index 9f9816fbecbc..1238adfbea21 100644
--- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
+++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
@@ -26,6 +26,137 @@ properties:
'#size-cells':
const: 0
+ mux-gpios:
+ description: GPIOs indicating which way the DP mux is steered
+ maxItems: 1
+
+ no-hpd:
+ description: Indicates this endpoint doesn't signal HPD for DisplayPort
+ type: boolean
+
+ orientation:
+ description:
+ Indicates this endpoint assigns lanes based on altmode and
+ type-c port orientation
+ type: boolean
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description:
+ Input port to receive DisplayPort (DP) data
+ unevaluatedProperties: false
+
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ description: DisplayPort data for the type-c port(s)
+ unevaluatedProperties: false
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An array of physical DP data lane indexes
+ - 0 is DP ML0 lane
+ - 1 is DP ML1 lane
+ - 2 is DP ML2 lane
+ - 3 is DP ML3 lane
+ oneOf:
+ - items:
+ - const: 0
+ - const: 1
+ - items:
+ - const: 0
+ - const: 1
+ - const: 2
+ - const: 3
+
+ required:
+ - endpoint@0
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port to receive USB SuperSpeed (SS) data
+ patternProperties:
+ "^endpoint@([0-8])$":
+ $ref: /schemas/graph.yaml#/properties/endpoint
+
+ anyOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+ - required:
+ - endpoint@2
+ - required:
+ - endpoint@3
+ - required:
+ - endpoint@4
+ - required:
+ - endpoint@5
+ - required:
+ - endpoint@6
+ - required:
+ - endpoint@7
+ - required:
+ - endpoint@8
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description: Output ports for combined DP and USB SS data
+ patternProperties:
+ "^endpoint@([0-8])$":
+ $ref: /schemas/graph.yaml#/$defs/endpoint-base
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ An array of physical USB Type-C data lane indexes.
+ - 0 is SSRX1 lane
+ - 1 is SSTX1 lane
+ - 2 is SSTX2 lane
+ - 3 is SSRX2 lane
+ minItems: 4
+ maxItems: 4
+ items:
+ maximum: 3
+
+ anyOf:
+ - required:
+ - endpoint@0
+ - required:
+ - endpoint@1
+ - required:
+ - endpoint@2
+ - required:
+ - endpoint@3
+ - required:
+ - endpoint@4
+ - required:
+ - endpoint@5
+ - required:
+ - endpoint@6
+ - required:
+ - endpoint@7
+ - required:
+ - endpoint@8
+
+ required:
+ - port@2
+ anyOf:
+ - required:
+ - port@0
+ - required:
+ - port@1
+
patternProperties:
'^connector@[0-9a-f]+$':
$ref: /schemas/connector/usb-connector.yaml#
@@ -35,6 +166,38 @@ patternProperties:
required:
- compatible
+allOf:
+ - if:
+ properties:
+ no-hpd: true
+ required:
+ - no-hpd
+ then:
+ properties:
+ ports:
+ required:
+ - port@0
+ - if:
+ properties:
+ mux-gpios: true
+ required:
+ - mux-gpios
+ then:
+ properties:
+ ports:
+ required:
+ - port@0
+ - if:
+ properties:
+ orientation: true
+ required:
+ - orientation
+ then:
+ properties:
+ ports:
+ required:
+ - port@0
+
additionalProperties: false
examples:
@@ -60,6 +223,103 @@ examples:
power-role = "dual";
data-role = "dual";
try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usb_c0_hs: endpoint {
+ remote-endpoint = <&usb_hub_dfp3_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usb_c0_ss: endpoint {
+ remote-endpoint = <&cros_typec_c0_ss>;
+ };
+ };
+ };
+ };
+
+ connector@1 {
+ compatible = "usb-c-connector";
+ reg = <1>;
+ power-role = "dual";
+ data-role = "dual";
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usb_c1_hs: endpoint {
+ remote-endpoint = <&usb_hub_dfp2_hs>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usb_c1_ss: endpoint {
+ remote-endpoint = <&cros_typec_c1_ss>;
+ };
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dp_in: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&dp_phy>;
+ data-lanes = <0 1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb_in_0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usb_ss_0_out>;
+ };
+
+ usb_in_1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usb_ss_1_out>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cros_typec_c0_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usb_c0_ss>;
+ data-lanes = <0 1 2 3>;
+ };
+
+ cros_typec_c1_ss: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usb_c1_ss>;
+ data-lanes = <2 3 0 1>;
+ };
+ };
};
};
};
diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
index aac8819bd00b..c860eb7ed3f5 100644
--- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
+++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
@@ -98,9 +98,6 @@ properties:
gpio-controller: true
- typec:
- $ref: /schemas/chrome/google,cros-ec-typec.yaml#
-
ec-pwm:
$ref: /schemas/pwm/google,cros-ec-pwm.yaml#
deprecated: true
@@ -166,6 +163,10 @@ patternProperties:
type: object
$ref: /schemas/extcon/extcon-usbc-cros-ec.yaml#
+ "^typec(-[0-9])*$":
+ type: object
+ $ref: /schemas/chrome/google,cros-ec-typec.yaml#
+
required:
- compatible
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 08/11] platform/chrome: cros_ec_typec: Add support for signaling DP HPD via drm_bridge
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (6 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 07/11] dt-bindings: chrome: Add ports to google, cros-ec-typec for DP altmode Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 09/11] platform/chrome: cros_ec_typec: Support DP muxing via DRM lane assignment Stephen Boyd
` (3 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
We can imagine that logically the EC is a device that has some number of
DisplayPort (DP) connector inputs, some number of USB3 connector inputs,
and some number of USB type-c connector outputs. If you squint enough it
looks like a USB type-c dock. Logically there's a crossbar pin
assignment capability within the EC that can assign USB and DP lanes to
USB type-c lanes in the connector (i.e. USB type-c pin configurations).
In reality, the EC is a microcontroller that has some TCPCs and
redrivers connected to it over something like i2c and DP/USB from the AP
is wired directly to those ICs, not the EC.
This design allows the EC to abstract many possible USB and DP hardware
configurations away from the AP (kernel) so that the AP can largely deal
with USB and DP without thinking about USB Type-C much at all. The DP
and USB data originate in the AP, not the EC, so it helps to think that
the EC takes the DP and USB data as input to mux onto USB type-c ports
even if it really doesn't do that. With this split design, the EC
forwards the DP HPD state to the DP hardware via a GPIO that's connected
to the DP phy.
Having that HPD state signaled directly to the DP phy uses precious
hardware resources, a pin or two and a wire, and it also forces the TCPM
to live on the EC. If we want to save costs and move more control of USB
type-c to the kernel it's in our interest to get rid of the HPD pin
entirely and signal HPD to the DP phy some other way. Luckily, the EC
already exposes information about the USB Type-C stack to the kernel via
the host command interface in the "google,cros-ec-typec" compatible
driver, which parses EC messages related to USB type-c and effectively
"replays" those messages to the kernel's USB typec subsystem. This
includes the state of HPD, which can be interrogated and acted upon by
registering a 'struct typec_mux_dev' with the typec subsystem or by
hooking directly into this cros_ec_typec driver.
On DT based systems, the DP display pipeline is abstracted via a 'struct
drm_bridge'. If we want to signal HPD state from within the kernel we
need to hook into the drm_bridge framework somehow to call
drm_bridge_hpd_notify() when HPD state changes in the typec framework.
Use the newly added drm_dp_typec_bridge code to do this. When the EC
notifies AP of a type-c event, look at the port state and set the
connector state to connected or disconnected based on the HPD level when
the port is in DP mode.
To keep this patch minimal, only signal HPD state to the drm_bridge
chain. Later patches will add more features. Eventually we'll be able to
inform userspace about which usb-c-connector node is displaying DP and
what USB devices are connected to a connector.
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>
---
drivers/platform/chrome/Kconfig | 1 +
drivers/platform/chrome/cros_ec_typec.c | 64 ++++++++++++++++++++++++-
drivers/platform/chrome/cros_ec_typec.h | 4 +-
3 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index 7dbeb786352a..0aee8a77f1d6 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -231,6 +231,7 @@ config CROS_EC_TYPEC
depends on MFD_CROS_EC_DEV && TYPEC
depends on CROS_USBPD_NOTIFY
depends on USB_ROLE_SWITCH
+ select DRM_AUX_HPD_BRIDGE if DRM_BRIDGE && OF
default MFD_CROS_EC_DEV
help
If you say Y here, you get support for accessing Type C connector
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index 4d305876ec08..5cbc6b3df906 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -9,6 +9,7 @@
#include <linux/acpi.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
#include <linux/platform_data/cros_ec_commands.h>
#include <linux/platform_data/cros_usbpd_notify.h>
#include <linux/platform_device.h>
@@ -16,11 +17,18 @@
#include <linux/usb/typec_dp.h>
#include <linux/usb/typec_tbt.h>
+#include <drm/bridge/aux-bridge.h>
+
#include "cros_ec_typec.h"
#include "cros_typec_vdm.h"
#define DRV_NAME "cros-ec-typec"
+struct cros_typec_dp_bridge {
+ struct cros_typec_data *typec_data;
+ struct drm_dp_typec_bridge_dev *dev;
+};
+
#define DP_PORT_VDO (DP_CONF_SET_PIN_ASSIGN(BIT(DP_PIN_ASSIGN_C) | BIT(DP_PIN_ASSIGN_D)) | \
DP_CAP_DFP_D | DP_CAP_RECEPTACLE)
@@ -334,6 +342,9 @@ static int cros_typec_init_ports(struct cros_typec_data *typec)
u32 port_num = 0;
nports = device_get_child_node_count(dev);
+ /* Don't count any 'ports' child node */
+ if (of_graph_is_present(dev->of_node))
+ nports--;
if (nports == 0) {
dev_err(dev, "No port entries found.\n");
return -ENODEV;
@@ -347,6 +358,10 @@ static int cros_typec_init_ports(struct cros_typec_data *typec)
/* DT uses "reg" to specify port number. */
port_prop = dev->of_node ? "reg" : "port-number";
device_for_each_child_node(dev, fwnode) {
+ /* An OF graph isn't a connector */
+ if (fwnode_name_eq(fwnode, "ports"))
+ continue;
+
if (fwnode_property_read_u32(fwnode, port_prop, &port_num)) {
ret = -EINVAL;
dev_err(dev, "No port-number for port, aborting.\n");
@@ -413,6 +428,36 @@ static int cros_typec_init_ports(struct cros_typec_data *typec)
return ret;
}
+static int cros_typec_init_dp_bridge(struct cros_typec_data *typec)
+{
+ struct device *dev = typec->dev;
+ struct cros_typec_dp_bridge *dp_bridge;
+ struct fwnode_handle *ep __free(fwnode_handle);
+ struct drm_dp_typec_bridge_dev *dp_dev;
+ struct drm_dp_typec_bridge_desc desc = {
+ .of_node = dev->of_node,
+ };
+
+ ep = fwnode_graph_get_endpoint_by_id(dev_fwnode(dev), 0, 0, 0);
+ if (!ep) {
+ /* There isn't a DP input endpoint. Ignore. */
+ return 0;
+ }
+
+ dp_bridge = devm_kzalloc(dev, sizeof(*dp_bridge), GFP_KERNEL);
+ if (!dp_bridge)
+ return -ENOMEM;
+ typec->dp_bridge = dp_bridge;
+ dp_bridge->typec_data = typec;
+
+ dp_dev = devm_drm_dp_typec_bridge_alloc(dev, &desc);
+ if (IS_ERR(dp_dev))
+ return PTR_ERR(dp_dev);
+ dp_bridge->dev = dp_dev;
+
+ return devm_drm_dp_typec_bridge_add(dev, dp_dev);
+}
+
static int cros_typec_usb_safe_state(struct cros_typec_port *port)
{
int ret;
@@ -612,6 +657,7 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
struct ec_response_usb_pd_control_v2 *pd_ctrl)
{
struct cros_typec_port *port = typec->ports[port_num];
+ struct cros_typec_dp_bridge *dp_bridge = typec->dp_bridge;
struct ec_response_usb_pd_mux_info resp;
struct ec_params_usb_pd_mux_info req = {
.port = port_num,
@@ -619,6 +665,7 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
struct ec_params_usb_pd_mux_ack mux_ack;
enum typec_orientation orientation;
int ret;
+ bool dp_enabled;
ret = cros_ec_cmd(typec->ec, 0, EC_CMD_USB_PD_MUX_INFO,
&req, sizeof(req), &resp, sizeof(resp));
@@ -628,6 +675,8 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
return ret;
}
+ dp_enabled = resp.flags & USB_PD_MUX_DP_ENABLED;
+
/* No change needs to be made, let's exit early. */
if (port->mux_flags == resp.flags && port->role == pd_ctrl->role)
return 0;
@@ -659,8 +708,14 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
ret = cros_typec_enable_usb4(typec, port_num, pd_ctrl);
} else if (port->mux_flags & USB_PD_MUX_TBT_COMPAT_ENABLED) {
ret = cros_typec_enable_tbt(typec, port_num, pd_ctrl);
- } else if (port->mux_flags & USB_PD_MUX_DP_ENABLED) {
+ } else if (dp_enabled) {
ret = cros_typec_enable_dp(typec, port_num, pd_ctrl);
+ if (dp_bridge) {
+ drm_dp_typec_bridge_notify(dp_bridge->dev,
+ port->mux_flags & USB_PD_MUX_HPD_LVL ?
+ connector_status_connected :
+ connector_status_disconnected);
+ }
} else if (port->mux_flags & USB_PD_MUX_SAFE_MODE) {
ret = cros_typec_usb_safe_state(port);
} else if (port->mux_flags & USB_PD_MUX_USB_ENABLED) {
@@ -677,6 +732,9 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
}
mux_ack:
+ if (dp_bridge && !dp_enabled)
+ drm_dp_typec_bridge_notify(dp_bridge->dev, connector_status_disconnected);
+
if (!typec->needs_mux_ack)
return ret;
@@ -1261,6 +1319,10 @@ static int cros_typec_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
+ ret = cros_typec_init_dp_bridge(typec);
+ if (ret < 0)
+ return ret;
+
INIT_WORK(&typec->port_work, cros_typec_port_work);
/*
diff --git a/drivers/platform/chrome/cros_ec_typec.h b/drivers/platform/chrome/cros_ec_typec.h
index deda180a646f..37c9a3ae3402 100644
--- a/drivers/platform/chrome/cros_ec_typec.h
+++ b/drivers/platform/chrome/cros_ec_typec.h
@@ -27,6 +27,8 @@ struct cros_typec_altmode_node {
struct list_head list;
};
+struct cros_typec_dp_bridge;
+
/* Platform-specific data for the Chrome OS EC Type C controller. */
struct cros_typec_data {
struct device *dev;
@@ -35,12 +37,12 @@ struct cros_typec_data {
unsigned int pd_ctrl_ver;
/* Array of ports, indexed by port number. */
struct cros_typec_port *ports[EC_USB_PD_MAX_PORTS];
+ struct cros_typec_dp_bridge *dp_bridge;
struct notifier_block nb;
struct work_struct port_work;
bool typec_cmd_supported;
bool needs_mux_ack;
};
-
/* Per port data. */
struct cros_typec_port {
struct typec_port *port;
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 09/11] platform/chrome: cros_ec_typec: Support DP muxing via DRM lane assignment
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (7 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 08/11] platform/chrome: cros_ec_typec: Add support for signaling DP HPD via drm_bridge Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 10/11] platform/chrome: cros_ec_typec: Support DP orientation Stephen Boyd
` (2 subsequent siblings)
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
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 (DP ML0/ML1)
wired to one type-c port while the other two (DP ML2/ML3) are wired to
another type-c port.
Use drm_dp_typec_bridge_assign_pins() to implement support for DP
altmode configurations like pinconf D and DP muxing to different type-c
ports. In the DP altmode spec, pinconf C assigns all 4 SuperSpeed lanes
in the usb-c-connector node to DP, while pinconf D assigns 2 SuperSpeed
lanes to DP and 2 SuperSpeed lanes to USB. Use the 'data-lanes' property
from the input DP graph endpoint to calculate the maximum number of
lanes coming from the DP source (either 2 or 4) and limit the lanes
requested to the smaller of this or the pin configuration.
Use the 'data-lanes' property from the active type-c output port to
determine which logical DP lanes should be assigned to the output of the
drm_bridge by passing the lane mapping to
drm_dp_typec_bridge_assign_pins(). For now assume the type-c pins are in
the normal orientation.
The EC can mux the DP signal to any number of USB type-c ports. We only
need to make sure that the drm_bridge is mapping the DP lanes to the
appropriate type-c pins for the pin configuration. This means that
having the same type-c port data-lanes property is valid and expected in
cases where an analog mux is used to steer the DP signal to one of many
TCPCs and eventually usb-c-connector nodes.
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>
---
drivers/platform/chrome/cros_ec_typec.c | 49 +++++++++++++++++++++++--
drivers/platform/chrome/cros_ec_typec.h | 3 ++
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index 5cbc6b3df906..fa7f7efb9d3f 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -27,6 +27,7 @@
struct cros_typec_dp_bridge {
struct cros_typec_data *typec_data;
struct drm_dp_typec_bridge_dev *dev;
+ struct cros_typec_port *active_port;
};
#define DP_PORT_VDO (DP_CONF_SET_PIN_ASSIGN(BIT(DP_PIN_ASSIGN_C) | BIT(DP_PIN_ASSIGN_D)) | \
@@ -330,6 +331,20 @@ static int cros_typec_register_port_altmodes(struct cros_typec_data *typec,
return 0;
}
+static void cros_typec_init_dp_usbc_lanes(struct cros_typec_port *typec_port)
+{
+ struct cros_typec_data *typec = typec_port->typec_data;
+ unsigned int port_num = typec_port->port_num;
+ struct device *dev = typec->dev;
+ struct fwnode_handle *ep __free(fwnode_handle);
+ const u32 default_lane_mapping[] = { 0, 1, 2, 3 };
+
+ ep = fwnode_graph_get_endpoint_by_id(dev_fwnode(dev), 2, port_num, 0);
+ if (fwnode_property_read_u32_array(ep, "data-lanes", typec_port->lane_mapping,
+ ARRAY_SIZE(typec_port->lane_mapping)))
+ memcpy(typec_port->lane_mapping, default_lane_mapping, sizeof(default_lane_mapping));
+}
+
static int cros_typec_init_ports(struct cros_typec_data *typec)
{
struct device *dev = typec->dev;
@@ -387,6 +402,7 @@ static int cros_typec_init_ports(struct cros_typec_data *typec)
typec->ports[port_num] = cros_port;
cap = &cros_port->caps;
+ cros_typec_init_dp_usbc_lanes(cros_port);
ret = cros_typec_parse_port_props(cap, fwnode, dev);
if (ret < 0)
goto unregister_ports;
@@ -434,6 +450,7 @@ static int cros_typec_init_dp_bridge(struct cros_typec_data *typec)
struct cros_typec_dp_bridge *dp_bridge;
struct fwnode_handle *ep __free(fwnode_handle);
struct drm_dp_typec_bridge_dev *dp_dev;
+ int num_lanes;
struct drm_dp_typec_bridge_desc desc = {
.of_node = dev->of_node,
};
@@ -450,6 +467,11 @@ static int cros_typec_init_dp_bridge(struct cros_typec_data *typec)
typec->dp_bridge = dp_bridge;
dp_bridge->typec_data = typec;
+ num_lanes = fwnode_property_count_u32(ep, "data-lanes");
+ if (num_lanes < 0)
+ num_lanes = 4;
+ desc.num_dp_lanes = num_lanes;
+
dp_dev = devm_drm_dp_typec_bridge_alloc(dev, &desc);
if (IS_ERR(dp_dev))
return PTR_ERR(dp_dev);
@@ -555,10 +577,12 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
struct ec_response_usb_pd_control_v2 *pd_ctrl)
{
struct cros_typec_port *port = typec->ports[port_num];
+ struct cros_typec_dp_bridge *dp_bridge = typec->dp_bridge;
struct typec_displayport_data dp_data;
u32 cable_tbt_vdo;
u32 cable_dp_vdo;
int ret;
+ bool hpd_asserted = port->mux_flags & USB_PD_MUX_HPD_LVL;
if (typec->pd_ctrl_ver < 2) {
dev_err(typec->dev,
@@ -566,6 +590,16 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
return -ENOTSUPP;
}
+ /*
+ * Assume the first port to have HPD asserted is the one muxed to DP
+ * (i.e. active_port). When there's only one port this delays setting
+ * the active_port until HPD is asserted, but before that the
+ * drm_connector looks disconnected so active_port doesn't need to be
+ * set.
+ */
+ if (dp_bridge && hpd_asserted && !dp_bridge->active_port)
+ dp_bridge->active_port = port;
+
if (!pd_ctrl->dp_mode) {
dev_err(typec->dev, "No valid DP mode provided.\n");
return -EINVAL;
@@ -575,7 +609,7 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
dp_data.status = DP_STATUS_ENABLED;
if (port->mux_flags & USB_PD_MUX_HPD_IRQ)
dp_data.status |= DP_STATUS_IRQ_HPD;
- if (port->mux_flags & USB_PD_MUX_HPD_LVL)
+ if (hpd_asserted)
dp_data.status |= DP_STATUS_HPD_STATE;
/* Configuration VDO. */
@@ -587,6 +621,13 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
return ret;
}
+ if (dp_bridge && dp_bridge->active_port == port) {
+ ret = drm_dp_typec_bridge_assign_pins(dp_bridge->dev, dp_data.conf, 0,
+ port->lane_mapping);
+ if (ret)
+ return ret;
+ }
+
port->state.data = &dp_data;
port->state.mode = TYPEC_MODAL_STATE(ffs(pd_ctrl->dp_mode));
@@ -710,7 +751,7 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
ret = cros_typec_enable_tbt(typec, port_num, pd_ctrl);
} else if (dp_enabled) {
ret = cros_typec_enable_dp(typec, port_num, pd_ctrl);
- if (dp_bridge) {
+ if (dp_bridge && dp_bridge->active_port == port) {
drm_dp_typec_bridge_notify(dp_bridge->dev,
port->mux_flags & USB_PD_MUX_HPD_LVL ?
connector_status_connected :
@@ -732,8 +773,10 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
}
mux_ack:
- if (dp_bridge && !dp_enabled)
+ if (dp_bridge && !dp_enabled && dp_bridge->active_port == port) {
drm_dp_typec_bridge_notify(dp_bridge->dev, connector_status_disconnected);
+ dp_bridge->active_port = NULL;
+ }
if (!typec->needs_mux_ack)
return ret;
diff --git a/drivers/platform/chrome/cros_ec_typec.h b/drivers/platform/chrome/cros_ec_typec.h
index 37c9a3ae3402..74d062dc03b2 100644
--- a/drivers/platform/chrome/cros_ec_typec.h
+++ b/drivers/platform/chrome/cros_ec_typec.h
@@ -14,6 +14,8 @@
#include <linux/usb/typec_retimer.h>
#include <linux/workqueue.h>
+#include <drm/bridge/aux-bridge.h>
+
/* Supported alt modes. */
enum {
CROS_EC_ALTMODE_DP = 0,
@@ -67,6 +69,7 @@ struct cros_typec_port {
uint8_t mux_flags;
uint8_t role;
+ u32 lane_mapping[NUM_USB_SS];
struct typec_altmode *port_altmode[CROS_EC_ALTMODE_MAX];
/* Flag indicating that PD partner discovery data parsing is completed. */
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 10/11] platform/chrome: cros_ec_typec: Support DP orientation
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (8 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 09/11] platform/chrome: cros_ec_typec: Support DP muxing via DRM lane assignment Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 11/11] platform/chrome: cros_ec_typec: Handle lack of HPD information Stephen Boyd
2024-08-16 22:12 ` [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
Handle orientation for the type-c port when the DT node has the
'orientation' property. The 'orientation' property is present when the
DisplayPort lanes are directly wired to the usb-c-connector and the
board design relies on the DP lanes to be remapped by software. The
property wouldn't be present if, for example, the EC controls a port
mapper part that flips the DP lanes for the port orientation.
Pass the port orientation to drm_dp_typec_bridge_assign_pins() when the
DT property is present so that the previous drm_bridge in the bridge
chain can remap the DP lanes to the right usb-c-connector SuperSpeed
pins for the orientation.
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>
---
drivers/platform/chrome/cros_ec_typec.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index fa7f7efb9d3f..9b54b3288f5f 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -28,6 +28,7 @@ struct cros_typec_dp_bridge {
struct cros_typec_data *typec_data;
struct drm_dp_typec_bridge_dev *dev;
struct cros_typec_port *active_port;
+ bool orientation;
};
#define DP_PORT_VDO (DP_CONF_SET_PIN_ASSIGN(BIT(DP_PIN_ASSIGN_C) | BIT(DP_PIN_ASSIGN_D)) | \
@@ -449,13 +450,15 @@ static int cros_typec_init_dp_bridge(struct cros_typec_data *typec)
struct device *dev = typec->dev;
struct cros_typec_dp_bridge *dp_bridge;
struct fwnode_handle *ep __free(fwnode_handle);
+ struct fwnode_handle *devnode;
struct drm_dp_typec_bridge_dev *dp_dev;
int num_lanes;
struct drm_dp_typec_bridge_desc desc = {
.of_node = dev->of_node,
};
- ep = fwnode_graph_get_endpoint_by_id(dev_fwnode(dev), 0, 0, 0);
+ devnode = dev_fwnode(dev);
+ ep = fwnode_graph_get_endpoint_by_id(devnode, 0, 0, 0);
if (!ep) {
/* There isn't a DP input endpoint. Ignore. */
return 0;
@@ -467,6 +470,8 @@ static int cros_typec_init_dp_bridge(struct cros_typec_data *typec)
typec->dp_bridge = dp_bridge;
dp_bridge->typec_data = typec;
+ dp_bridge->orientation = fwnode_property_read_bool(devnode, "orientation");
+
num_lanes = fwnode_property_count_u32(ep, "data-lanes");
if (num_lanes < 0)
num_lanes = 4;
@@ -582,6 +587,7 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
u32 cable_tbt_vdo;
u32 cable_dp_vdo;
int ret;
+ enum typec_orientation orientation;
bool hpd_asserted = port->mux_flags & USB_PD_MUX_HPD_LVL;
if (typec->pd_ctrl_ver < 2) {
@@ -622,7 +628,13 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
}
if (dp_bridge && dp_bridge->active_port == port) {
- ret = drm_dp_typec_bridge_assign_pins(dp_bridge->dev, dp_data.conf, 0,
+ orientation = TYPEC_ORIENTATION_NORMAL;
+ if (dp_bridge->orientation &&
+ port->mux_flags & USB_PD_MUX_POLARITY_INVERTED)
+ orientation = TYPEC_ORIENTATION_REVERSE;
+
+ ret = drm_dp_typec_bridge_assign_pins(dp_bridge->dev, dp_data.conf,
+ orientation,
port->lane_mapping);
if (ret)
return ret;
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* [PATCH v2 11/11] platform/chrome: cros_ec_typec: Handle lack of HPD information
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (9 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 10/11] platform/chrome: cros_ec_typec: Support DP orientation Stephen Boyd
@ 2024-08-15 0:34 ` Stephen Boyd
2024-08-16 22:12 ` [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-15 0:34 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
Some EC firmwares on Trogdor/Strongbad boards don't properly indicate
the state of DP HPD on a type-c port. Instead, the EC only indicates
that a type-c port has entered or exited DP mode. To make matters worse,
on these boards the DP signal is muxed between two USB type-c
connectors, so we can't use the DP entry of a port to figure out which
type-c port is actually displaying DP.
Read the state of the EC's analog mux from the hpd notification callback
to figure out which type-c port is displaying DP. This circumvents the
entire host command/message interface, because it doesn't work all the
time. Stash the hpd state into the port that's muxed, and then inject
that hpd state into the struct we get from the EC. Only do this when we
have the mux-gpios property in DT, indicating that we have to read the
EC gpio state to figure this out. For now we only support a single gpio
"bit", so there can only be two USB type-c ports.
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>
---
drivers/platform/chrome/cros_ec_typec.c | 107 +++++++++++++++++++++---
drivers/platform/chrome/cros_ec_typec.h | 1 +
2 files changed, 98 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_typec.c b/drivers/platform/chrome/cros_ec_typec.c
index 9b54b3288f5f..e6e33b7bb543 100644
--- a/drivers/platform/chrome/cros_ec_typec.c
+++ b/drivers/platform/chrome/cros_ec_typec.c
@@ -7,6 +7,7 @@
*/
#include <linux/acpi.h>
+#include <linux/gpio/consumer.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_graph.h>
@@ -28,6 +29,7 @@ struct cros_typec_dp_bridge {
struct cros_typec_data *typec_data;
struct drm_dp_typec_bridge_dev *dev;
struct cros_typec_port *active_port;
+ struct gpio_desc *mux_gpio;
bool orientation;
};
@@ -445,6 +447,43 @@ static int cros_typec_init_ports(struct cros_typec_data *typec)
return ret;
}
+static void cros_typec_dp_bridge_hpd_notify(struct drm_dp_typec_bridge_dev *typec_bridge_dev,
+ void *data, enum drm_connector_status status)
+{
+ struct cros_typec_dp_bridge *dp_bridge = data;
+ struct cros_typec_port *typec_port;
+ struct cros_typec_data *typec;
+ struct gpio_desc *mux_gpio;
+ struct device *dev;
+ int val;
+
+ typec = dp_bridge->typec_data;
+ typec_port = typec->ports[0];
+ dev = typec->dev;
+
+ /*
+ * Some ECs don't notify AP when HPD goes high or low so we have to
+ * read the EC GPIO that controls the mux to figure out which type-c
+ * port is connected to DP by the EC.
+ */
+ mux_gpio = dp_bridge->mux_gpio;
+ if (mux_gpio) {
+ val = gpiod_get_value_cansleep(mux_gpio);
+ if (val < 0) {
+ dev_err(dev, "Failed to read mux gpio for hpd notify\n");
+ return;
+ }
+
+ typec_port = typec->ports[val];
+ }
+
+ /* Proxy the connector status as the HPD state to replay later. */
+ typec_port->hpd_asserted = status == connector_status_connected;
+
+ /* Refresh port state. */
+ schedule_work(&typec->port_work);
+}
+
static int cros_typec_init_dp_bridge(struct cros_typec_data *typec)
{
struct device *dev = typec->dev;
@@ -471,12 +510,21 @@ static int cros_typec_init_dp_bridge(struct cros_typec_data *typec)
dp_bridge->typec_data = typec;
dp_bridge->orientation = fwnode_property_read_bool(devnode, "orientation");
+ dp_bridge->mux_gpio = devm_gpiod_get_optional(dev, "mux", GPIOD_ASIS);
+ if (IS_ERR(dp_bridge->mux_gpio))
+ return dev_err_probe(dev, PTR_ERR(dp_bridge->mux_gpio), "failed to get mux gpio\n");
num_lanes = fwnode_property_count_u32(ep, "data-lanes");
if (num_lanes < 0)
num_lanes = 4;
desc.num_dp_lanes = num_lanes;
+ desc.no_hpd = fwnode_property_read_bool(devnode, "no-hpd");
+ if (desc.no_hpd) {
+ desc.hpd_notify = cros_typec_dp_bridge_hpd_notify;
+ desc.hpd_data = dp_bridge;
+ }
+
dp_dev = devm_drm_dp_typec_bridge_alloc(dev, &desc);
if (IS_ERR(dp_dev))
return PTR_ERR(dp_dev);
@@ -582,6 +630,7 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
struct ec_response_usb_pd_control_v2 *pd_ctrl)
{
struct cros_typec_port *port = typec->ports[port_num];
+ struct cros_typec_port *muxed_port;
struct cros_typec_dp_bridge *dp_bridge = typec->dp_bridge;
struct typec_displayport_data dp_data;
u32 cable_tbt_vdo;
@@ -589,6 +638,9 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
int ret;
enum typec_orientation orientation;
bool hpd_asserted = port->mux_flags & USB_PD_MUX_HPD_LVL;
+ bool is_active_port = false;
+ struct gpio_desc *mux_gpio;
+ int val;
if (typec->pd_ctrl_ver < 2) {
dev_err(typec->dev,
@@ -596,15 +648,47 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
return -ENOTSUPP;
}
- /*
- * Assume the first port to have HPD asserted is the one muxed to DP
- * (i.e. active_port). When there's only one port this delays setting
- * the active_port until HPD is asserted, but before that the
- * drm_connector looks disconnected so active_port doesn't need to be
- * set.
- */
- if (dp_bridge && hpd_asserted && !dp_bridge->active_port)
- dp_bridge->active_port = port;
+ if (dp_bridge) {
+ /*
+ * Some ECs don't notify AP when HPD goes high or low so we have to
+ * read the EC GPIO that controls the mux to figure out which type-c
+ * port is connected to DP by the EC.
+ */
+ mux_gpio = dp_bridge->mux_gpio;
+ if (mux_gpio) {
+ /*
+ * Only read the mux GPIO setting if hpd is asserted
+ * and we need to change the active_port. Otherwise, an
+ * active_port is already set and HPD going high or low
+ * doesn't change the muxed port until DP mode is
+ * exited.
+ */
+ if (hpd_asserted && !dp_bridge->active_port) {
+ val = gpiod_get_value_cansleep(mux_gpio);
+ if (val < 0) {
+ dev_err(typec->dev, "Failed to read mux gpio\n");
+ return val;
+ }
+
+ muxed_port = typec->ports[val];
+ }
+ } else {
+ muxed_port = port;
+ }
+
+ /*
+ * Assume the first port to have HPD asserted is the one muxed
+ * to DP (i.e. active_port). When there's only one port this
+ * delays setting the active_port until HPD is asserted, but
+ * before that the drm_connector looks disconnected so
+ * active_port doesn't need to be set.
+ */
+ if (hpd_asserted && !dp_bridge->active_port && muxed_port == port)
+ dp_bridge->active_port = port;
+
+ if (dp_bridge->active_port == port)
+ is_active_port = true;
+ }
if (!pd_ctrl->dp_mode) {
dev_err(typec->dev, "No valid DP mode provided.\n");
@@ -627,7 +711,7 @@ static int cros_typec_enable_dp(struct cros_typec_data *typec,
return ret;
}
- if (dp_bridge && dp_bridge->active_port == port) {
+ if (is_active_port) {
orientation = TYPEC_ORIENTATION_NORMAL;
if (dp_bridge->orientation &&
port->mux_flags & USB_PD_MUX_POLARITY_INVERTED)
@@ -729,6 +813,9 @@ static int cros_typec_configure_mux(struct cros_typec_data *typec, int port_num,
}
dp_enabled = resp.flags & USB_PD_MUX_DP_ENABLED;
+ /* Replay HPD from the GPIO state if EC firmware is broken */
+ if (dp_enabled && port->hpd_asserted)
+ resp.flags |= USB_PD_MUX_HPD_LVL;
/* No change needs to be made, let's exit early. */
if (port->mux_flags == resp.flags && port->role == pd_ctrl->role)
diff --git a/drivers/platform/chrome/cros_ec_typec.h b/drivers/platform/chrome/cros_ec_typec.h
index 74d062dc03b2..26565cd77d79 100644
--- a/drivers/platform/chrome/cros_ec_typec.h
+++ b/drivers/platform/chrome/cros_ec_typec.h
@@ -69,6 +69,7 @@ struct cros_typec_port {
uint8_t mux_flags;
uint8_t role;
+ bool hpd_asserted;
u32 lane_mapping[NUM_USB_SS];
struct typec_altmode *port_altmode[CROS_EC_ALTMODE_MAX];
--
https://chromeos.dev
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
` (10 preceding siblings ...)
2024-08-15 0:34 ` [PATCH v2 11/11] platform/chrome: cros_ec_typec: Handle lack of HPD information Stephen Boyd
@ 2024-08-16 22:12 ` Stephen Boyd
11 siblings, 0 replies; 14+ messages in thread
From: Stephen Boyd @ 2024-08-16 22:12 UTC (permalink / raw)
To: chrome-platform
Cc: linux-kernel, patches, devicetree, Douglas Anderson, Pin-yen Lin,
Andrzej Hajda, Benson Leung, Conor Dooley, Daniel Vetter,
David Airlie, Dmitry Baryshkov, dri-devel, Guenter Roeck,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Lee Jones, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Prashant Malani, Robert Foss, Rob Herring,
Thomas Zimmermann, Tzung-Bi Shih
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.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2 07/11] dt-bindings: chrome: Add ports to google,cros-ec-typec for DP altmode
2024-08-15 0:34 ` [PATCH v2 07/11] dt-bindings: chrome: Add ports to google, cros-ec-typec for DP altmode Stephen Boyd
@ 2024-08-21 16:12 ` Lee Jones
0 siblings, 0 replies; 14+ messages in thread
From: Lee Jones @ 2024-08-21 16:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: chrome-platform, linux-kernel, patches, devicetree,
Douglas Anderson, Pin-yen Lin, Andrzej Hajda, Benson Leung,
Conor Dooley, Daniel Vetter, David Airlie, Dmitry Baryshkov,
dri-devel, Guenter Roeck, Jernej Skrabec, Jonas Karlman,
Krzysztof Kozlowski, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Prashant Malani, Robert Foss,
Rob Herring, Thomas Zimmermann, Tzung-Bi Shih
On Wed, 14 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.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: 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>
Needs to be accompanied by a DT review:
Acked-by: Lee Jones <lee@kernel.org>
> ---
> .../bindings/chrome/google,cros-ec-typec.yaml | 260 ++++++++++++++++++
> .../bindings/mfd/google,cros-ec.yaml | 7 +-
> 2 files changed, 264 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> index 9f9816fbecbc..1238adfbea21 100644
> --- a/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> +++ b/Documentation/devicetree/bindings/chrome/google,cros-ec-typec.yaml
> @@ -26,6 +26,137 @@ properties:
> '#size-cells':
> const: 0
>
> + mux-gpios:
> + description: GPIOs indicating which way the DP mux is steered
> + maxItems: 1
> +
> + no-hpd:
> + description: Indicates this endpoint doesn't signal HPD for DisplayPort
> + type: boolean
> +
> + orientation:
> + description:
> + Indicates this endpoint assigns lanes based on altmode and
> + type-c port orientation
> + type: boolean
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + description:
> + Input port to receive DisplayPort (DP) data
> + unevaluatedProperties: false
> +
> + properties:
> + endpoint@0:
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + description: DisplayPort data for the type-c port(s)
> + unevaluatedProperties: false
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical DP data lane indexes
> + - 0 is DP ML0 lane
> + - 1 is DP ML1 lane
> + - 2 is DP ML2 lane
> + - 3 is DP ML3 lane
> + oneOf:
> + - items:
> + - const: 0
> + - const: 1
> + - items:
> + - const: 0
> + - const: 1
> + - const: 2
> + - const: 3
> +
> + required:
> + - endpoint@0
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port to receive USB SuperSpeed (SS) data
> + patternProperties:
> + "^endpoint@([0-8])$":
> + $ref: /schemas/graph.yaml#/properties/endpoint
> +
> + anyOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> + - required:
> + - endpoint@2
> + - required:
> + - endpoint@3
> + - required:
> + - endpoint@4
> + - required:
> + - endpoint@5
> + - required:
> + - endpoint@6
> + - required:
> + - endpoint@7
> + - required:
> + - endpoint@8
> +
> + port@2:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description: Output ports for combined DP and USB SS data
> + patternProperties:
> + "^endpoint@([0-8])$":
> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
> + unevaluatedProperties: false
> +
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description: |
> + An array of physical USB Type-C data lane indexes.
> + - 0 is SSRX1 lane
> + - 1 is SSTX1 lane
> + - 2 is SSTX2 lane
> + - 3 is SSRX2 lane
> + minItems: 4
> + maxItems: 4
> + items:
> + maximum: 3
> +
> + anyOf:
> + - required:
> + - endpoint@0
> + - required:
> + - endpoint@1
> + - required:
> + - endpoint@2
> + - required:
> + - endpoint@3
> + - required:
> + - endpoint@4
> + - required:
> + - endpoint@5
> + - required:
> + - endpoint@6
> + - required:
> + - endpoint@7
> + - required:
> + - endpoint@8
> +
> + required:
> + - port@2
> + anyOf:
> + - required:
> + - port@0
> + - required:
> + - port@1
> +
> patternProperties:
> '^connector@[0-9a-f]+$':
> $ref: /schemas/connector/usb-connector.yaml#
> @@ -35,6 +166,38 @@ patternProperties:
> required:
> - compatible
>
> +allOf:
> + - if:
> + properties:
> + no-hpd: true
> + required:
> + - no-hpd
> + then:
> + properties:
> + ports:
> + required:
> + - port@0
> + - if:
> + properties:
> + mux-gpios: true
> + required:
> + - mux-gpios
> + then:
> + properties:
> + ports:
> + required:
> + - port@0
> + - if:
> + properties:
> + orientation: true
> + required:
> + - orientation
> + then:
> + properties:
> + ports:
> + required:
> + - port@0
> +
> additionalProperties: false
>
> examples:
> @@ -60,6 +223,103 @@ examples:
> power-role = "dual";
> data-role = "dual";
> try-power-role = "source";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usb_c0_hs: endpoint {
> + remote-endpoint = <&usb_hub_dfp3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + usb_c0_ss: endpoint {
> + remote-endpoint = <&cros_typec_c0_ss>;
> + };
> + };
> + };
> + };
> +
> + connector@1 {
> + compatible = "usb-c-connector";
> + reg = <1>;
> + power-role = "dual";
> + data-role = "dual";
> + try-power-role = "source";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usb_c1_hs: endpoint {
> + remote-endpoint = <&usb_hub_dfp2_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + usb_c1_ss: endpoint {
> + remote-endpoint = <&cros_typec_c1_ss>;
> + };
> + };
> + };
> + };
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dp_in: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&dp_phy>;
> + data-lanes = <0 1>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usb_in_0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&usb_ss_0_out>;
> + };
> +
> + usb_in_1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&usb_ss_1_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cros_typec_c0_ss: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&usb_c0_ss>;
> + data-lanes = <0 1 2 3>;
> + };
> +
> + cros_typec_c1_ss: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&usb_c1_ss>;
> + data-lanes = <2 3 0 1>;
> + };
> + };
> };
> };
> };
> diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> index aac8819bd00b..c860eb7ed3f5 100644
> --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml
> @@ -98,9 +98,6 @@ properties:
>
> gpio-controller: true
>
> - typec:
> - $ref: /schemas/chrome/google,cros-ec-typec.yaml#
> -
> ec-pwm:
> $ref: /schemas/pwm/google,cros-ec-pwm.yaml#
> deprecated: true
> @@ -166,6 +163,10 @@ patternProperties:
> type: object
> $ref: /schemas/extcon/extcon-usbc-cros-ec.yaml#
>
> + "^typec(-[0-9])*$":
> + type: object
> + $ref: /schemas/chrome/google,cros-ec-typec.yaml#
> +
> required:
> - compatible
>
> --
> https://chromeos.dev
>
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2024-08-21 16:13 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-08-15 0:34 [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 01/11] drm/atomic-helper: Introduce lane remapping support to bridges Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 02/11] drm/bridge: Verify lane assignment is going to work during atomic_check Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 03/11] drm/bridge: aux-hpd: Support USB Type-C DP altmodes via DRM lane assignment Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 04/11] drm/bridge: dp_typec: Support USB Type-C orientation Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 05/11] drm/bridge: dp_typec: Add "no-hpd" support Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 06/11] drm/bridge: dp_typec: Allow users to hook hpd notify path Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 07/11] dt-bindings: chrome: Add ports to google, cros-ec-typec for DP altmode Stephen Boyd
2024-08-21 16:12 ` [PATCH v2 07/11] dt-bindings: chrome: Add ports to google,cros-ec-typec " Lee Jones
2024-08-15 0:34 ` [PATCH v2 08/11] platform/chrome: cros_ec_typec: Add support for signaling DP HPD via drm_bridge Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 09/11] platform/chrome: cros_ec_typec: Support DP muxing via DRM lane assignment Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 10/11] platform/chrome: cros_ec_typec: Support DP orientation Stephen Boyd
2024-08-15 0:34 ` [PATCH v2 11/11] platform/chrome: cros_ec_typec: Handle lack of HPD information Stephen Boyd
2024-08-16 22:12 ` [PATCH v2 00/11] platform/chrome: Add DT USB/DP muxing/topology support Stephen Boyd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).