[PATCH V10 1/4] drm: of: Add drm_of_get_dsi_bus helper function

[Maxime Ripard]

On Tue, Jan 17, 2023 at 01:12:39PM -0600, Chris Morgan wrote:
> On Tue, Jan 17, 2023 at 05:58:19PM +0100, Maxime Ripard wrote:
> > Hi,
> > 
> > On Thu, Jan 12, 2023 at 11:53:55AM -0600, Chris Morgan wrote:
> > > From: Chris Morgan <macromorgan at hotmail.com>
> > > 
> > > Add helper function to find DSI host for devices where DSI panel is not
> > > a minor of a DSI bus (such as the Samsung AMS495QA01 panel or the
> > > official Raspberry Pi touchscreen display).
> > > 
> > > Signed-off-by: Chris Morgan <macromorgan at hotmail.com>
> > > Signed-off-by: Maya Matuszczyk <maccraft123mc at gmail.com>
> > > ---
> > >  drivers/gpu/drm/drm_of.c | 70 ++++++++++++++++++++++++++++++++++++++++
> > >  include/drm/drm_of.h     | 10 ++++++
> > >  2 files changed, 80 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> > > index 7bbcb999bb75..6c2c97a716fe 100644
> > > --- a/drivers/gpu/drm/drm_of.c
> > > +++ b/drivers/gpu/drm/drm_of.c
> > > @@ -10,6 +10,7 @@
> > >  #include <drm/drm_crtc.h>
> > >  #include <drm/drm_device.h>
> > >  #include <drm/drm_encoder.h>
> > > +#include <drm/drm_mipi_dsi.h>
> > >  #include <drm/drm_of.h>
> > >  #include <drm/drm_panel.h>
> > >  
> > > @@ -493,3 +494,72 @@ int drm_of_get_data_lanes_count_ep(const struct device_node *port,
> > >  	return ret;
> > >  }
> > >  EXPORT_SYMBOL_GPL(drm_of_get_data_lanes_count_ep);
> > > +
> > > +#if IS_ENABLED(CONFIG_DRM_MIPI_DSI)
> > > +
> > > +/**
> > > + * drm_of_get_dsi_bus - find the DSI bus for a given device
> > > + * @dev: parent device of display (SPI, I2C)
> > > + * @info: DSI device info to be updated with DSI node. This is optional
> > > + * and if not needed can be NULL.
> > > + *
> > > + * Gets parent DSI bus for a DSI device controlled through a bus other
> > > + * than MIPI-DCS (SPI, I2C, etc.) using the Device Tree.
> > > + *
> > > + * Returns pointer to mipi_dsi_host if successful, -EINVAL if the
> > > + * request is unsupported, -EPROBE_DEFER if the DSI host is found but
> > > + * not available, or -ENODEV otherwise.
> > > + */
> > > +struct mipi_dsi_host *drm_of_get_dsi_bus(struct device *dev,
> > > +					 struct mipi_dsi_device_info *info)
> > > +{
> > > +	struct mipi_dsi_host *dsi_host;
> > > +	struct device_node *endpoint, *dsi_host_node;
> > > +
> > > +	/*
> > > +	 * Get first endpoint child from device.
> > > +	 */
> > > +	endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> > > +	if (!endpoint)
> > > +		return ERR_PTR(-ENODEV);
> > > +
> > > +	/*
> > > +	 * Follow the first endpoint to get the DSI host node.
> > > +	 */
> > > +	dsi_host_node = of_graph_get_remote_port_parent(endpoint);
> > > +	if (!dsi_host_node)
> > > +		goto error;
> > > +
> > > +	/*
> > > +	 * Get the DSI host from the DSI host node. If we get an error
> > > +	 * or the return is null assume we're not ready to probe just
> > > +	 * yet. Release the DSI host node since we're done with it.
> > > +	 */
> > > +	dsi_host = of_find_mipi_dsi_host_by_node(dsi_host_node);
> > > +	of_node_put(dsi_host_node);
> > > +	if (IS_ERR_OR_NULL(dsi_host)) {
> > > +		of_node_put(endpoint);
> > > +		return ERR_PTR(-EPROBE_DEFER);
> > > +	}
> > > +
> > > +	/*
> > > +	 * Set the node of the mipi_dsi_device_info to the correct node
> > > +	 * and then release the endpoint node since we're done with it.
> > > +	 * since this is optional, check if the info is NULL first.
> > > +	 */
> > > +	if (info) {
> > > +		info->node = of_graph_get_remote_port(endpoint);
> > 
> > it looks to me that the info->node is actually the DSI device OF node,
> > not its host port. Which begs the question, why should we even return it
> > there, since there's a pretty big chance that dev->of.node ==
> > info->node, and you obviously don't care about the channel and type fields.
> > 
> > I've had a look and node of the current users of
> > mipi_dsi_device_register_full actually register a mipi_dsi_device_info
> > with a node pointer set to !NULL, including the driver in this series.
> > 
> > So, why do we care about the device info at all?
>
> I honestly thought it might be useful, but I can try without it.

It might tbh, but it doesn't look like you use it in your driver. You have:

struct mipi_dsi_device_info info = {
	.type = "d53e6ea8966",
	.channel = 0,
	.node = NULL,
};

...

// info.node is NULL so far
dsi_host = drm_of_get_dsi_bus(dev, &info);

...

// info.node has been filled to the port node by drm_of_get_dsi_bus()
db->dsi_dev = devm_mipi_dsi_device_register_full(dev, dsi_host, &info);

// db->dsi_dev.dev.of_node is now set to the port node

But if we grep through drm_mipi_dsi.c, we can see that the of_node is
only really useful if we're using of_find_mipi_dsi_device_by_node, and
it looks like you don't.

So nothing uses info->node, which also explains why not reporting the
proper node has been working.

Looking more into the code, it really looks to me that info->node should
be equal to the your panel device tree node, that's what
of_mipi_dsi_device_add does at least.

if info->node == dev->of_node, and if info->node is the only thing
filled by drm_of_get_dsi_bus(), then it doesn't need to fill it at all
because it's already accessible easily to the caller (and even more
easily than to the callee).

So yeah, until we have a real-world need to retrieve the info function I
think we should leave it aside for now, and we can always change the API
later if we need to.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-rockchip/attachments/20230118/2f3171e3/attachment-0001.sig>