Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for
 dw-mipi-dsi
To:     Archit Taneja <architt@codeaurora.org>, 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 <nickey.yang@rock-chips.com>
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
Precedence: bulk

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 <nickey.yang@rock-chips.com>
>> ---
>> .../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
>>
>


From 1582294546185032801@xxx Thu Oct 26 04:54:29 +0000 2017
X-GM-THRID: 1582200069796772034
X-Gmail-Labels: Inbox,Category Forums