Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

["Heiko Stübner" <heiko@sntech.de>]

Am Mittwoch, 6. Juni 2018, 07:59:29 CEST schrieb Archit Taneja:
> On Monday 04 June 2018 05:47 PM, Heiko Stuebner wrote:
> > Am Donnerstag, 18. Januar 2018, 05:53:55 CEST schrieb Archit Taneja:
> >> Add binding info for peripherals that support dual-channel DSI. Add
> >> corresponding optional bindings for DSI host controllers that may
> >> be configured in this mode. Add an example of an I2C controlled
> >> device operating in dual-channel DSI mode.
> >> 
> >> Signed-off-by: Archit Taneja <architt@codeaurora.org>
> > 
> > Looks like a great solution for that problem, so
> > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> > 
> > As I'm looking into that for my rk3399-scarlet device right now and
> > couldn't find this patchset in the kernel yet, is it planned to
> > merge or refresh these binding changes or were problems encountered.
> > 
> > At least an Ack/Review from Rob seems to be missing.
> 
> I forgot about these patches. Rob had reviewed the first one in
> the set the second one still needed an Ack. I'll post a v3
> that adds the Reviewed-bys and fixes a small typo.

very nice ... because it looks like yesterday I managed to make the Rockchip 
dsi work in dual mode following this.

But one question came up, do you really want two input ports on the panel 
side? I.e. hardware-wise, I guess the panel will have one 8-lane or so input 
thatonly gets split up on the soc side onto 2 dsi controllers?

So right now I'm operating with a devicetree like

&mipi_dsi {
        status = "okay";
        clock-master;

        ports {
                mipi_out: port@1 {
                        reg = <1>;

                        mipi_out_panel: endpoint {
                                remote-endpoint = <&mipi_in_panel>;
                        };
                };
        };

        mipi_panel: panel@0 {
		  compatible = "innolux,p097pfg";
                reg = <0>;
                backlight = <&backlight>;
                enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
                pinctrl-names = "default";
                pinctrl-0 = <&display_rst_l>;

                port {
                        #address-cells = <1>;
                        #size-cells = <0>;

                        mipi_in_panel: endpoint@0 {
                                reg = <0>;
                                remote-endpoint = <&mipi_out_panel>;
                        };

                        mipi1_in_panel: endpoint@1 {
                                reg = <1>;
                                remote-endpoint = <&mipi1_out_panel>;
                        };
                };
        };
};

&mipi_dsi1 {
        status = "okay";

        ports {
                mipi1_out: port@1 {
                        reg = <1>;

                        mipi1_out_panel: endpoint {
                                remote-endpoint = <&mipi1_in_panel>;
                        };
                };
        };
};


I guess it is a matter of preference on what reflects the hardware
best, so maybe that's Robs call?


Heiko

> >> ---
> >> v2:
> >> - Specify that clock-master is a boolean property.
> >> - Drop/add unit-address and #*-cells where applicable.
> >> 
> >>   .../devicetree/bindings/display/mipi-dsi-bus.txt   | 80
> >>   ++++++++++++++++++++++ 1 file changed, 80 insertions(+)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt index
> >> 94fb72cb916f..7a3abbedb3fa 100644
> >> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> >> 
> >> @@ -29,6 +29,13 @@ Required properties:
> >>   - #size-cells: Should be 0. There are cases where it makes sense to use
> >>   a
> >>   
> >>     different value here. See below.
> >> 
> >> +Optional properties:
> >> +- clock-master: boolean. Should be enabled if the host is being used in
> >> +  conjunction with another DSI host to drive the same peripheral.
> >> Hardware
> >> +  supporting such a configuration generally requires the data on both
> >> the busses +  to be driven by the same clock. Only the DSI host instance
> >> controlling this +  clock should contain this property.
> >> +
> >> 
> >>   DSI peripheral
> >>   ==============
> >> 
> >> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI
> >> bus (mostly for the data>> 
> >>   path). Connections between such peripherals and a DSI host can be
> >>   represented using the graph bindings [1], [2].
> >> 
> >> +Peripherals that support dual channel DSI
> >> +-----------------------------------------
> >> +
> >> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> >> +busses. Each DSI bus/channel drives some portion of the pixel data
> >> (generally +left/right half of each line of the display, or even/odd
> >> lines of the display). +The graph bindings should be used to represent
> >> the multiple DSI busses that are +connected to this peripheral. Each DSI
> >> host's output endpoint can be linked to +an input endpoint of the DSI
> >> peripheral.
> >> +
> >> 
> >>   [1] Documentation/devicetree/bindings/graph.txt
> >>   [2] Documentation/devicetree/bindings/media/video-interfaces.txt
> >> 
> >> @@ -71,6 +88,8 @@ Examples
> >> 
> >>     with different virtual channel configurations.
> >>   
> >>   - (4) is an example of a peripheral on a I2C control bus connected with
> >>   to
> >>   
> >>     a DSI host using of-graph bindings.
> >> 
> >> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI
> >> peripheral,
> >> +  which uses I2C as its primary control bus.
> >> 
> >>   1)
> >>   
> >>   	dsi-host {
> >> 
> >> @@ -153,3 +172,64 @@ Examples
> >> 
> >>   			};
> >>   		
> >>   		};
> >>   	
> >>   	};
> >> 
> >> +
> >> +5)
> >> +	i2c-host {
> >> +		dsi-bridge@35 {
> >> +			compatible = "...";
> >> +			reg = <0x35>;
> >> +
> >> +			ports {
> >> +				#address-cells = <1>;
> >> +				#size-cells = <0>;
> >> +
> >> +				port@0 {
> >> +					reg = <0>;
> >> +					dsi0_in: endpoint {
> >> +						remote-endpoint = <&dsi0_out>;
> >> +					};
> >> +				};
> >> +
> >> +				port@1 {
> >> +					reg = <1>;
> >> +					dsi1_in: endpoint {
> >> +						remote-endpoint = <&dsi1_out>;
> >> +					};
> >> +				};
> >> +			};
> >> +		};
> >> +	};
> >> +
> >> +	dsi0-host {
> >> +		...
> >> +
> >> +		/*
> >> +		 * this DSI instance drives the clock for both the host
> >> +		 * controllers
> >> +		 */
> >> +		clock-master;
> >> +
> >> +		ports {
> >> +			...
> >> +
> >> +			port {
> >> +				dsi0_out: endpoint {
> >> +					remote-endpoint = <&dsi0_in>;
> >> +				};
> >> +			};
> >> +		};
> >> +	};
> >> +
> >> +	dsi1-host {
> >> +		...
> >> +
> >> +		ports {
> >> +			...
> >> +
> >> +			port {
> >> +				dsi1_out: endpoint {
> >> +					remote-endpoint = <&dsi1_in>;
> >> +				};
> >> +			};
> >> +		};
> >> +	};
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-arm-msm"
> > in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html




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