On 05/03/2016 07:32 PM, Philipp Zabel wrote:
Am Dienstag, den 03.05.2016, 16:28 +0530 schrieb Archit Taneja:
The DSI node now has two ports that describe the connection between the
MDP interface output and the DSI input, and the connection between the DSI
output and the connected panel/bridge. Update the properties and the
example.
Also, use generic PHY bindings instead of the custom one.
Signed-off-by: Archit Taneja <architt@xxxxxxxxxxxxxx>
---
.../devicetree/bindings/display/msm/dsi.txt | 53 +++++++++++++++-------
1 file changed, 37 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt
index bf41d7c..0223f06 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -25,12 +25,18 @@ Required properties:
- vdd-supply: phandle to vdd regulator device node
- vddio-supply: phandle to vdd-io regulator device node
- vdda-supply: phandle to vdda regulator device node
-- qcom,dsi-phy: phandle to DSI PHY device node
+- phys: phandle to DSI PHY device node
+- phy-names: the name of the corresponding PHY device
Should "dsi_phy" be specified here?
Also is there any kind of system to the PHY naming? I've seen more
bindings use hyphen instead of underscore in the name, for example.
I have called the MediaTek MIPI_TX PHY "dphy" for no other reason than
it's a MIPI D-PHY.
I agree with the hyphen part, I'll switch to that.
The DSI PHY block isn't only the D-PHY interface, it also contains a
PLL and some logic to support more complex configurations (for
example, syncing with the PHY connected to another DSI output). That's
the main reason why I left the name as "dsi_phy".
- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
+- ports: Contains 2 DSI controller ports as child nodes. Each port contains
+ an endpoint subnode as defined in [2] and [3]. port@0 describes the
+ connection between the MDP interface output and the DSI input. port@1
+ describes the connection between the DSI output and the connected
+ panel/bridge.
Optional properties:
- panel@0: Node of panel connected to this DSI controller.
- See files in [2] for each supported panel.
+ See files in [4] for each supported panel.
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
driving a panel which needs 2 DSI links.
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
@@ -42,15 +48,15 @@ Optional properties:
- pinctrl-names: the pin control state names; should contain "default"
- pinctrl-0: the default pinctrl state (active)
- pinctrl-n: the "sleep" pinctrl state
-- port: DSI controller output port, containing one endpoint subnode.
DSI Endpoint properties:
- - remote-endpoint: set to phandle of the connected panel's endpoint.
- See [3] for device graph info.
+ - remote-endpoint: For port@0, set to phandle of the connected panel/bridge's
+ input endpoint. For port@1, set to the MDP interface output.
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
to the physical lanes on the given platform. The value contained in
index n describes what logical data lane is mapped to the physical data
- lane n (DATAn, where n lies between 0 and 3).
+ lane n (DATAn, where n lies between 0 and 3). Only for the endpoint in
+ port@1.
I approve of the of graph change, but I notice that the
qcom,data-lane-map is very similar to the data-lanes property documented
in Documentation/devicetree/bindings/media/video-interfaces.txt for MIPI
CSI-2. Could that maybe be reused for DSI?
You're right. I missed out on the existing binding when I posted this.
One difference in this binding is that the indices here point to the
physical lanes, and the value contained in the index is the logical
lane (that's how it's described in the register documentation). For
the "data-lanes" property, it's the other way round. It's still
better to use the existing binding. I'll post a separate patch to
update this.
For example:
@@ -97,8 +103,9 @@ Optional properties:
regulator is wanted.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-[2] Documentation/devicetree/bindings/display/panel/
-[3] Documentation/devicetree/bindings/graph.txt
+[2] Documentation/devicetree/bindings/graph.txt
+[3] Documentation/devicetree/bindings/media/video-interfaces.txt
+[4] Documentation/devicetree/bindings/display/panel/
Example:
dsi0: dsi@fd922800 {
@@ -129,7 +136,8 @@ Example:
vdd-supply = <&pma8084_l22>;
vddio-supply = <&pma8084_l12>;
- qcom,dsi-phy = <&dsi_phy0>;
+ phys = <&dsi_phy0>;
+ phy-names ="dsi_phy";
qcom,dual-dsi-mode;
qcom,master-dsi;
@@ -139,6 +147,26 @@ Example:
pinctrl-0 = <&mdss_dsi_active>;
pinctrl-1 = <&mdss_dsi_suspend>;
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsi0_in: endpoint {
+ remote-endpoint = <&mdp_intf1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsi0_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ qcom,data-lane-map = <0 1 2 3>;
+ };
+ };
+ };
+
panel: panel@0 {
compatible = "sharp,lq101r1sx01";
reg = <0>;
If the panel is connected via port@1, why is this still needed?
Did you mean that the numbering(reg prop) isn't needed? If so, yeah, I
missed out on that. I'll remove it. Thanks for pointing it out.
Archit
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
