Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output
mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel
connections with the board.
1. Single Link / Single Mode on OLDI TX 0 OR 1.
2. Single Link / Duplicate Mode on OLDI TX 0 and 1.
3. Dual Link / Single Mode on OLDI TX 0 and 1.
Add "ti,rgb565-to-888" property to override 16bit output from a videoport
for a bridge that only accepts 24bit RGB888 DPI input.
On some boards the HDMI bridge takes a 24bit DPI input, but only 16 data
pins are actually enabled from the SoC. This new property forces the
output to be RGB565 on a specific video port if the bridge requests a
24bit RGB color space.
This assumes that the video port is connected like so:
SoC : Bridge
R0 -> R3
R1 -> R4
R2 -> R5
R3 -> R6
R4 -> R7
G0 -> G2
G1 -> G3
G2 -> G4
G3 -> G5
G4 -> G6
G5 -> G7
B0 -> B3
B1 -> B4
B2 -> B5
B3 -> B6
B4 -> B7
On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
The bridge sees 24bits of data, but the lsb's are always zero.
Signed-off-by: Aradhya Bhatia <[email protected]>
---
.../bindings/display/ti/ti,am65x-dss.yaml | 25 +++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
index 6bbce921479d..11d9b3821409 100644
--- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
+++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
@@ -80,15 +80,35 @@ properties:
properties:
port@0:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
The DSS OLDI output port node form video port 1
+ properties:
+ ti,oldi-mode:
+ description: TI specific property to indicate the mode the OLDI TXes
+ and the display panel are connected in.
+ 0 -> OLDI TXes OFF (driver default for am625-dss)
+ 1 -> Single link, Single Mode (OLDI0) (driver default for am65x-dss)
+ 2 -> Single link, Single Mode (OLDI1)
+ 3 -> Single link, Duplicate Mode
+ 4 -> Dual link (Only Single Mode)
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1, 2, 3, 4]
+
port@1:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
The DSS DPI output port node from video port 2
+ properties:
+ ti,rgb565-to-888:
+ description:
+ property to override DPI output to 16bit for 24bit bridge
+ type: boolean
+
ti,am65x-oldi-io-ctrl:
$ref: "/schemas/types.yaml#/definitions/phandle"
description:
@@ -144,6 +164,7 @@ examples:
#size-cells = <0>;
port@0 {
reg = <0>;
+ ti,oldi-mode = <1>;
oldi_out0: endpoint {
remote-endpoint = <&lcd_in0>;
};
--
2.37.0
On Tue, Jul 19, 2022 at 01:38:38PM +0530, Aradhya Bhatia wrote:
> Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output
> mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel
> connections with the board.
>
> 1. Single Link / Single Mode on OLDI TX 0 OR 1.
> 2. Single Link / Duplicate Mode on OLDI TX 0 and 1.
> 3. Dual Link / Single Mode on OLDI TX 0 and 1.
>
> Add "ti,rgb565-to-888" property to override 16bit output from a videoport
> for a bridge that only accepts 24bit RGB888 DPI input.
>
> On some boards the HDMI bridge takes a 24bit DPI input, but only 16 data
> pins are actually enabled from the SoC. This new property forces the
> output to be RGB565 on a specific video port if the bridge requests a
> 24bit RGB color space.
>
> This assumes that the video port is connected like so:
>
> SoC : Bridge
> R0 -> R3
> R1 -> R4
> R2 -> R5
> R3 -> R6
> R4 -> R7
> G0 -> G2
> G1 -> G3
> G2 -> G4
> G3 -> G5
> G4 -> G6
> G5 -> G7
> B0 -> B3
> B1 -> B4
> B2 -> B5
> B3 -> B6
> B4 -> B7
>
> On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
> The bridge sees 24bits of data, but the lsb's are always zero.
Unless the bridge ignores the LSBs, that's not the right way to do 16 to
24 bit. The LSBs should be connected to the MSB of the color component
to get full color range.
>
> Signed-off-by: Aradhya Bhatia <[email protected]>
> ---
> .../bindings/display/ti/ti,am65x-dss.yaml | 25 +++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> index 6bbce921479d..11d9b3821409 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> @@ -80,15 +80,35 @@ properties:
>
> properties:
> port@0:
> - $ref: /schemas/graph.yaml#/properties/port
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> description:
> The DSS OLDI output port node form video port 1
>
> + properties:
> + ti,oldi-mode:
> + description: TI specific property to indicate the mode the OLDI TXes
> + and the display panel are connected in.
> + 0 -> OLDI TXes OFF (driver default for am625-dss)
> + 1 -> Single link, Single Mode (OLDI0) (driver default for am65x-dss)
> + 2 -> Single link, Single Mode (OLDI1)
> + 3 -> Single link, Duplicate Mode
> + 4 -> Dual link (Only Single Mode)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3, 4]
Wouldn't 'data-lanes' property work for this purpose.
Generally, we don't put properties in port nodes.
> +
> port@1:
> - $ref: /schemas/graph.yaml#/properties/port
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> description:
> The DSS DPI output port node from video port 2
>
> + properties:
> + ti,rgb565-to-888:
> + description:
> + property to override DPI output to 16bit for 24bit bridge
> + type: boolean
There's work underway for standard way to handle interface formats[1].
Please help/comment on that to make sure it works for you.
Rob
[1] https://lore.kernel.org/all/[email protected]/
On 17:28-20220720, Rob Herring wrote:
> > On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
> > The bridge sees 24bits of data, but the lsb's are always zero.
>
> Unless the bridge ignores the LSBs, that's not the right way to do 16 to
> 24 bit. The LSBs should be connected to the MSB of the color component
> to get full color range.
I unfortunately cannot point specifics without violating NDAs, so
will just give a broad perspective.
Correct, this is not ideal, but in certain scenarios with limited
pins (due to iovoltage groups), we are indeed starting to see this
kind of usage model starting to pop up. Tradeoff is in a limit on
image quality, but that tends to be acceptable in certain lower cost
solutions.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 21-Jul-22 04:58, Rob Herring wrote:
> On Tue, Jul 19, 2022 at 01:38:38PM +0530, Aradhya Bhatia wrote:
>> Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output
>> mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel
>> connections with the board.
>>
>> 1. Single Link / Single Mode on OLDI TX 0 OR 1.
>> 2. Single Link / Duplicate Mode on OLDI TX 0 and 1.
>> 3. Dual Link / Single Mode on OLDI TX 0 and 1.
>>
>> Add "ti,rgb565-to-888" property to override 16bit output from a videoport
>> for a bridge that only accepts 24bit RGB888 DPI input.
>>
>> On some boards the HDMI bridge takes a 24bit DPI input, but only 16 data
>> pins are actually enabled from the SoC. This new property forces the
>> output to be RGB565 on a specific video port if the bridge requests a
>> 24bit RGB color space.
>>
>> This assumes that the video port is connected like so:
>>
>> SoC : Bridge
>> R0 -> R3
>> R1 -> R4
>> R2 -> R5
>> R3 -> R6
>> R4 -> R7
>> G0 -> G2
>> G1 -> G3
>> G2 -> G4
>> G3 -> G5
>> G4 -> G6
>> G5 -> G7
>> B0 -> B3
>> B1 -> B4
>> B2 -> B5
>> B3 -> B6
>> B4 -> B7
>>
>> On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
>> The bridge sees 24bits of data, but the lsb's are always zero.
>
> Unless the bridge ignores the LSBs, that's not the right way to do 16 to
> 24 bit. The LSBs should be connected to the MSB of the color component
> to get full color range.
>
>>
>> Signed-off-by: Aradhya Bhatia <[email protected]>
>> ---
>> .../bindings/display/ti/ti,am65x-dss.yaml | 25 +++++++++++++++++--
>> 1 file changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>> index 6bbce921479d..11d9b3821409 100644
>> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
>> @@ -80,15 +80,35 @@ properties:
>>
>> properties:
>> port@0:
>> - $ref: /schemas/graph.yaml#/properties/port
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> description:
>> The DSS OLDI output port node form video port 1
>>
>> + properties:
>> + ti,oldi-mode:
>> + description: TI specific property to indicate the mode the OLDI TXes
>> + and the display panel are connected in.
>> + 0 -> OLDI TXes OFF (driver default for am625-dss)
>> + 1 -> Single link, Single Mode (OLDI0) (driver default for am65x-dss)
>> + 2 -> Single link, Single Mode (OLDI1)
>> + 3 -> Single link, Duplicate Mode
>> + 4 -> Dual link (Only Single Mode)
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> + enum: [0, 1, 2, 3, 4]
>
> Wouldn't 'data-lanes' property work for this purpose.
>
> Generally, we don't put properties in port nodes.
>
Thank you for the suggestions Rob!
I looked into the "data-lanes" property and it seems that the property
alone would not be able to help distinguish between the "Single link,
Duplicate mode" (Mode 3) and "Dual link, Single mode" (Mode 4). For both
the cases, the property will look like "data-lanes = <0 1>;" in the DT
node.
I have an idea on what the driver could use along with the data-lanes
property to ascertain the OLDI mode.
By means of number of remote-endpoints in DTS.
The OLDI output port of DSS can be made to have 2 remote endpoints when
2 panels are connected as "Single link, Duplicate Mode" vs only 1 remote
endpoint for "Dual Link, Single Mode". Based on the count, the driver
can distinguish between the two when both the data-lanes are activated
in DT node.
Let me know if you think this method would be appropriate.
>> +
>> port@1:
>> - $ref: /schemas/graph.yaml#/properties/port
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + unevaluatedProperties: false
>> description:
>> The DSS DPI output port node from video port 2
>>
>> + properties:
>> + ti,rgb565-to-888:
>> + description:
>> + property to override DPI output to 16bit for 24bit bridge
>> + type: boolean
>
> There's work underway for standard way to handle interface formats[1].
> Please help/comment on that to make sure it works for you.
>
> Rob
>
> [1] https://lore.kernel.org/all/[email protected]/
I also followed what this patch series is implementing. This seems to be
applicable for cases where the DPI pins are drawn and forwarded towards
a simple panel capable of accepting the raw parallel data.
It does not cover for the bridges with lesser number of formats to
support.
Regards
Aradhya
On Mon, Jul 25, 2022 at 04:56:15PM +0530, Aradhya Bhatia wrote:
> On 21-Jul-22 04:58, Rob Herring wrote:
> > On Tue, Jul 19, 2022 at 01:38:38PM +0530, Aradhya Bhatia wrote:
> > > +
> > > port@1:
> > > - $ref: /schemas/graph.yaml#/properties/port
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > + unevaluatedProperties: false
> > > description:
> > > The DSS DPI output port node from video port 2
> > > + properties:
> > > + ti,rgb565-to-888:
> > > + description:
> > > + property to override DPI output to 16bit for 24bit bridge
> > > + type: boolean
> >
> > There's work underway for standard way to handle interface formats[1].
> > Please help/comment on that to make sure it works for you.
> >
> > Rob
> >
> > [1] https://lore.kernel.org/all/[email protected]/
>
> I also followed what this patch series is implementing. This seems to be
> applicable for cases where the DPI pins are drawn and forwarded towards
> a simple panel capable of accepting the raw parallel data.
It would be great to have that patch move forward and eventually get it
merged, only Rob commented weeks ago.
Francesco
On 22/07/2022 19:16, Nishanth Menon wrote:
> On 17:28-20220720, Rob Herring wrote:
>>> On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
>>> The bridge sees 24bits of data, but the lsb's are always zero.
>>
>> Unless the bridge ignores the LSBs, that's not the right way to do 16 to
>> 24 bit. The LSBs should be connected to the MSB of the color component
>> to get full color range.
>
> I unfortunately cannot point specifics without violating NDAs, so
> will just give a broad perspective.
>
> Correct, this is not ideal, but in certain scenarios with limited
> pins (due to iovoltage groups), we are indeed starting to see this
> kind of usage model starting to pop up. Tradeoff is in a limit on
> image quality, but that tends to be acceptable in certain lower cost
> solutions.
It doesn't require more pins. If the lowest bits are tied to ground the
image is always a bit darker than it should, and you do not get the full
brightness. But if you wire e.g. the red component:
SoC : Bridge
R2 -> R0
R3 -> R1
R4 -> R2
R0 -> R3
R1 -> R4
R2 -> R5
R3 -> R6
R4 -> R7
or
R4 -> R0
R4 -> R1
R4 -> R2
R0 -> R3
R1 -> R4
R2 -> R5
R3 -> R6
R4 -> R7
You'll get the full range.
Tomi
On 19/07/2022 11:08, Aradhya Bhatia wrote:
> Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output
> mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel
> connections with the board.
>
> 1. Single Link / Single Mode on OLDI TX 0 OR 1.
> 2. Single Link / Duplicate Mode on OLDI TX 0 and 1.
> 3. Dual Link / Single Mode on OLDI TX 0 and 1.
>
> Add "ti,rgb565-to-888" property to override 16bit output from a videoport
> for a bridge that only accepts 24bit RGB888 DPI input.
>
> On some boards the HDMI bridge takes a 24bit DPI input, but only 16 data
> pins are actually enabled from the SoC. This new property forces the
> output to be RGB565 on a specific video port if the bridge requests a
> 24bit RGB color space.
>
> This assumes that the video port is connected like so:
>
> SoC : Bridge
> R0 -> R3
> R1 -> R4
> R2 -> R5
> R3 -> R6
> R4 -> R7
> G0 -> G2
> G1 -> G3
> G2 -> G4
> G3 -> G5
> G4 -> G6
> G5 -> G7
> B0 -> B3
> B1 -> B4
> B2 -> B5
> B3 -> B6
> B4 -> B7
>
> On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
> The bridge sees 24bits of data, but the lsb's are always zero.
>
> Signed-off-by: Aradhya Bhatia <[email protected]>
> ---
> .../bindings/display/ti/ti,am65x-dss.yaml | 25 +++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> index 6bbce921479d..11d9b3821409 100644
> --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> @@ -80,15 +80,35 @@ properties:
>
> properties:
> port@0:
> - $ref: /schemas/graph.yaml#/properties/port
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> description:
> The DSS OLDI output port node form video port 1
>
> + properties:
> + ti,oldi-mode:
> + description: TI specific property to indicate the mode the OLDI TXes
> + and the display panel are connected in.
> + 0 -> OLDI TXes OFF (driver default for am625-dss)
> + 1 -> Single link, Single Mode (OLDI0) (driver default for am65x-dss)
> + 2 -> Single link, Single Mode (OLDI1)
> + 3 -> Single link, Duplicate Mode
> + 4 -> Dual link (Only Single Mode)
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [0, 1, 2, 3, 4]
> +
> port@1:
> - $ref: /schemas/graph.yaml#/properties/port
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> description:
> The DSS DPI output port node from video port 2
>
> + properties:
> + ti,rgb565-to-888:
> + description:
> + property to override DPI output to 16bit for 24bit bridge
> + type: boolean
So you have a board with 16 DSS pins connected, going to a bridge/panel
that only supports 24 bit input. I don't think there's anything TI
specific here, sounds like a common situation.
"rgb565-to-888" sounds like there's some kind of conversion happening,
but all this does is set the videoport width to 16 bits.
I'm not sure if there's a better solution but in the OMAP DSS we have
"data-lines" property for an endpoint, which tells the driver the width
of the bus.
Tomi
On Mon, Jul 25, 2022 at 04:56:15PM +0530, Aradhya Bhatia wrote:
>
>
> On 21-Jul-22 04:58, Rob Herring wrote:
> > On Tue, Jul 19, 2022 at 01:38:38PM +0530, Aradhya Bhatia wrote:
> > > Add "ti,oldi-mode" property to indicate the tidss driver the OLDI output
> > > mode. The 2 OLDI TXes on am625-dss allow a 3 different types of panel
> > > connections with the board.
> > >
> > > 1. Single Link / Single Mode on OLDI TX 0 OR 1.
> > > 2. Single Link / Duplicate Mode on OLDI TX 0 and 1.
> > > 3. Dual Link / Single Mode on OLDI TX 0 and 1.
> > >
> > > Add "ti,rgb565-to-888" property to override 16bit output from a videoport
> > > for a bridge that only accepts 24bit RGB888 DPI input.
> > >
> > > On some boards the HDMI bridge takes a 24bit DPI input, but only 16 data
> > > pins are actually enabled from the SoC. This new property forces the
> > > output to be RGB565 on a specific video port if the bridge requests a
> > > 24bit RGB color space.
> > >
> > > This assumes that the video port is connected like so:
> > >
> > > SoC : Bridge
> > > R0 -> R3
> > > R1 -> R4
> > > R2 -> R5
> > > R3 -> R6
> > > R4 -> R7
> > > G0 -> G2
> > > G1 -> G3
> > > G2 -> G4
> > > G3 -> G5
> > > G4 -> G6
> > > G5 -> G7
> > > B0 -> B3
> > > B1 -> B4
> > > B2 -> B5
> > > B3 -> B6
> > > B4 -> B7
> > >
> > > On the bridge side R0->R2, G0->G1, B0->B2 would be tied to ground.
> > > The bridge sees 24bits of data, but the lsb's are always zero.
> >
> > Unless the bridge ignores the LSBs, that's not the right way to do 16 to
> > 24 bit. The LSBs should be connected to the MSB of the color component
> > to get full color range.
> >
> > >
> > > Signed-off-by: Aradhya Bhatia <[email protected]>
> > > ---
> > > .../bindings/display/ti/ti,am65x-dss.yaml | 25 +++++++++++++++++--
> > > 1 file changed, 23 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> > > index 6bbce921479d..11d9b3821409 100644
> > > --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> > > +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml
> > > @@ -80,15 +80,35 @@ properties:
> > > properties:
> > > port@0:
> > > - $ref: /schemas/graph.yaml#/properties/port
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > + unevaluatedProperties: false
> > > description:
> > > The DSS OLDI output port node form video port 1
> > > + properties:
> > > + ti,oldi-mode:
> > > + description: TI specific property to indicate the mode the OLDI TXes
> > > + and the display panel are connected in.
> > > + 0 -> OLDI TXes OFF (driver default for am625-dss)
> > > + 1 -> Single link, Single Mode (OLDI0) (driver default for am65x-dss)
> > > + 2 -> Single link, Single Mode (OLDI1)
> > > + 3 -> Single link, Duplicate Mode
> > > + 4 -> Dual link (Only Single Mode)
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + enum: [0, 1, 2, 3, 4]
> >
> > Wouldn't 'data-lanes' property work for this purpose.
> >
> > Generally, we don't put properties in port nodes.
> >
> Thank you for the suggestions Rob!
>
> I looked into the "data-lanes" property and it seems that the property
> alone would not be able to help distinguish between the "Single link,
> Duplicate mode" (Mode 3) and "Dual link, Single mode" (Mode 4). For both
> the cases, the property will look like "data-lanes = <0 1>;" in the DT
> node.
>
> I have an idea on what the driver could use along with the data-lanes
> property to ascertain the OLDI mode.
>
> By means of number of remote-endpoints in DTS.
> The OLDI output port of DSS can be made to have 2 remote endpoints when
> 2 panels are connected as "Single link, Duplicate Mode" vs only 1 remote
> endpoint for "Dual Link, Single Mode". Based on the count, the driver
> can distinguish between the two when both the data-lanes are activated
> in DT node.
You can only have 1 'remote-endpoint'. However, you can have multiple
endpoint nodes which is generally used for fanout (output) or muxed
(input) cases. Your case is fanout as it is the same data sent to
multiple connections.
data-lanes would be kind of redundant in that case since it would be 1
lane per endpoint.
>
> Let me know if you think this method would be appropriate.
> > > +
> > > port@1:
> > > - $ref: /schemas/graph.yaml#/properties/port
> > > + $ref: /schemas/graph.yaml#/$defs/port-base
> > > + unevaluatedProperties: false
> > > description:
> > > The DSS DPI output port node from video port 2
> > > + properties:
> > > + ti,rgb565-to-888:
> > > + description:
> > > + property to override DPI output to 16bit for 24bit bridge
> > > + type: boolean
> >
> > There's work underway for standard way to handle interface formats[1].
> > Please help/comment on that to make sure it works for you.
> >
> > Rob
> >
> > [1] https://lore.kernel.org/all/[email protected]/
>
> I also followed what this patch series is implementing. This seems to be
> applicable for cases where the DPI pins are drawn and forwarded towards
> a simple panel capable of accepting the raw parallel data.
>
> It does not cover for the bridges with lesser number of formats to
> support.
Not sure what you mean here, but raise it on that thread.
Rob