Message ID | 20230322104639.221402-1-treapking@chromium.org |
---|---|
Headers | show |
Series | Register Type-C mode-switch in DP bridge endpoints | expand |
On Wed, Mar 22, 2023 at 06:46:32PM +0800, Pin-yen Lin wrote: > Add helpers to register and unregister Type-C "switches" for bridges > capable of switching their output between two downstream devices. > > The helper registers USB Type-C mode switches when the "mode-switch" > and the "reg" properties are available in Device Tree. ... > +config DRM_DISPLAY_DP_TYPEC_HELPER > + bool > + default y def_bool y > + depends on DRM_DISPLAY_HELPER > + depends on DRM_DISPLAY_HELPER=TYPEC || TYPEC=y > + help > + DRM display helpers for USB Type-C Displayport Alternate mode. Hmm... Dunno if this help is enough. ... > + snprintf(name, sizeof(name), "%pfwP-%u", fwnode, port_num); Would it be possible to have a dup in name and would it be a problem if so? ... > +/** > + * drm_dp_register_typec_switches() - register Type-C switches > + * @dev: Device that registers Type-C switches > + * @port: Device node for the switch > + * @switch_desc: A Type-C switch descriptor > + * @data: Private data for the switches > + * @mux_set: Callback function for typec_mux_set > + * > + * This function registers USB Type-C switches for DP bridges that can switch > + * the output signal between their output pins. This function uses devm_kcalloc > + * to allocate memory, so it is expected to only call this in the driver probe > + * functions. > + * > + * Currently only mode switches are implemented, and the function assumes the > + * given @port device node has endpoints with "mode-switch" property. > + * The port number is determined by the "reg" property of the endpoint. `kernel-doc -v ...` should complain on absence of "Return" section. > + */ ... > + switch_desc->typec_ports = devm_kcalloc(dev, switch_desc->num_typec_switches, > + sizeof(struct drm_dp_typec_port_data), sizeof(*switch_desc_typec_ports), ? > + GFP_KERNEL); > + if (!switch_desc->typec_ports) > + return -ENOMEM; ... > +#ifdef CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER Ah, maybe this should use IS_REACHABLE() ? > +void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc); > +int drm_dp_register_typec_switches(struct device *dev, struct fwnode_handle *port, > + struct drm_dp_typec_switch_desc *switch_desc, > + void *data, typec_mux_set_fn_t mux_set); > +#else > +static inline void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc) > +{ > +} > +static inline int drm_dp_register_typec_switches( > + struct device *dev, struct fwnode_handle *port, > + struct drm_dp_typec_switch_desc *switch_desc, void *data, > + typec_mux_set_fn_t mux_set) > +{ > + return -EOPNOTSUPP; > +} > +#endif
On Wed, Mar 22, 2023 at 06:46:36PM +0800, Pin-yen Lin wrote: > Register USB Type-C mode switches when the "mode-switch" property and > relevant ports are available in Device Tree. Configure the crosspoint > switch based on the entered alternate mode for a specific Type-C > connector. > > Crosspoint switch can also be used for switching the output signal for > different orientations of a single USB Type-C connector, but the > orientation switch is not implemented yet. A TODO is added for this. ... > +static int anx7625_typec_mux_set(struct typec_mux_dev *mux, > + struct typec_mux_state *state) > +{ > + struct drm_dp_typec_port_data *port = typec_mux_get_drvdata(mux); > + struct anx7625_data *ctx = port->data; > + struct device *dev = ctx->dev; > + struct drm_dp_typec_switch_desc switch_desc = ctx->switch_desc; > + bool new_dp_connected, old_dp_connected; > + > + if (switch_desc.num_typec_switches == 1) > + return 0; > + wait_for_completion(&ctx->mux_register); How do we guarantee this won't become an infinite waiting? Perhaps a comment explaining that? > + old_dp_connected = ctx->port_data[0].dp_connected || > + ctx->port_data[1].dp_connected; > + > + ctx->port_data[port->port_num].dp_connected = > + state->alt && > + state->alt->svid == USB_TYPEC_DP_SID && > + state->alt->mode == USB_TYPEC_DP_MODE; > + > + dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n", > + ctx->port_data[0].dp_connected, ctx->port_data[1].dp_connected); > + > + new_dp_connected = ctx->port_data[0].dp_connected || > + ctx->port_data[1].dp_connected; > + > + /* DP on, power on first */ > + if (!old_dp_connected && new_dp_connected) > + pm_runtime_get_sync(dev); > + > + anx7625_typec_two_ports_update(ctx); > + > + /* DP off, power off last */ > + if (old_dp_connected && !new_dp_connected) > + pm_runtime_put_sync(dev); > + > + return 0; > +} ... > + struct device_node *port_node = of_graph_get_port_by_id(dev->of_node, 1); You use fwnode below, so why not fwnode_graph_...(dev_fwnode(dev), ...) ? > + struct drm_dp_typec_switch_desc *switch_desc = &ctx->switch_desc; > + int ret; > + u32 dp_lanes[4]; > + unsigned int i, num_lanes; > + > + /* > + * Currently, only mode switch is implemented. > + * TODO: Implement Type-C orientation switch for anx7625. > + */ > + ret = drm_dp_register_typec_switches(dev, &port_node->fwnode, > + &ctx->switch_desc, ctx, > + anx7625_typec_mux_set); > + if (ret) > + return ret; > + > + ctx->port_data = devm_kcalloc(dev, switch_desc->num_typec_switches, > + sizeof(struct anx7625_typec_port_data), sizeof(*ctx->port_data), ? > + GFP_KERNEL); > + if (!ctx->port_data) { > + ret = -ENOMEM; > + goto unregister_mux; > + } ... > +struct anx7625_typec_port_data { > + bool dp_connected; > + enum typec_orientation orientation; Most likely enum will be 32-bit and bool 8-bit. Which means that the data type size become 8 bytes for no reason. Can you swap the lines and perhaps check this with `pahole` tool? > +};
Il 22/03/23 11:46, Pin-yen Lin ha scritto: > The output port endpoints can be connected to USB-C connectors. > Running drm_of_find_panel_or_bridge() with such endpoints leads to > a continuous return value of -EPROBE_DEFER, even though there is > no panel present. > > To avoid this, check for the existence of a "mode-switch" property in > the port endpoint, and skip panel registration completely if so. > > Signed-off-by: Pin-yen Lin <treapking@chromium.org> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
On Thu, Mar 23, 2023 at 12:38:49AM +0200, Dmitry Baryshkov wrote: > On Wed, 22 Mar 2023 at 12:47, Pin-yen Lin <treapking@chromium.org> wrote: ... > > +config DRM_DISPLAY_DP_TYPEC_HELPER > > + bool > > + default y > > + depends on DRM_DISPLAY_HELPER > > + depends on DRM_DISPLAY_HELPER=TYPEC || TYPEC=y > > If it is a select'able option, it doesn't make sense to use "depends" > here. Select will override depends. He-he, not so easy. This will help to find configurations that miss these dependencies. Arnd taught me that. IIRC the ASoC subsystem has a lot of such cases. > > + help > > + DRM display helpers for USB Type-C Displayport Alternate mode.
Hi Andy, Thanks for the review. On Wed, Mar 22, 2023 at 8:01 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Wed, Mar 22, 2023 at 06:46:32PM +0800, Pin-yen Lin wrote: > > Add helpers to register and unregister Type-C "switches" for bridges > > capable of switching their output between two downstream devices. > > > > The helper registers USB Type-C mode switches when the "mode-switch" > > and the "reg" properties are available in Device Tree. > > ... > > > +config DRM_DISPLAY_DP_TYPEC_HELPER > > > + bool > > + default y > > def_bool y > > > + depends on DRM_DISPLAY_HELPER > > + depends on DRM_DISPLAY_HELPER=TYPEC || TYPEC=y > > + help > > + DRM display helpers for USB Type-C Displayport Alternate mode. > > Hmm... Dunno if this help is enough. Okay I'll add more detail in the next version. > > ... > > > + snprintf(name, sizeof(name), "%pfwP-%u", fwnode, port_num); > > Would it be possible to have a dup in name and would it be a problem if so? > The port_num is included in the name, so the names should be unique. Also, the fwnode name actually contains the reg property, so this name looks like "endpoint@0-1" now... I'll change the name from fwnode name to dev_name() per Dmitry's comment. > ... > > > +/** > > + * drm_dp_register_typec_switches() - register Type-C switches > > + * @dev: Device that registers Type-C switches > > + * @port: Device node for the switch > > + * @switch_desc: A Type-C switch descriptor > > + * @data: Private data for the switches > > + * @mux_set: Callback function for typec_mux_set > > + * > > + * This function registers USB Type-C switches for DP bridges that can switch > > + * the output signal between their output pins. This function uses devm_kcalloc > > + * to allocate memory, so it is expected to only call this in the driver probe > > + * functions. > > + * > > + * Currently only mode switches are implemented, and the function assumes the > > + * given @port device node has endpoints with "mode-switch" property. > > + * The port number is determined by the "reg" property of the endpoint. > > `kernel-doc -v ...` should complain on absence of "Return" section. > > > + */ > > ... > > > + switch_desc->typec_ports = devm_kcalloc(dev, switch_desc->num_typec_switches, > > + sizeof(struct drm_dp_typec_port_data), > > sizeof(*switch_desc_typec_ports), > > ? > > > + GFP_KERNEL); > > + if (!switch_desc->typec_ports) > > + return -ENOMEM; > > ... > > > +#ifdef CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER > > Ah, maybe this should use IS_REACHABLE() ? CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER is a boolean. Is there any difference between IS_REACHABLE and ifdef when the given config is a boolean? > > > +void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc); > > +int drm_dp_register_typec_switches(struct device *dev, struct fwnode_handle *port, > > + struct drm_dp_typec_switch_desc *switch_desc, > > + void *data, typec_mux_set_fn_t mux_set); > > +#else > > +static inline void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc) > > +{ > > +} > > +static inline int drm_dp_register_typec_switches( > > + struct device *dev, struct fwnode_handle *port, > > + struct drm_dp_typec_switch_desc *switch_desc, void *data, > > + typec_mux_set_fn_t mux_set) > > +{ > > + return -EOPNOTSUPP; > > +} > > +#endif > > -- > With Best Regards, > Andy Shevchenko > Best regards, Pin-yen >
On Fri, Mar 31, 2023 at 11:36 AM Pin-yen Lin <treapking@chromium.org> wrote: > > Hi Andy, > > Thanks for the review. > > On Wed, Mar 22, 2023 at 8:01 PM Andy Shevchenko > <andriy.shevchenko@linux.intel.com> wrote: > > > > On Wed, Mar 22, 2023 at 06:46:32PM +0800, Pin-yen Lin wrote: > > > Add helpers to register and unregister Type-C "switches" for bridges > > > capable of switching their output between two downstream devices. > > > > > > The helper registers USB Type-C mode switches when the "mode-switch" > > > and the "reg" properties are available in Device Tree. > > > > ... > > > > > +config DRM_DISPLAY_DP_TYPEC_HELPER > > > > > + bool > > > + default y > > > > def_bool y > > > > > + depends on DRM_DISPLAY_HELPER > > > + depends on DRM_DISPLAY_HELPER=TYPEC || TYPEC=y > > > + help > > > + DRM display helpers for USB Type-C Displayport Alternate mode. > > > > Hmm... Dunno if this help is enough. > > Okay I'll add more detail in the next version. > > > > ... > > > > > + snprintf(name, sizeof(name), "%pfwP-%u", fwnode, port_num); > > > > Would it be possible to have a dup in name and would it be a problem if so? > > > The port_num is included in the name, so the names should be unique. > Also, the fwnode name actually contains the reg property, so this name > looks like "endpoint@0-1" now... I'll change the name from fwnode name This should be "endpoint@0-0", or "endpoint@1-1@. The `port_num` value has the same number as the `reg` property > to dev_name() per Dmitry's comment. > > ... > > > > > +/** > > > + * drm_dp_register_typec_switches() - register Type-C switches > > > + * @dev: Device that registers Type-C switches > > > + * @port: Device node for the switch > > > + * @switch_desc: A Type-C switch descriptor > > > + * @data: Private data for the switches > > > + * @mux_set: Callback function for typec_mux_set > > > + * > > > + * This function registers USB Type-C switches for DP bridges that can switch > > > + * the output signal between their output pins. This function uses devm_kcalloc > > > + * to allocate memory, so it is expected to only call this in the driver probe > > > + * functions. > > > + * > > > + * Currently only mode switches are implemented, and the function assumes the > > > + * given @port device node has endpoints with "mode-switch" property. > > > + * The port number is determined by the "reg" property of the endpoint. > > > > `kernel-doc -v ...` should complain on absence of "Return" section. > > > > > + */ > > > > ... > > > > > + switch_desc->typec_ports = devm_kcalloc(dev, switch_desc->num_typec_switches, > > > + sizeof(struct drm_dp_typec_port_data), > > > > sizeof(*switch_desc_typec_ports), > > > > ? > > > > > + GFP_KERNEL); > > > + if (!switch_desc->typec_ports) > > > + return -ENOMEM; > > > > ... > > > > > +#ifdef CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER > > > > Ah, maybe this should use IS_REACHABLE() ? > > CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER is a boolean. Is there any > difference between IS_REACHABLE and ifdef when the given config is a > boolean? > > > > > +void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc); > > > +int drm_dp_register_typec_switches(struct device *dev, struct fwnode_handle *port, > > > + struct drm_dp_typec_switch_desc *switch_desc, > > > + void *data, typec_mux_set_fn_t mux_set); > > > +#else > > > +static inline void drm_dp_unregister_typec_switches(struct drm_dp_typec_switch_desc *switch_desc) > > > +{ > > > +} > > > +static inline int drm_dp_register_typec_switches( > > > + struct device *dev, struct fwnode_handle *port, > > > + struct drm_dp_typec_switch_desc *switch_desc, void *data, > > > + typec_mux_set_fn_t mux_set) > > > +{ > > > + return -EOPNOTSUPP; > > > +} > > > +#endif > > > > -- > > With Best Regards, > > Andy Shevchenko > > > > Best regards, > Pin-yen > >
Hi Andy, Thanks for the review. On Wed, Mar 22, 2023 at 8:16 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Wed, Mar 22, 2023 at 06:46:36PM +0800, Pin-yen Lin wrote: > > Register USB Type-C mode switches when the "mode-switch" property and > > relevant ports are available in Device Tree. Configure the crosspoint > > switch based on the entered alternate mode for a specific Type-C > > connector. > > > > Crosspoint switch can also be used for switching the output signal for > > different orientations of a single USB Type-C connector, but the > > orientation switch is not implemented yet. A TODO is added for this. > > ... > > > +static int anx7625_typec_mux_set(struct typec_mux_dev *mux, > > + struct typec_mux_state *state) > > +{ > > + struct drm_dp_typec_port_data *port = typec_mux_get_drvdata(mux); > > + struct anx7625_data *ctx = port->data; > > + struct device *dev = ctx->dev; > > + struct drm_dp_typec_switch_desc switch_desc = ctx->switch_desc; > > + bool new_dp_connected, old_dp_connected; > > + > > + if (switch_desc.num_typec_switches == 1) > > + return 0; > > > + wait_for_completion(&ctx->mux_register); > > How do we guarantee this won't become an infinite waiting? > Perhaps a comment explaining that? > > > + old_dp_connected = ctx->port_data[0].dp_connected || > > + ctx->port_data[1].dp_connected; > > + > > + ctx->port_data[port->port_num].dp_connected = > > + state->alt && > > + state->alt->svid == USB_TYPEC_DP_SID && > > + state->alt->mode == USB_TYPEC_DP_MODE; > > + > > + dev_dbg(dev, "mux_set dp_connected: c0=%d, c1=%d\n", > > + ctx->port_data[0].dp_connected, ctx->port_data[1].dp_connected); > > + > > + new_dp_connected = ctx->port_data[0].dp_connected || > > + ctx->port_data[1].dp_connected; > > + > > + /* DP on, power on first */ > > + if (!old_dp_connected && new_dp_connected) > > + pm_runtime_get_sync(dev); > > + > > + anx7625_typec_two_ports_update(ctx); > > + > > + /* DP off, power off last */ > > + if (old_dp_connected && !new_dp_connected) > > + pm_runtime_put_sync(dev); > > + > > + return 0; > > +} > > ... > > > + struct device_node *port_node = of_graph_get_port_by_id(dev->of_node, 1); > > You use fwnode below, so why not fwnode_graph_...(dev_fwnode(dev), ...) ? There is no existing helper like `fwnode_graph_get_port_by_id`, so using of_graph variant is easier here. Should I add a `fwnode_graph_get_port_by_id` helper for this? > > > + struct drm_dp_typec_switch_desc *switch_desc = &ctx->switch_desc; > > + int ret; > > + u32 dp_lanes[4]; > > + unsigned int i, num_lanes; > > + > > + /* > > + * Currently, only mode switch is implemented. > > + * TODO: Implement Type-C orientation switch for anx7625. > > + */ > > + ret = drm_dp_register_typec_switches(dev, &port_node->fwnode, > > + &ctx->switch_desc, ctx, > > + anx7625_typec_mux_set); > > + if (ret) > > + return ret; > > + > > + ctx->port_data = devm_kcalloc(dev, switch_desc->num_typec_switches, > > + sizeof(struct anx7625_typec_port_data), > > sizeof(*ctx->port_data), > > ? > > > + GFP_KERNEL); > > + if (!ctx->port_data) { > > + ret = -ENOMEM; > > + goto unregister_mux; > > + } > > ... > > > +struct anx7625_typec_port_data { > > + bool dp_connected; > > + enum typec_orientation orientation; > > Most likely enum will be 32-bit and bool 8-bit. Which means that the data type > size become 8 bytes for no reason. Can you swap the lines and perhaps check this > with `pahole` tool? > > > +}; > > -- > With Best Regards, > Andy Shevchenko > > Best regards, Pin-yen