[RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Heiko Stübner
heiko at sntech.de
Wed Jun 6 08:30:04 UTC 2018
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 at codeaurora.org>
> >
> > Looks like a great solution for that problem, so
> > Reviewed-by: Heiko Stuebner <heiko at 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 at 1 {
reg = <1>;
mipi_out_panel: endpoint {
remote-endpoint = <&mipi_in_panel>;
};
};
};
mipi_panel: panel at 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 at 0 {
reg = <0>;
remote-endpoint = <&mipi_out_panel>;
};
mipi1_in_panel: endpoint at 1 {
reg = <1>;
remote-endpoint = <&mipi1_out_panel>;
};
};
};
};
&mipi_dsi1 {
status = "okay";
ports {
mipi1_out: port at 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 at 35 {
> >> + compatible = "...";
> >> + reg = <0x35>;
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + port at 0 {
> >> + reg = <0>;
> >> + dsi0_in: endpoint {
> >> + remote-endpoint = <&dsi0_out>;
> >> + };
> >> + };
> >> +
> >> + port at 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 at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the dri-devel
mailing list