From: Brian Norris <briannorris@chromium.org>
To: Archit Taneja <architt@codeaurora.org>
Cc: mark.rutland@arm.com, airlied@linux.ie, zyw@rock-chips.comg,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org,
Nickey Yang <nickey.yang@rock-chips.com>,
robh+dt@kernel.org, xbl@rock-chips.com, hl@rock-chips.com
Subject: Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi
Date: Mon, 4 Dec 2017 17:19:16 -0800 [thread overview]
Message-ID: <20171205011914.GA59914@google.com> (raw)
In-Reply-To: <0dcf03d3-eda6-1b90-10ed-1d14f07824ab@codeaurora.org>
Hi Archit,
I'm a relative n00b here, but I'm trying to follow along and I have some
questions:
On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote:
> On 11/30/2017 11:02 PM, Nickey Yang wrote:
> >I try to follow as you suggested,use
> >
> >mipi_dsi: mipi@ff960000 {
> > ...
> > ...
> > clock-master; /* implies that this DSI instance drivers the clock
> > * for both the DSIs.
> > */
> > ports {
> > mipi_in: port {
> > ...
> > ...
> > };
> > /* add extra output ports for both DSIs */
> > mipi_out: port {
> > mipi_panel_out: endpoint {
> > remote-endpoint = <&panel_in_channel0>;
> > };
> > };
> > };
> > panel {
> > ...
> > ...
> > /*
> > * panel node can describe its input ports, if both the DSIs output
> > * ports are connected to the same device (i.e, the same DSI panel),
> > * we can assume that the DSIs need to operate in dual DSI mode
> > */
> > ports {
> > ...
> > port@0 {
> > panel_in_channel0: endpoint {
> > remote-endpoint = <&mipi_panel_out>;
> > };
> > };
> > port@1 {
> > panel_in_channel1: endpoint {
> > remote-endpoint = <&mipi1_panel_out>;
> > };
> >
> > };
> > };
> > };
> >};
> >
> >mipi_dsi1: mipi@ff968000 {
> > ...
> > ...
> > ports {
> > mipi1_in: port {
> > ...
> > ...
> > };
> > mipi1_out: port {
> > mipi1_panel_out: endpoint {
> > remote-endpoint = <&panel_in_channel1>;
> > };
> > };
> > };
> >}
> >
> >But it seems we can not use of_drm_find_panel(like below)
> >
> >/*
> > port = of_graph_get_port_by_id(dev->of_node, 1);
> > if (port) {
> > endpoint = of_get_child_by_name(port, "endpoint");
> > of_node_put(port);
> > if (!endpoint) {
> > dev_err(dev, "no output endpoint found\n");
> > return -EINVAL;
> > }
> > panel_node = of_graph_get_remote_port_parent(endpoint);
> > of_node_put(endpoint);
> > if (!panel_node) {
> > dev_err(dev, "no output node found\n");
> > return -EINVAL;
> > }
> > panel = of_drm_find_panel(panel_node);
> > of_node_put(panel_node);
> > if (!panel)
> > return -EPROBE_DEFER;
> > }
> >*/
> >to get DSI1 outputs,because of_drm_find_panel need compare
> >
> >if (panel->dev->of_node == np)
> >
> >in dsi_panel driver innolux->base.dev = &innolux->link->dev;
> >dsi->dev
>
> Yes, we should only have 1 drm_panel in the global panel list.
> Shouldn't it be possible to modify the dsi driver such that dsi1
> doesn't care whether it has a drm_panel for it or not, if we are
> in dual dsi mode?
>
> I imagine a sequence like this:
>
> 1. dsi0 probes, parses the of-graph, finds the panel and saves its device
> node.
Does this mean we depend on probe order? Or would we be able to
-EPROBE_DEFER or similar if dsi1 binds first?
> 2. dsi1 probes, parses the of-graph, find the panel's device node
> - dsi1 checks if it is the same as the panel attached to dsi0.
> - If so, it just takes the drm_panel pointer from dsi0.
> - If not, it tries a of_drm_find_panel() on the panel's device node.
So, that all means we'd need a new variant of
drm_of_find_panel_or_bridge() for "dual" drivers like this? Or else
open-code this logic in dw-mipi-dsi.c?
> A dual DSI panel driver would also be a bit different. It will be a
> mipi_dsi_driver with the master DSI (dsi0) as the mipi_dsi_device. Using
> the of-graph helpers, we would get the device node of dsi1 using
> of_find_mipi_dsi_host_by_node(), and create another DSI device using
> mipi_dsi_device_register_full(). Then, we call mipi_dsi_attach() on
> both the dsi devices.
That seems...interesting. I guess that sounds like it could work, but
someone would have to play with that a bit more.
I assume one wouldn't want to do all this in every dual DSI driver that
needs this, right?
> >struct innolux_panel {
> > struct drm_panel base;
> > struct mipi_dsi_device *link;
> >};
> >It means one panel can only be found in his dsi node,(like dsi0 above).
> >
> >I'm doubting about it, Or may we follow tegra_dsi_ganged_probe
> >(drivers/gpu/drm/tergra/dsi.c) method.
>
> This method will add a new binding similar to "nvidia,ganged-mode", which
> is something we don't want to do.
It's unfortunate we have the anti-pattern already merged :(
Brian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org>
To: Archit Taneja <architt@codeaurora.org>
Cc: Nickey Yang <nickey.yang@rock-chips.com>,
robh+dt@kernel.org, heiko@sntech.de, mark.rutland@arm.com,
airlied@linux.ie, hl@rock-chips.com, zyw@rock-chips.comg,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-rockchip@lists.infradead.org, xbl@rock-chips.com
Subject: Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi
Date: Mon, 4 Dec 2017 17:19:16 -0800 [thread overview]
Message-ID: <20171205011914.GA59914@google.com> (raw)
In-Reply-To: <0dcf03d3-eda6-1b90-10ed-1d14f07824ab@codeaurora.org>
Hi Archit,
I'm a relative n00b here, but I'm trying to follow along and I have some
questions:
On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote:
> On 11/30/2017 11:02 PM, Nickey Yang wrote:
> >I try to follow as you suggested,use
> >
> >mipi_dsi: mipi@ff960000 {
> > ...
> > ...
> > clock-master; /* implies that this DSI instance drivers the clock
> > * for both the DSIs.
> > */
> > ports {
> > mipi_in: port {
> > ...
> > ...
> > };
> > /* add extra output ports for both DSIs */
> > mipi_out: port {
> > mipi_panel_out: endpoint {
> > remote-endpoint = <&panel_in_channel0>;
> > };
> > };
> > };
> > panel {
> > ...
> > ...
> > /*
> > * panel node can describe its input ports, if both the DSIs output
> > * ports are connected to the same device (i.e, the same DSI panel),
> > * we can assume that the DSIs need to operate in dual DSI mode
> > */
> > ports {
> > ...
> > port@0 {
> > panel_in_channel0: endpoint {
> > remote-endpoint = <&mipi_panel_out>;
> > };
> > };
> > port@1 {
> > panel_in_channel1: endpoint {
> > remote-endpoint = <&mipi1_panel_out>;
> > };
> >
> > };
> > };
> > };
> >};
> >
> >mipi_dsi1: mipi@ff968000 {
> > ...
> > ...
> > ports {
> > mipi1_in: port {
> > ...
> > ...
> > };
> > mipi1_out: port {
> > mipi1_panel_out: endpoint {
> > remote-endpoint = <&panel_in_channel1>;
> > };
> > };
> > };
> >}
> >
> >But it seems we can not use of_drm_find_panel(like below)
> >
> >/*
> > port = of_graph_get_port_by_id(dev->of_node, 1);
> > if (port) {
> > endpoint = of_get_child_by_name(port, "endpoint");
> > of_node_put(port);
> > if (!endpoint) {
> > dev_err(dev, "no output endpoint found\n");
> > return -EINVAL;
> > }
> > panel_node = of_graph_get_remote_port_parent(endpoint);
> > of_node_put(endpoint);
> > if (!panel_node) {
> > dev_err(dev, "no output node found\n");
> > return -EINVAL;
> > }
> > panel = of_drm_find_panel(panel_node);
> > of_node_put(panel_node);
> > if (!panel)
> > return -EPROBE_DEFER;
> > }
> >*/
> >to get DSI1 outputs,because of_drm_find_panel need compare
> >
> >if (panel->dev->of_node == np)
> >
> >in dsi_panel driver innolux->base.dev = &innolux->link->dev;
> >dsi->dev
>
> Yes, we should only have 1 drm_panel in the global panel list.
> Shouldn't it be possible to modify the dsi driver such that dsi1
> doesn't care whether it has a drm_panel for it or not, if we are
> in dual dsi mode?
>
> I imagine a sequence like this:
>
> 1. dsi0 probes, parses the of-graph, finds the panel and saves its device
> node.
Does this mean we depend on probe order? Or would we be able to
-EPROBE_DEFER or similar if dsi1 binds first?
> 2. dsi1 probes, parses the of-graph, find the panel's device node
> - dsi1 checks if it is the same as the panel attached to dsi0.
> - If so, it just takes the drm_panel pointer from dsi0.
> - If not, it tries a of_drm_find_panel() on the panel's device node.
So, that all means we'd need a new variant of
drm_of_find_panel_or_bridge() for "dual" drivers like this? Or else
open-code this logic in dw-mipi-dsi.c?
> A dual DSI panel driver would also be a bit different. It will be a
> mipi_dsi_driver with the master DSI (dsi0) as the mipi_dsi_device. Using
> the of-graph helpers, we would get the device node of dsi1 using
> of_find_mipi_dsi_host_by_node(), and create another DSI device using
> mipi_dsi_device_register_full(). Then, we call mipi_dsi_attach() on
> both the dsi devices.
That seems...interesting. I guess that sounds like it could work, but
someone would have to play with that a bit more.
I assume one wouldn't want to do all this in every dual DSI driver that
needs this, right?
> >struct innolux_panel {
> > struct drm_panel base;
> > struct mipi_dsi_device *link;
> >};
> >It means one panel can only be found in his dsi node,(like dsi0 above).
> >
> >I'm doubting about it, Or may we follow tegra_dsi_ganged_probe
> >(drivers/gpu/drm/tergra/dsi.c) method.
>
> This method will add a new binding similar to "nvidia,ganged-mode", which
> is something we don't want to do.
It's unfortunate we have the anti-pattern already merged :(
Brian
next prev parent reply other threads:[~2017-12-05 1:19 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-25 3:50 [PATCH v3 1/6] drm/rockchip/dsi: Define and use macros for PHY register addresses Nickey Yang
2017-10-25 3:50 ` Nickey Yang
2017-10-25 3:50 ` [PATCH v3 2/6] drm/rockchip/dsi: correct phy parameter setting Nickey Yang
2017-10-25 3:50 ` Nickey Yang
2017-10-25 7:49 ` Sean Paul
2017-10-25 3:51 ` [PATCH v3 3/6] drm/rockchip/dsi: correct Feedback divider setting Nickey Yang
2017-10-25 3:51 ` Nickey Yang
2017-10-25 7:57 ` Sean Paul
2017-10-25 7:57 ` Sean Paul
2017-10-26 1:09 ` Brian Norris
2017-10-26 1:09 ` Brian Norris
2017-10-26 4:13 ` Archit Taneja
2017-10-26 4:13 ` Archit Taneja
[not found] ` <c1f17f1e-6e4f-d44d-348e-43157474f3c9-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-10-26 9:44 ` Philippe CORNU
2017-10-26 9:44 ` Philippe CORNU
2017-10-26 21:32 ` Brian Norris
2017-11-28 0:29 ` Brian Norris
2017-11-28 0:34 ` Brian Norris
2017-11-28 0:34 ` Brian Norris
2017-10-25 3:51 ` [PATCH v3 4/6] drm/rockchip/dsi: add dual mipi channel support Nickey Yang
2017-10-25 8:04 ` Sean Paul
2017-10-25 8:04 ` Sean Paul
2017-10-26 5:11 ` Archit Taneja
2017-10-26 5:11 ` Archit Taneja
2017-10-25 3:51 ` [PATCH v3 5/6] dt-bindings: add the rockchip,dual-channel for dw-mipi-dsi Nickey Yang
2017-10-26 4:53 ` [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel " Archit Taneja
2017-11-30 17:32 ` Nickey Yang
2017-11-30 17:32 ` Nickey Yang
2017-12-01 12:59 ` Archit Taneja
2017-12-01 12:59 ` Archit Taneja
2017-12-05 1:19 ` Brian Norris [this message]
2017-12-05 1:19 ` Brian Norris
2017-12-05 5:16 ` Archit Taneja
2017-12-05 5:16 ` Archit Taneja
2017-10-25 3:51 ` [PATCH v3 6/6] arm64: dts: rockchip: add mipi_dsi1 support for rk3399 Nickey Yang
2017-10-25 7:47 ` [PATCH v3 1/6] drm/rockchip/dsi: Define and use macros for PHY register addresses Sean Paul
2017-10-25 7:47 ` Sean Paul
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=20171205011914.GA59914@google.com \
--to=briannorris@chromium.org \
--cc=airlied@linux.ie \
--cc=architt@codeaurora.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=hl@rock-chips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=nickey.yang@rock-chips.com \
--cc=robh+dt@kernel.org \
--cc=xbl@rock-chips.com \
--cc=zyw@rock-chips.comg \
/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.