On 06/06/17 12:35, Boris Brezillon wrote:
> On Sat, 3 Jun 2017 23:43:17 +0530
> Archit Taneja <architt@xxxxxxxxxxxxxx> wrote:
>
>> Hi,
>>
>> On 06/02/2017 05:34 PM, Boris Brezillon wrote:
>>> Document the bindings used for the Cadence DSI bridge.
>>>
>>> Signed-off-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxxxxxxx>
>>> ---
>>> .../bindings/display/bridge/cdns,dsi.txt | 55 ++++++++++++++++++++++
>>> 1 file changed, 55 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
>>> new file mode 100644
>>> index 000000000000..770c5c5b1e93
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
>>> @@ -0,0 +1,55 @@
>>> +Cadence DSI bridge
>>> +==================
>>> +
>>> +The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
>>
>> Is this a separate chip, or an IP integrated into SoCs?
>
> It's supposed to be integrated into SoCs.
>
>> If it's the
>> latter, I don't think DPI on the its input side is the right term to
>> use. Maybe RGB would be more appropriate here.
>
> Well, the datasheet explicitly mentions DPI, and you can also send
> pixels in YUV422 and YUV420 format on this bus, so I don't think RGB is
> appropriate, but if you really want me to use RGB I can change that.
>
> BTW, can you detail why DPI is not appropriate for internal parallel
> busses. I don't understand why it makes a difference when the bus is exposed
> through external pins.
I think MIPI DPI is fine, if it is indeed MIPI DPI. But mot all parallel
video busses are MIPI DPI.
>>> +Required subnodes:
>>> +- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
>>> + Currently contains a single input port at address 0 representing the DPI
>>> + input. Other ports will be added later to support the SDI inputs.
>>> + Port 0 should be connected to a DPI encoder output.
>>
>> The output of the DSI bridge may be another bridge, which could be i2c
>> controlled. In that case, it won't be a child of the DSI bridge. For
>> such scenarios, we might want to define an output port for the bridge.
>
> Hm, okay. IIRC, this is something you mentioned when I asked how to
> describe input/output ports for a DSI bridge a while ago.
>
> I'm still not sure how the links between input and output endpoint are
> supposed to be described.
>
> For example, if you take the case where you have the DSI device
> directly described under the DSI host controller, should I create
> another node for this output port? Something like the following?
>
> dsi@xxx {
> #address-cells = <1>;
> #size-cells = <0>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
> dpi_in: port@0 {
> reg = <0>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> endpoint@0 {
> remote-endpoint = <&dpi_out>;
> };
> };
>
> dsi_out0: port@1 {
> reg = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> dsi_out0: endpoint@0 {
> remote-endpoint = <&dsi_panel0_in>;
> };
> };
>
> dsi_out0: port@2 {
> reg = <2>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> dsi_out1: endpoint@0 {
> remote-endpoint = <&dsi_panel1_in>;
> };
> };
> };
>
> panel@0 {
> compatible = "...";
> reg = <0>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
>
> dsi_panel0_in: endpoint@0 {
> remote-endpoint = <&dsi_out0>;
> };
> };
> };
>
> panel@1 {
> compatible = "...";
> reg = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0>;
>
> dsi_panel1_in: endpoint@0 {
> remote-endpoint = <&dsi_out1>;
> };
> };
> };
> };
>
The ports & endpoints describe the video path, and the node child-parent
relationship describe the control path. And "port" is a physical
connector of some sort, and endpoint is a virtual channel or such.
So, you can have DSI peripherals which are either children of the DSI
bridge, and can be controlled with DSI commands. Or, you can have, say,
i2c peripherals, defined under an i2c node, which just take the video
stream from the DSI bridge. Both would have similar ports & endpoints,
but the DT nodes would be located under different parents.
Also, you can't have two output ports unless the DSI bridge has actually
multiple output pins. If the two panels are connected to the same DSI
pins, and the DSI virtual channel is used to direct the output to the
correct panel, then these should be endpoints.
Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
