diff mbox series

[v5,2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

Message ID 1525235522-8954-3-git-send-email-spanda@codeaurora.org
State Not Applicable, archived
Headers show
Series Add suppport for sn65dsi86 bridge chip and Innolux 2k edp panel | expand

Commit Message

Sandeep Panda May 2, 2018, 4:32 a.m. UTC 
Document the bindings used for the sn65dsi86 DSI to eDP bridge.

Changes in v1:
 - Rephrase the dt-binding descriptions to be more inline with existing
   bindings (Andrzej Hajda).
 - Add missing dt-binding that are parsed by corresponding driver
   (Andrzej Hajda).

Changes in v2:
 - Remove edp panel specific dt-binding entries. Only keep bridge
   specific entries (Sean Paul).
 - Remove custom-modes dt entry since its usage is removed from driver also (Sean Paul).
 - Remove is-pluggable dt entry since this will not be needed anymore (Sean Paul).

Changes in v3:
 - Remove irq-gpio dt entry and instead populate is an interrupt
   property (Rob Herring).

Changes in v4:
 - Add link to bridge chip datasheet (Stephen Boyd)
 - Add vpll and vcc regulator supply bindings (Stephen Boyd)
 - Add ref clk optional dt binding (Stephen Boyd)
 - Add gpio-controller optional dt binding (Stephen Boyd)

Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
 .../bindings/display/bridge/ti,sn65dsi86.txt       | 76 ++++++++++++++++++++++
 1 file changed, 76 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt

Comments

Stephen Boyd May 2, 2018, 5:01 p.m. UTC | #1 
Quoting Sandeep Panda (2018-05-01 21:32:00)
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> new file mode 100644
> index 0000000..0d042ce
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> @@ -0,0 +1,76 @@
> +SN65DSI86 DSI to eDP bridge chip
> +--------------------------------
> +
> +This is the binding for Texas Instruments SN65DSI86 bridge.
> +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
> +
> +Required properties:
> +- compatible: Must be "ti,sn65dsi86"
> +- reg: i2c address of the chip, 0x2d as per datasheet
> +- enable-gpios: OF device-tree gpio specification for bridge_en pin
> +
> +- vccio-supply: A 1.8V supply that powers up the digital IOs.
> +- vpll-supply: A 1.8V supply that powers up the displayport PLL.
> +- vcca-supply: A 1.2V supply that powers up the analog circuits.
> +- vcc-supply: A 1.2V supply that powers up the digital core.
> +
> +Optional properties:
> +- interrupts: Specifier for the SN65DSI86 interrupt line.
> +- hpd-gpios: OF device-tree gpio specifications for HPD pin.
> +
> +- refclk-freq-khz: Value specifying the frequency of reference clock in KHz unit.

Please use the clocks property instead. We may need to turn the clk on
first before this can work so the driver would use the clk framework (at
least in linux). clock-names could have 'refclk' because that's the pin
name.

Is there a way in DRM to figure out the frequency of the clock frequency
for DACP/N? It looks like if refclk is grounded, then the DACP/N pins
from the DSI side should be one of a set of frequencies, so I'm just
curious how that will work and if the binding would need to be updated
to indicate what the frequency of the DSI clock lane is, or if DRM can
tell this driver through the port/graph stuff somehow.

> +
> +- gpio-controller: Marks the device has a GPIO controller.
> +- #gpio-cells: Number of GPIO cells. Refer to binding document "gpio/gpio.txt"

What's the number? 2?

> +- #pwm-cells : Number of cells used to specify a PWM. See pwm.txt in this directory
> +              for a description of the cell formats.

What's the number? 1? There's a pwm.txt in this directory?

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sandeep Panda May 3, 2018, 9:41 a.m. UTC | #2 
On 2018-05-02 22:31, Stephen Boyd wrote:
> Quoting Sandeep Panda (2018-05-01 21:32:00)
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
>> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> new file mode 100644
>> index 0000000..0d042ce
>> --- /dev/null
>> +++ 
>> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> @@ -0,0 +1,76 @@
>> +SN65DSI86 DSI to eDP bridge chip
>> +--------------------------------
>> +
>> +This is the binding for Texas Instruments SN65DSI86 bridge.
>> +http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
>> +
>> +Required properties:
>> +- compatible: Must be "ti,sn65dsi86"
>> +- reg: i2c address of the chip, 0x2d as per datasheet
>> +- enable-gpios: OF device-tree gpio specification for bridge_en pin
>> +
>> +- vccio-supply: A 1.8V supply that powers up the digital IOs.
>> +- vpll-supply: A 1.8V supply that powers up the displayport PLL.
>> +- vcca-supply: A 1.2V supply that powers up the analog circuits.
>> +- vcc-supply: A 1.2V supply that powers up the digital core.
>> +
>> +Optional properties:
>> +- interrupts: Specifier for the SN65DSI86 interrupt line.
>> +- hpd-gpios: OF device-tree gpio specifications for HPD pin.
>> +
>> +- refclk-freq-khz: Value specifying the frequency of reference clock 
>> in KHz unit.
> 
> Please use the clocks property instead. We may need to turn the clk on
> first before this can work so the driver would use the clk framework 
> (at
> least in linux). clock-names could have 'refclk' because that's the pin
> name.
> 
> Is there a way in DRM to figure out the frequency of the clock 
> frequency
> for DACP/N? It looks like if refclk is grounded, then the DACP/N pins
> from the DSI side should be one of a set of frequencies, so I'm just
> curious how that will work and if the binding would need to be updated
> to indicate what the frequency of the DSI clock lane is, or if DRM can
> tell this driver through the port/graph stuff somehow.
> 

Can we do something like below?
    1. Add a required dt-property to indicate what is the source of 
refclk, ti,sn-refclk-src = <0> ---> means refclk is derived from refclk 
pin.
                                                                          
   ti,sn-refclk-src = <1> ---> means refclk is derived from DACP/N pin.
    2. Add a clock property to indicate the refclk frequency for refclk 
pin.
    3. In driver, parse the refclk source dt-property. If the source is 
refclk pin then get the frquency from clock dt-property and program the 
i2c register accordingly.
       Else if the source is DACP/N pin then calculate the DSIA frequency 
based on current display mode (by the time we go for configuring refclk, 
drm_mode_set is already done and in  diver we can calculate the 
frequency) and program the i2c register accordingly.

>> +
>> +- gpio-controller: Marks the device has a GPIO controller.
>> +- #gpio-cells: Number of GPIO cells. Refer to binding document 
>> "gpio/gpio.txt"
> 
> What's the number? 2?
number is 4, i will update this in binding
> 
>> +- #pwm-cells : Number of cells used to specify a PWM. See pwm.txt in 
>> this directory
>> +              for a description of the cell formats.
> 
> What's the number? 1? There's a pwm.txt in this directory?
yes number is 1, i will update the binding. it should be pwm/pwm.txt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Stephen Boyd May 7, 2018, 10:18 p.m. UTC | #3 
Quoting spanda@codeaurora.org (2018-05-03 02:41:29)
> On 2018-05-02 22:31, Stephen Boyd wrote:
> > Quoting Sandeep Panda (2018-05-01 21:32:00)
> >> diff --git 
> >> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt 
> >> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
> >> new file mode 100644
> >> index 0000000..0d042ce
> > 
> > Please use the clocks property instead. We may need to turn the clk on
> > first before this can work so the driver would use the clk framework 
> > (at
> > least in linux). clock-names could have 'refclk' because that's the pin
> > name.
> > 
> > Is there a way in DRM to figure out the frequency of the clock 
> > frequency
> > for DACP/N? It looks like if refclk is grounded, then the DACP/N pins
> > from the DSI side should be one of a set of frequencies, so I'm just
> > curious how that will work and if the binding would need to be updated
> > to indicate what the frequency of the DSI clock lane is, or if DRM can
> > tell this driver through the port/graph stuff somehow.
> > 
> 
> Can we do something like below?
>     1. Add a required dt-property to indicate what is the source of 
> refclk, ti,sn-refclk-src = <0> ---> means refclk is derived from refclk 
> pin.
>                                                                           
>    ti,sn-refclk-src = <1> ---> means refclk is derived from DACP/N pin.
>     2. Add a clock property to indicate the refclk frequency for refclk 
> pin.
>     3. In driver, parse the refclk source dt-property. If the source is 
> refclk pin then get the frquency from clock dt-property and program the 
> i2c register accordingly.
>        Else if the source is DACP/N pin then calculate the DSIA frequency 
> based on current display mode (by the time we go for configuring refclk, 
> drm_mode_set is already done and in  diver we can calculate the 
> frequency) and program the i2c register accordingly.

The presence or non-presence of the refclk should still be indicated via
the standard clock property instead of some TI specific property. The
driver can try to clk_get() the refclk and if its there it can call
clk_get_rate() to figure out the reference clk frequency. It should also
turn it on with clk_prepare_enable() to make sure the clk is clocking
and turn it off when the driver isn't using it.

If the reference clk is recovered from the DACP/N pin then there won't
be a clocks property, and the driver can do what you describe in #3.

> 
> >> +
> >> +- gpio-controller: Marks the device has a GPIO controller.
> >> +- #gpio-cells: Number of GPIO cells. Refer to binding document 
> >> "gpio/gpio.txt"
> > 
> > What's the number? 2?
> number is 4, i will update this in binding

Really? What do you need 4 cells for? The number of cells doesn't
indicate the number of GPIOs on the device.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Sandeep Panda May 11, 2018, 11:18 a.m. UTC | #4 
On 2018-05-08 03:48, Stephen Boyd wrote:
> Quoting spanda@codeaurora.org (2018-05-03 02:41:29)
>> On 2018-05-02 22:31, Stephen Boyd wrote:
>> > Quoting Sandeep Panda (2018-05-01 21:32:00)
>> >> diff --git
>> >> a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> >> b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>> >> new file mode 100644
>> >> index 0000000..0d042ce
>> >
>> > Please use the clocks property instead. We may need to turn the clk on
>> > first before this can work so the driver would use the clk framework
>> > (at
>> > least in linux). clock-names could have 'refclk' because that's the pin
>> > name.
>> >
>> > Is there a way in DRM to figure out the frequency of the clock
>> > frequency
>> > for DACP/N? It looks like if refclk is grounded, then the DACP/N pins
>> > from the DSI side should be one of a set of frequencies, so I'm just
>> > curious how that will work and if the binding would need to be updated
>> > to indicate what the frequency of the DSI clock lane is, or if DRM can
>> > tell this driver through the port/graph stuff somehow.
>> >
>> 
>> Can we do something like below?
>>     1. Add a required dt-property to indicate what is the source of
>> refclk, ti,sn-refclk-src = <0> ---> means refclk is derived from 
>> refclk
>> pin.
>> 
>>    ti,sn-refclk-src = <1> ---> means refclk is derived from DACP/N 
>> pin.
>>     2. Add a clock property to indicate the refclk frequency for 
>> refclk
>> pin.
>>     3. In driver, parse the refclk source dt-property. If the source 
>> is
>> refclk pin then get the frquency from clock dt-property and program 
>> the
>> i2c register accordingly.
>>        Else if the source is DACP/N pin then calculate the DSIA 
>> frequency
>> based on current display mode (by the time we go for configuring 
>> refclk,
>> drm_mode_set is already done and in  diver we can calculate the
>> frequency) and program the i2c register accordingly.
> 
> The presence or non-presence of the refclk should still be indicated 
> via
> the standard clock property instead of some TI specific property. The
> driver can try to clk_get() the refclk and if its there it can call
> clk_get_rate() to figure out the reference clk frequency. It should 
> also
> turn it on with clk_prepare_enable() to make sure the clk is clocking
> and turn it off when the driver isn't using it.
> 
> If the reference clk is recovered from the DACP/N pin then there won't
> be a clocks property, and the driver can do what you describe in #3.
> 
>> 
>> >> +
>> >> +- gpio-controller: Marks the device has a GPIO controller.
>> >> +- #gpio-cells: Number of GPIO cells. Refer to binding document
>> >> "gpio/gpio.txt"
>> >
>> > What's the number? 2?
>> number is 4, i will update this in binding
> 
> Really? What do you need 4 cells for? The number of cells doesn't
> indicate the number of GPIOs on the device.

It should be 2, got confused with number GPIOs.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
new file mode 100644
index 0000000..0d042ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
@@ -0,0 +1,76 @@ 
+SN65DSI86 DSI to eDP bridge chip
+--------------------------------
+
+This is the binding for Texas Instruments SN65DSI86 bridge.
+http://www.ti.com/general/docs/lit/getliterature.tsp?genericPartNumber=sn65dsi86&fileType=pdf
+
+Required properties:
+- compatible: Must be "ti,sn65dsi86"
+- reg: i2c address of the chip, 0x2d as per datasheet
+- enable-gpios: OF device-tree gpio specification for bridge_en pin
+
+- vccio-supply: A 1.8V supply that powers up the digital IOs.
+- vpll-supply: A 1.8V supply that powers up the displayport PLL.
+- vcca-supply: A 1.2V supply that powers up the analog circuits.
+- vcc-supply: A 1.2V supply that powers up the digital core.
+
+Optional properties:
+- interrupts: Specifier for the SN65DSI86 interrupt line.
+- hpd-gpios: OF device-tree gpio specifications for HPD pin.
+
+- refclk-freq-khz: Value specifying the frequency of reference clock in KHz unit.
+
+- gpio-controller: Marks the device has a GPIO controller.
+- #gpio-cells: Number of GPIO cells. Refer to binding document "gpio/gpio.txt"
+- #pwm-cells : Number of cells used to specify a PWM. See pwm.txt in this directory
+	       for a description of the cell formats.
+
+Required nodes:
+
+This device has two video ports. Their connections are modelled using the
+OF graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for DSI input
+- Video port 1 for eDP output
+
+Example
+-------
+
+edp-bridge@2d {
+	compatible = "ti,sn65dsi86";
+	#address-cells = <1>;
+	#size-cells = <0>;
+	reg = <0x2d>;
+
+	enable-gpios = <&msmgpio 33 GPIO_ACTIVE_HIGH>;
+	interrupt-parent = <&gpio3>;
+	interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
+
+	vccio-supply = <&pm8916_l17>;
+	vcca-supply = <&pm8916_l6>;
+	vpll-supply = <&pm8916_l17>;
+	vcc-supply = <&pm8916_l6>;
+
+	refclk-freq-khz = <19200>;
+
+	ports {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		port@0 {
+			reg = <0>;
+
+			edp_bridge_in: endpoint {
+				remote-endpoint = <&dsi_out>;
+			};
+		};
+
+		port@1 {
+			reg = <1>;
+
+			edp_bridge_out: endpoint {
+				remote-endpoint = <&edp_panel_in>;
+			};
+		};
+	};
+}