All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Anholt <eric@anholt.net>
To: Archit Taneja <architt@codeaurora.org>,
	dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Boris Brezillon <boris.brezillon@free-electrons.com>
Subject: Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.
Date: Tue, 18 Jul 2017 13:13:04 -0700	[thread overview]
Message-ID: <87mv81bj1r.fsf@eliezer.anholt.net> (raw)
In-Reply-To: <c187aa6c-6817-ca5b-7b1b-450f82fccf93@codeaurora.org>

[-- Attachment #1: Type: text/plain, Size: 4839 bytes --]

Archit Taneja <architt@codeaurora.org> writes:

> On 07/15/2017 04:28 AM, Eric Anholt wrote:
>> Archit Taneja <architt@codeaurora.org> 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?

Yeah.


> 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:

I think instead of extending the struct, we can just walk to the parent
similarly to how of_graph_get_remove_port_parent() does.  And fix some
node refcounting at the same time:

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index ed3d505dc203..77d439254da6 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -313,7 +313,12 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
         * connect our host to it and probe them now.
         */
        list_for_each_entry_safe(dsi, temp, &unattached_device_list, list) {
-               if (of_get_parent(dsi->dev.of_node) == host->dev->of_node) {
+               struct device_node *host_node = of_get_parent(dsi->dev.of_node);
+
+               if (!of_node_cmp(host_node->name, "ports"))
+                       host_node = of_get_next_parent(host_node);
+
+               if (host_node == host->dev->of_node) {
                        dsi->host = host;
                        dsi->dev.parent = host->dev;
                        device_initialize(&dsi->dev);
@@ -321,6 +326,8 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
                        mipi_dsi_device_add(dsi);
                        list_del_init(&dsi->list);
                }
+
+               of_node_put(host_node);
        }
        mutex_unlock(&host_lock);
 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Eric Anholt <eric@anholt.net>
To: Archit Taneja <architt@codeaurora.org>,
	dri-devel@lists.freedesktop.org,
	Andrzej Hajda <a.hajda@samsung.com>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers.
Date: Tue, 18 Jul 2017 13:13:04 -0700	[thread overview]
Message-ID: <87mv81bj1r.fsf@eliezer.anholt.net> (raw)
In-Reply-To: <c187aa6c-6817-ca5b-7b1b-450f82fccf93@codeaurora.org>


[-- Attachment #1.1: Type: text/plain, Size: 4839 bytes --]

Archit Taneja <architt@codeaurora.org> writes:

> On 07/15/2017 04:28 AM, Eric Anholt wrote:
>> Archit Taneja <architt@codeaurora.org> 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?

Yeah.


> 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:

I think instead of extending the struct, we can just walk to the parent
similarly to how of_graph_get_remove_port_parent() does.  And fix some
node refcounting at the same time:

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index ed3d505dc203..77d439254da6 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -313,7 +313,12 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
         * connect our host to it and probe them now.
         */
        list_for_each_entry_safe(dsi, temp, &unattached_device_list, list) {
-               if (of_get_parent(dsi->dev.of_node) == host->dev->of_node) {
+               struct device_node *host_node = of_get_parent(dsi->dev.of_node);
+
+               if (!of_node_cmp(host_node->name, "ports"))
+                       host_node = of_get_next_parent(host_node);
+
+               if (host_node == host->dev->of_node) {
                        dsi->host = host;
                        dsi->dev.parent = host->dev;
                        device_initialize(&dsi->dev);
@@ -321,6 +326,8 @@ int mipi_dsi_host_register(struct mipi_dsi_host *host)
                        mipi_dsi_device_add(dsi);
                        list_del_init(&dsi->list);
                }
+
+               of_node_put(host_node);
        }
        mutex_unlock(&host_lock);
 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-07-18 20:13 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27 19:58 [PATCH 0/8] RPi touchscreen panel driver v4 Eric Anholt
2017-06-27 19:58 ` Eric Anholt
2017-06-27 19:58 ` [PATCH 1/8] drm/vc4: Fix DSI T_INIT timing Eric Anholt
2017-06-27 19:58   ` Eric Anholt
2017-06-29  9:02   ` Andrzej Hajda
2017-06-29  9:02     ` Andrzej Hajda
2017-06-27 19:58 ` [PATCH 2/8] drm/vc4: Fix misleading name of the continuous flag Eric Anholt
2017-06-27 19:58   ` Eric Anholt
2017-06-29  9:03   ` Andrzej Hajda
2017-06-29  9:03     ` Andrzej Hajda
2017-06-27 19:58 ` [PATCH 3/8] drm/vc4: Use drm_mode_vrefresh() in DSI fixup, in case vrefresh is 0 Eric Anholt
2017-06-27 19:58   ` Eric Anholt
2017-06-29  9:24   ` Andrzej Hajda
2017-06-29  9:24     ` Andrzej Hajda
2017-06-27 19:58 ` [PATCH 4/8] drm/bridge: Add a devm_ allocator for panel bridge Eric Anholt
2017-06-27 19:58   ` Eric Anholt
2017-06-29  9:30   ` Andrzej Hajda
2017-06-29  9:30     ` Andrzej Hajda
2017-06-27 19:58 ` [PATCH 5/8] drm/vc4: Delay DSI host registration until the panel has probed Eric Anholt
2017-06-27 19:58   ` Eric Anholt
2017-06-29  9:42   ` Andrzej Hajda
2017-06-29  9:42     ` Andrzej Hajda
2017-06-27 19:58 ` [PATCH 6/8] drm: Allow DSI devices to be registered before the host registers Eric Anholt
2017-06-27 19:58   ` Eric Anholt
2017-06-29  5:03   ` Archit Taneja
2017-06-29  5:03     ` Archit Taneja
2017-06-29 10:39     ` Andrzej Hajda
2017-06-29 10:39       ` Andrzej Hajda
2017-06-29 15:22       ` Eric Anholt
2017-06-29 15:22         ` Eric Anholt
2017-06-30  8:48         ` Andrzej Hajda
2017-06-30  8:48           ` Andrzej Hajda
2017-07-03 10:56       ` Archit Taneja
2017-07-03 10:56         ` Archit Taneja
2017-07-14 23:01         ` Eric Anholt
2017-07-14 23:01           ` Eric Anholt
2017-07-17 13:39           ` Archit Taneja
2017-07-17 13:39             ` Archit Taneja
2017-07-14 22:58     ` Eric Anholt
2017-07-14 22:58       ` Eric Anholt
2017-07-17  4:26       ` Archit Taneja
2017-07-17  4:26         ` Archit Taneja
2017-07-18 20:13         ` Eric Anholt [this message]
2017-07-18 20:13           ` Eric Anholt
2017-07-19  3:29           ` Archit Taneja
2017-07-19  3:29             ` Archit Taneja
2017-08-04  9:29           ` Boris Brezillon
2017-08-04  9:29             ` Boris Brezillon
2017-06-27 19:58 ` [PATCH 7/8] dt-bindings: Document the Raspberry Pi Touchscreen nodes Eric Anholt
2017-06-27 19:58   ` Eric Anholt
2017-06-27 19:58 ` [PATCH 8/8] drm/panel: Add support for the Raspberry Pi 7" Touchscreen Eric Anholt
2017-06-27 19:58   ` Eric Anholt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87mv81bj1r.fsf@eliezer.anholt.net \
    --to=eric@anholt.net \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=a.hajda@samsung.com \
    --cc=architt@codeaurora.org \
    --cc=boris.brezillon@free-electrons.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thierry.reding@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.