Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
---
.../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




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




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux