[PATCH 8/9] dt-bindings: msm/dsi: Modify port and PHY bindings
Archit Taneja
architt at codeaurora.org
Wed May 4 08:09:09 UTC 2016
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 at codeaurora.org>
>> ---
>> .../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 at 0 describes the
>> + connection between the MDP interface output and the DSI input. port at 1
>> + describes the connection between the DSI output and the connected
>> + panel/bridge.
>>
>> Optional properties:
>> - panel at 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 at 0, set to phandle of the connected panel/bridge's
>> + input endpoint. For port at 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 at 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 at 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 at 0 {
>> + reg = <0>;
>> + dsi0_in: endpoint {
>> + remote-endpoint = <&mdp_intf1_out>;
>> + };
>> + };
>> +
>> + port at 1 {
>> + reg = <1>;
>> + dsi0_out: endpoint {
>> + remote-endpoint = <&panel_in>;
>> + qcom,data-lane-map = <0 1 2 3>;
>> + };
>> + };
>> + };
>> +
>> panel: panel at 0 {
>> compatible = "sharp,lq101r1sx01";
>> reg = <0>;
>
> If the panel is connected via port at 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
More information about the dri-devel
mailing list