[RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Archit Taneja
architt at codeaurora.org
Wed Jun 6 10:21:16 UTC 2018
On Wednesday 06 June 2018 02:00 PM, Heiko Stübner wrote:
> 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?
I think all dual DSI panels actually have 2 DSI controllers/parsers
within them, one on each port. The MIPI DSI spec doesn't support 8
lanes. Also, the pixels coming out of the host are distributed among
the lanes differently than what would have been the case with a
'theoretical' 8 lane receiver.
Other than that, some dual DSI panels only accept DSI commands on the
'master' port, where as others expect the same command to be sent across
both the ports.
Therefore, I think it's better to represent dual DSI panels having 2
DSI input ports.
Your DT looks good to me.
Thanks,
Archit
>
> 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