On Sat, Aug 31, 2024 at 09:06:44PM -0700, Stephen Boyd wrote:
> Extend the aux-hpd bridge driver to support assigning DP lanes to USB
> type-c pins based on typec mux state entry. 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
Isn't the proper spelling "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.
>
> Parse the struct typec_mux_state members to determine if DP altmode has
> been entered and if HPD is asserted or not. Signal HPD to the drm bridge
> chain when HPD is asserted. Similarly, parse the pin assignment and map
> the DP lanes to the usb-c output lanes, taking into account any lane
> remapping from the data-lanes endpoint property. Pass that lane mapping
> to the previous drm_bridge in the bridge chain during the atomic check
> phase.
...
> +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);
+ container_of.h ?
With that said, can the argument be const here?
> +}
...
Ditto for the two more helpers, added in this change.
...
> +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);
I'm wondering why it's not made fwnode to begin with...
