From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753650AbdK3RdI (ORCPT ); Thu, 30 Nov 2017 12:33:08 -0500 Received: from regular1.263xmail.com ([211.150.99.136]:54233 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752134AbdK3RdH (ORCPT ); Thu, 30 Nov 2017 12:33:07 -0500 X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-RL-SENDER: nickey.yang@rock-chips.com X-FST-TO: xbl@rock-chips.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: nickey.yang@rock-chips.com X-UNIQUE-TAG: <8bb811bf2a0b154e279ed9b369449859> X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi To: Archit Taneja , robh+dt@kernel.org, heiko@sntech.de, mark.rutland@arm.com, airlied@linux.ie Cc: hl@rock-chips.com, zyw@rock-chips.comg, briannorris@chromium.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-rockchip@lists.infradead.org, xbl@rock-chips.com References: <1508903463-7254-1-git-send-email-nickey.yang@rock-chips.com> <1508903463-7254-5-git-send-email-nickey.yang@rock-chips.com> <816a1d2d-d213-709d-f357-63e7c5248ad3@codeaurora.org> From: Nickey Yang Message-ID: <2dab7233-139f-b148-2f5e-40a32b3dc797@rock-chips.com> Date: Fri, 1 Dec 2017 01:32:48 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <816a1d2d-d213-709d-f357-63e7c5248ad3@codeaurora.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Archit, On 2017年10月26日 12:53, Archit Taneja wrote: > > > On 10/25/2017 09:21 AM, Nickey Yang wrote: >> Configure dsi slave channel when driving a panel >> which needs 2 DSI links. >> >> Signed-off-by: Nickey Yang >> --- >> .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 2 ++ >>   1 file changed, 2 insertions(+) >> >> diff --git >> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt >> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt >> >> index 6bb59ab..a2bea22 100644 >> --- >> a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt >> +++ >> b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt >> @@ -19,6 +19,8 @@ Optional properties: >>   - power-domains: a phandle to mipi dsi power domain node. >>   - resets: list of phandle + reset specifier pairs, as described in >> [3]. >>   - reset-names: string reset name, must be "apb". >> +- rockchip,dual-channel: phandle to a 2nd DSI channel, useful as a >> slave >> +channel when driving a panel which needs 2 DSI links. > The example below is how dual DSI bindings could look like. Let me > know what > you think of it. > > If both DSI outputs drive the same device (i.e, point to the same > panel DT > node), then I think it's reasonable enough to assume that the DSIs are > operating in a 'dual-channel' mode. That being said, we still need DT to > describe which of the DSIs generates the clock for both the channels. > This > is done with the 'clock-master' DT binding. > > Thanks, > Archit > > 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>; >             }; >         }; >     }; > }; > 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 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. Thanks, Nickey >>     [1] Documentation/devicetree/bindings/clock/clock-bindings.txt >>   [2] Documentation/devicetree/bindings/media/video-interfaces.txt >> >