On 07/15/2017 04:28 AM, Eric Anholt wrote:
Archit Taneja <architt@xxxxxxxxxxxxxx> writes:
On 06/28/2017 01:28 AM, Eric Anholt wrote:
When a mipi_dsi_host is registered, the DT is walked to find any child
nodes with compatible strings. Those get registered as DSI devices,
and most DSI panel drivers are mipi_dsi_drivers that attach to those nodes.
There is one special case currently, the adv7533 bridge, where the
bridge probes on I2C, and during the bridge attach step it looks up
the mipi_dsi_host and registers the mipi_dsi_device (for its own stub
mipi_dsi_driver).
For the Raspberry Pi panel, though, we also need to attach on I2C (our
control bus), but don't have a bridge driver. The lack of a bridge's
attach() step like adv7533 uses means that we aren't able to delay the
mipi_dsi_device creation until the mipi_dsi_host is present.
To fix this, we extend mipi_dsi_device_register_full() to allow being
called with a NULL host, which puts the device on a queue waiting for
a host to appear. When a new host is registered, we fill in the host
value and finish the device creation process.
This is quite a nice idea. The only bothering thing is the info.of_node usage
varies between child nodes (mipi_dsi_devs) and non-child nodes (i2c control
bus).
For DSI children expressed in DT, the of_node in info holds the DT node
corresponding to the DSI child itself. For non-DT ones, this patch assumes
that info.of_node stores the DSI host DT node. I think it should be okay as
long as we mention the usage in a comment somewhere. The other option is to
have a new info.host_node field to keep a track of the host DT node.
I think maybe you misread the patch? We're using
of_get_parent(dsi->dev.node), which came from info->node, to compare to
host->dev->of_node().
I think I did misread it.
Although, I'm not entirely clear what we should be setting info.node to.
In patch #8, info.node is set by:
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
info.node = of_graph_get_remote_port(endpoint);
Looking at the dt bindings in patch #7, it looks like info.node is set
to the 'port' device node in dsi@7e700000, is that right?
I suppose 'port' here seems like a reasonable representation of
dsi->dev.node, I wonder how it would work if the dsi host had multiple
ports underneath it. I.e:
dsi@7e700000 {
...
...
ports {
port@0 {
...
dsi_out_port: endpoint {
remote-endpoint = <&panel_dsi_port>;
};
};
port@1 {
...
...
};
};
};
Here, we would need to set info.node to the 'ports' node, so that
of_get_parent(dsi->dev.of_node) equals host->dev->of_node. That doesn't
seem correct.
Ideally, a dev's 'of_node' should be left to NULL if we don't have a
corresponding OF node. We're sort of overriding it here since we don't
have any other place to store this information in the mipi_dsi_device
struct.
Maybe we could add a 'host_node' entry in mipi_dsi_device itself, which
is exclusively used cases where the DSI device doesn't have a DT node.
Our check in mipi_dsi_host_register() could then be something like:
if (dsi->host_node) == host->dev->of_node) {
...
...
}
Since Thierry also reviews drm_mipi_dsi.c changes, it would nice to
get some comments from him too.
Thanks,
Archit
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
