diff mbox series

[v2,5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter

Message ID 20241012073543.1388069-6-victor.liu@nxp.com (mailing list archive)
State New, archived
Headers show
Series Add ITE IT6263 LVDS to HDMI converter support | expand

Commit Message

Liu Ying Oct. 12, 2024, 7:35 a.m. UTC
Document ITE IT6263 LVDS to HDMI converter.

Product link:
https://www.ite.com.tw/en/product/cate1/IT6263

Signed-off-by: Liu Ying <victor.liu@nxp.com>
---
v2:
* Document number of LVDS link data lanes.  (Biju)
* Simplify ports property by dropping "oneOf".  (Rob)

 .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
 1 file changed, 276 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml

Comments

Dmitry Baryshkov Oct. 12, 2024, 8:30 a.m. UTC | #1
On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> Document ITE IT6263 LVDS to HDMI converter.
> 
> Product link:
> https://www.ite.com.tw/en/product/cate1/IT6263
> 
> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> ---
> v2:
> * Document number of LVDS link data lanes.  (Biju)
> * Simplify ports property by dropping "oneOf".  (Rob)
> 
>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
>  1 file changed, 276 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> new file mode 100644
> index 000000000000..bc2bbec07623
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> @@ -0,0 +1,276 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ITE IT6263 LVDS to HDMI converter
> +
> +maintainers:
> +  - Liu Ying <victor.liu@nxp.com>
> +
> +description: |
> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
> +  1.2 and backward compatible with DVI 1.0 specification.
> +
> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
> +
> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
> +  is supported at up to 768KHz.
> +
> +properties:

No LVDS data-mapping support?

> +  compatible:
> +    const: ite,it6263
> +
> +  reg:
> +    maxItems: 1
> +
> +  clocks:
> +    maxItems: 1
> +    description: audio master clock
> +
> +  clock-names:
> +    const: mclk
> +
> +  reset-gpios:
> +    maxItems: 1
> +
> +  ivdd-supply:
> +    description: 1.8V digital logic power
> +
> +  ovdd-supply:
> +    description: 3.3V I/O pin power
> +
> +  txavcc18-supply:
> +    description: 1.8V HDMI analog frontend power
> +
> +  txavcc33-supply:
> +    description: 3.3V HDMI analog frontend power
> +
> +  pvcc1-supply:
> +    description: 1.8V HDMI frontend core PLL power
> +
> +  pvcc2-supply:
> +    description: 1.8V HDMI frontend filter PLL power
> +
> +  avcc-supply:
> +    description: 3.3V LVDS frontend power
> +
> +  anvdd-supply:
> +    description: 1.8V LVDS frontend analog power
> +
> +  apvdd-supply:
> +    description: 1.8V LVDS frontend PLL power
> +
> +  "#sound-dai-cells":
> +    const: 0
> +
> +  ite,lvds-link-num-data-lanes:
> +    $ref: /schemas/types.yaml#/definitions/uint8
> +    enum: [3, 4, 5]
> +    description: number of data lanes per LVDS link

Please use data-lanes property inside the OF graph.

> +
> +  ite,i2s-audio-fifo-sources:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1
> +    maxItems: 4
> +    items:
> +      enum: [0, 1, 2, 3]
> +    description:
> +      Each array element indicates the pin number of an I2S serial data input
> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.

What does that mean from the board point of view? Routed audio links for
the multichannel audio?

> +
> +  ite,rl-channel-swap-audio-sources:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 1
> +    maxItems: 4
> +    uniqueItems: true
> +    items:
> +      enum: [0, 1, 2, 3]
> +    description:
> +      Each array element indicates an audio source whose right channel and left
> +      channel are swapped by this converter. For I2S, the element is the pin
> +      number of an I2S serial data input line. For S/PDIF, the element is always
> +      0.

Why?

> +
> +  ports:
> +    $ref: /schemas/graph.yaml#/properties/ports
> +
> +    properties:
> +      port@0:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description:
> +          The first LVDS input link.
> +          In dual-link LVDS mode, this link works together with the second LVDS
> +          input link, and one link receives odd pixels while the other receives
> +          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
> +          and dual-lvds-even-pixels properties when and only when dual-link LVDS
> +          mode is used.
> +
> +        properties:
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +            description: the first sink port for odd pixels
> +
> +          dual-lvds-even-pixels:
> +            type: boolean
> +            description: the first sink port for even pixels
> +
> +      port@1:
> +        $ref: /schemas/graph.yaml#/$defs/port-base
> +        unevaluatedProperties: false
> +        description: the second LVDS input link
> +
> +        properties:
> +          dual-lvds-even-pixels:
> +            type: boolean
> +            description: the second sink port for even pixels
> +
> +          dual-lvds-odd-pixels:
> +            type: boolean
> +            description: the second sink port for odd pixels
> +
> +        oneOf:
> +          - required: [dual-lvds-even-pixels]
> +          - required: [dual-lvds-odd-pixels]

This still allows one to specify that both ports provide odd pixels. Is
that expected? Also why do you need two properties which specify the
same option.

My suggestion would be to add a single root-level property which
specifies which port provides even pixel data.

> +
> +      port@2:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: video port for the HDMI output
> +
> +      port@3:
> +        $ref: /schemas/graph.yaml#/properties/port
> +        description: sound input port
> +
> +    required:
> +      - port@0
> +      - port@2
> +
> +required:
> +  - compatible
> +  - reg
> +  - ivdd-supply
> +  - ovdd-supply
> +  - txavcc18-supply
> +  - txavcc33-supply
> +  - pvcc1-supply
> +  - pvcc2-supply
> +  - avcc-supply
> +  - anvdd-supply
> +  - apvdd-supply
> +  - ite,lvds-link-num-data-lanes
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    /* single-link LVDS input */
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        hdmi@4c {
> +            compatible = "ite,it6263";
> +            reg = <0x4c>;
> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> +            ivdd-supply = <&reg_buck5>;
> +            ovdd-supply = <&reg_vext_3v3>;
> +            txavcc18-supply = <&reg_buck5>;
> +            txavcc33-supply = <&reg_vext_3v3>;
> +            pvcc1-supply = <&reg_buck5>;
> +            pvcc2-supply = <&reg_buck5>;
> +            avcc-supply = <&reg_vext_3v3>;
> +            anvdd-supply = <&reg_buck5>;
> +            apvdd-supply = <&reg_buck5>;
> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                port@0 {
> +                    reg = <0>;
> +
> +                    it6263_lvds_link1: endpoint {
> +                        remote-endpoint = <&ldb_lvds_ch0>;
> +                    };
> +                };
> +
> +                port@2 {
> +                    reg = <2>;
> +
> +                    it6263_out: endpoint {
> +                        remote-endpoint = <&hdmi_in>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> +
> +  - |
> +    /* dual-link LVDS input */
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        hdmi@4c {
> +            compatible = "ite,it6263";
> +            reg = <0x4c>;
> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> +            ivdd-supply = <&reg_buck5>;
> +            ovdd-supply = <&reg_vext_3v3>;
> +            txavcc18-supply = <&reg_buck5>;
> +            txavcc33-supply = <&reg_vext_3v3>;
> +            pvcc1-supply = <&reg_buck5>;
> +            pvcc2-supply = <&reg_buck5>;
> +            avcc-supply = <&reg_vext_3v3>;
> +            anvdd-supply = <&reg_buck5>;
> +            apvdd-supply = <&reg_buck5>;
> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                port@0 {
> +                    reg = <0>;
> +                    dual-lvds-odd-pixels;
> +
> +                    it6263_lvds_link1_dual: endpoint {
> +                        remote-endpoint = <&ldb_lvds_ch0>;
> +                    };
> +                };
> +
> +                port@1 {
> +                    reg = <1>;
> +                    dual-lvds-even-pixels;
> +
> +                    it6263_lvds_link2_dual: endpoint {
> +                        remote-endpoint = <&ldb_lvds_ch1>;
> +                    };
> +                };
> +
> +                port@2 {
> +                    reg = <2>;
> +
> +                    it6263_out_dual: endpoint {
> +                        remote-endpoint = <&hdmi_in>;
> +                    };
> +                };
> +            };
> +        };
> +    };
> -- 
> 2.34.1
>
Liu Ying Oct. 12, 2024, 9:14 a.m. UTC | #2
On 10/12/2024, Dmitry Baryshkov wrote:
> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
>> Document ITE IT6263 LVDS to HDMI converter.
>>
>> Product link:
>> https://www.ite.com.tw/en/product/cate1/IT6263
>>
>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>> ---
>> v2:
>> * Document number of LVDS link data lanes.  (Biju)
>> * Simplify ports property by dropping "oneOf".  (Rob)
>>
>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
>>  1 file changed, 276 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>> new file mode 100644
>> index 000000000000..bc2bbec07623
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>> @@ -0,0 +1,276 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: ITE IT6263 LVDS to HDMI converter
>> +
>> +maintainers:
>> +  - Liu Ying <victor.liu@nxp.com>
>> +
>> +description: |
>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
>> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
>> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
>> +  1.2 and backward compatible with DVI 1.0 specification.
>> +
>> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
>> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
>> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
>> +
>> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
>> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
>> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
>> +  is supported at up to 768KHz.
>> +
>> +properties:
> 
> No LVDS data-mapping support?

It is enough to document number of LVDS link data lanes
because OS should be able to determine the data-mapping
by looking at the number and the data-mapping capability
of the other side of the LVDS link. 

> 
>> +  compatible:
>> +    const: ite,it6263
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 1
>> +    description: audio master clock
>> +
>> +  clock-names:
>> +    const: mclk
>> +
>> +  reset-gpios:
>> +    maxItems: 1
>> +
>> +  ivdd-supply:
>> +    description: 1.8V digital logic power
>> +
>> +  ovdd-supply:
>> +    description: 3.3V I/O pin power
>> +
>> +  txavcc18-supply:
>> +    description: 1.8V HDMI analog frontend power
>> +
>> +  txavcc33-supply:
>> +    description: 3.3V HDMI analog frontend power
>> +
>> +  pvcc1-supply:
>> +    description: 1.8V HDMI frontend core PLL power
>> +
>> +  pvcc2-supply:
>> +    description: 1.8V HDMI frontend filter PLL power
>> +
>> +  avcc-supply:
>> +    description: 3.3V LVDS frontend power
>> +
>> +  anvdd-supply:
>> +    description: 1.8V LVDS frontend analog power
>> +
>> +  apvdd-supply:
>> +    description: 1.8V LVDS frontend PLL power
>> +
>> +  "#sound-dai-cells":
>> +    const: 0
>> +
>> +  ite,lvds-link-num-data-lanes:
>> +    $ref: /schemas/types.yaml#/definitions/uint8
>> +    enum: [3, 4, 5]
>> +    description: number of data lanes per LVDS link
> 
> Please use data-lanes property inside the OF graph.

In both port@0 and port@1?

> 
>> +
>> +  ite,i2s-audio-fifo-sources:
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    minItems: 1
>> +    maxItems: 4
>> +    items:
>> +      enum: [0, 1, 2, 3]
>> +    description:
>> +      Each array element indicates the pin number of an I2S serial data input
>> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
> 
> What does that mean from the board point of view? Routed audio links for
> the multichannel audio?

Yes, also for single channel audio.

> 
>> +
>> +  ite,rl-channel-swap-audio-sources:
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    minItems: 1
>> +    maxItems: 4
>> +    uniqueItems: true
>> +    items:
>> +      enum: [0, 1, 2, 3]
>> +    description:
>> +      Each array element indicates an audio source whose right channel and left
>> +      channel are swapped by this converter. For I2S, the element is the pin
>> +      number of an I2S serial data input line. For S/PDIF, the element is always
>> +      0.
> 
> Why?

Because this converter has the capability to swap right channel
and left channel and S/PDIF always uses audio source0. 

> 
>> +
>> +  ports:
>> +    $ref: /schemas/graph.yaml#/properties/ports
>> +
>> +    properties:
>> +      port@0:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description:
>> +          The first LVDS input link.
>> +          In dual-link LVDS mode, this link works together with the second LVDS
>> +          input link, and one link receives odd pixels while the other receives
>> +          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
>> +          and dual-lvds-even-pixels properties when and only when dual-link LVDS
>> +          mode is used.
>> +
>> +        properties:
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +            description: the first sink port for odd pixels
>> +
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +            description: the first sink port for even pixels
>> +
>> +      port@1:
>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>> +        unevaluatedProperties: false
>> +        description: the second LVDS input link
>> +
>> +        properties:
>> +          dual-lvds-even-pixels:
>> +            type: boolean
>> +            description: the second sink port for even pixels
>> +
>> +          dual-lvds-odd-pixels:
>> +            type: boolean
>> +            description: the second sink port for odd pixels
>> +
>> +        oneOf:
>> +          - required: [dual-lvds-even-pixels]
>> +          - required: [dual-lvds-odd-pixels]
> 
> This still allows one to specify that both ports provide odd pixels. Is
> that expected? Also why do you need two properties which specify the
> same option.

No, that is not expected. Description for port@0 already mentions
one link receives odd pixels while the other receives even pixels.

Two options are supported for dual-link LVDS, not the same option:
1) LVDS link1(port@0) gets odd pixels
   and
   LVDS link2(port@1) gets even pixels.

2) LVDS link1(port@0) gets even pixels
   and
   LVDS link2(port@1) gets odd pixels.
That's the reason why each port needs two properties to define
odd/even pixels.

> 
> My suggestion would be to add a single root-level property which
> specifies which port provides even pixel data.

That won't work.  The LVDS source side expects the ports of
the sink side specify dual-lvds-{odd,even}-pixels properties.

> 
>> +
>> +      port@2:
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +        description: video port for the HDMI output
>> +
>> +      port@3:
>> +        $ref: /schemas/graph.yaml#/properties/port
>> +        description: sound input port
>> +
>> +    required:
>> +      - port@0
>> +      - port@2
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - ivdd-supply
>> +  - ovdd-supply
>> +  - txavcc18-supply
>> +  - txavcc33-supply
>> +  - pvcc1-supply
>> +  - pvcc2-supply
>> +  - avcc-supply
>> +  - anvdd-supply
>> +  - apvdd-supply
>> +  - ite,lvds-link-num-data-lanes
>> +  - ports
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    /* single-link LVDS input */
>> +    #include <dt-bindings/gpio/gpio.h>
>> +
>> +    i2c {
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        hdmi@4c {
>> +            compatible = "ite,it6263";
>> +            reg = <0x4c>;
>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
>> +            ivdd-supply = <&reg_buck5>;
>> +            ovdd-supply = <&reg_vext_3v3>;
>> +            txavcc18-supply = <&reg_buck5>;
>> +            txavcc33-supply = <&reg_vext_3v3>;
>> +            pvcc1-supply = <&reg_buck5>;
>> +            pvcc2-supply = <&reg_buck5>;
>> +            avcc-supply = <&reg_vext_3v3>;
>> +            anvdd-supply = <&reg_buck5>;
>> +            apvdd-supply = <&reg_buck5>;
>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
>> +
>> +            ports {
>> +                #address-cells = <1>;
>> +                #size-cells = <0>;
>> +
>> +                port@0 {
>> +                    reg = <0>;
>> +
>> +                    it6263_lvds_link1: endpoint {
>> +                        remote-endpoint = <&ldb_lvds_ch0>;
>> +                    };
>> +                };
>> +
>> +                port@2 {
>> +                    reg = <2>;
>> +
>> +                    it6263_out: endpoint {
>> +                        remote-endpoint = <&hdmi_in>;
>> +                    };
>> +                };
>> +            };
>> +        };
>> +    };
>> +
>> +  - |
>> +    /* dual-link LVDS input */
>> +    #include <dt-bindings/gpio/gpio.h>
>> +
>> +    i2c {
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        hdmi@4c {
>> +            compatible = "ite,it6263";
>> +            reg = <0x4c>;
>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
>> +            ivdd-supply = <&reg_buck5>;
>> +            ovdd-supply = <&reg_vext_3v3>;
>> +            txavcc18-supply = <&reg_buck5>;
>> +            txavcc33-supply = <&reg_vext_3v3>;
>> +            pvcc1-supply = <&reg_buck5>;
>> +            pvcc2-supply = <&reg_buck5>;
>> +            avcc-supply = <&reg_vext_3v3>;
>> +            anvdd-supply = <&reg_buck5>;
>> +            apvdd-supply = <&reg_buck5>;
>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
>> +
>> +            ports {
>> +                #address-cells = <1>;
>> +                #size-cells = <0>;
>> +
>> +                port@0 {
>> +                    reg = <0>;
>> +                    dual-lvds-odd-pixels;
>> +
>> +                    it6263_lvds_link1_dual: endpoint {
>> +                        remote-endpoint = <&ldb_lvds_ch0>;
>> +                    };
>> +                };
>> +
>> +                port@1 {
>> +                    reg = <1>;
>> +                    dual-lvds-even-pixels;
>> +
>> +                    it6263_lvds_link2_dual: endpoint {
>> +                        remote-endpoint = <&ldb_lvds_ch1>;
>> +                    };
>> +                };
>> +
>> +                port@2 {
>> +                    reg = <2>;
>> +
>> +                    it6263_out_dual: endpoint {
>> +                        remote-endpoint = <&hdmi_in>;
>> +                    };
>> +                };
>> +            };
>> +        };
>> +    };
>> -- 
>> 2.34.1
>>
>
Dmitry Baryshkov Oct. 13, 2024, 11:45 p.m. UTC | #3
On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> On 10/12/2024, Dmitry Baryshkov wrote:
> > On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> >> Document ITE IT6263 LVDS to HDMI converter.
> >>
> >> Product link:
> >> https://www.ite.com.tw/en/product/cate1/IT6263
> >>
> >> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >> ---
> >> v2:
> >> * Document number of LVDS link data lanes.  (Biju)
> >> * Simplify ports property by dropping "oneOf".  (Rob)
> >>
> >>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> >>  1 file changed, 276 insertions(+)
> >>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >> new file mode 100644
> >> index 000000000000..bc2bbec07623
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >> @@ -0,0 +1,276 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: ITE IT6263 LVDS to HDMI converter
> >> +
> >> +maintainers:
> >> +  - Liu Ying <victor.liu@nxp.com>
> >> +
> >> +description: |
> >> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
> >> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> >> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> >> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
> >> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
> >> +  1.2 and backward compatible with DVI 1.0 specification.
> >> +
> >> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
> >> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
> >> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
> >> +
> >> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
> >> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
> >> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
> >> +  is supported at up to 768KHz.
> >> +
> >> +properties:
> > 
> > No LVDS data-mapping support?
> 
> It is enough to document number of LVDS link data lanes
> because OS should be able to determine the data-mapping
> by looking at the number and the data-mapping capability
> of the other side of the LVDS link. 

From what I can see, data-mapping is specified on the consumer sink side
of the LVDS link. This means it should go to the bridge's device node.

> 
> > 
> >> +  compatible:
> >> +    const: ite,it6263
> >> +
> >> +  reg:
> >> +    maxItems: 1
> >> +
> >> +  clocks:
> >> +    maxItems: 1
> >> +    description: audio master clock
> >> +
> >> +  clock-names:
> >> +    const: mclk
> >> +
> >> +  reset-gpios:
> >> +    maxItems: 1
> >> +
> >> +  ivdd-supply:
> >> +    description: 1.8V digital logic power
> >> +
> >> +  ovdd-supply:
> >> +    description: 3.3V I/O pin power
> >> +
> >> +  txavcc18-supply:
> >> +    description: 1.8V HDMI analog frontend power
> >> +
> >> +  txavcc33-supply:
> >> +    description: 3.3V HDMI analog frontend power
> >> +
> >> +  pvcc1-supply:
> >> +    description: 1.8V HDMI frontend core PLL power
> >> +
> >> +  pvcc2-supply:
> >> +    description: 1.8V HDMI frontend filter PLL power
> >> +
> >> +  avcc-supply:
> >> +    description: 3.3V LVDS frontend power
> >> +
> >> +  anvdd-supply:
> >> +    description: 1.8V LVDS frontend analog power
> >> +
> >> +  apvdd-supply:
> >> +    description: 1.8V LVDS frontend PLL power
> >> +
> >> +  "#sound-dai-cells":
> >> +    const: 0
> >> +
> >> +  ite,lvds-link-num-data-lanes:
> >> +    $ref: /schemas/types.yaml#/definitions/uint8
> >> +    enum: [3, 4, 5]
> >> +    description: number of data lanes per LVDS link
> > 
> > Please use data-lanes property inside the OF graph.
> 
> In both port@0 and port@1?

Yes

> 
> > 
> >> +
> >> +  ite,i2s-audio-fifo-sources:
> >> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +    minItems: 1
> >> +    maxItems: 4
> >> +    items:
> >> +      enum: [0, 1, 2, 3]
> >> +    description:
> >> +      Each array element indicates the pin number of an I2S serial data input
> >> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
> > 
> > What does that mean from the board point of view? Routed audio links for
> > the multichannel audio?
> 
> Yes, also for single channel audio.
> 
> > 
> >> +
> >> +  ite,rl-channel-swap-audio-sources:
> >> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >> +    minItems: 1
> >> +    maxItems: 4
> >> +    uniqueItems: true
> >> +    items:
> >> +      enum: [0, 1, 2, 3]
> >> +    description:
> >> +      Each array element indicates an audio source whose right channel and left
> >> +      channel are swapped by this converter. For I2S, the element is the pin
> >> +      number of an I2S serial data input line. For S/PDIF, the element is always
> >> +      0.
> > 
> > Why?
> 
> Because this converter has the capability to swap right channel
> and left channel and S/PDIF always uses audio source0. 
> 
> > 
> >> +
> >> +  ports:
> >> +    $ref: /schemas/graph.yaml#/properties/ports
> >> +
> >> +    properties:
> >> +      port@0:
> >> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >> +        unevaluatedProperties: false
> >> +        description:
> >> +          The first LVDS input link.
> >> +          In dual-link LVDS mode, this link works together with the second LVDS
> >> +          input link, and one link receives odd pixels while the other receives
> >> +          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
> >> +          and dual-lvds-even-pixels properties when and only when dual-link LVDS
> >> +          mode is used.
> >> +
> >> +        properties:
> >> +          dual-lvds-odd-pixels:
> >> +            type: boolean
> >> +            description: the first sink port for odd pixels
> >> +
> >> +          dual-lvds-even-pixels:
> >> +            type: boolean
> >> +            description: the first sink port for even pixels
> >> +
> >> +      port@1:
> >> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >> +        unevaluatedProperties: false
> >> +        description: the second LVDS input link
> >> +
> >> +        properties:
> >> +          dual-lvds-even-pixels:
> >> +            type: boolean
> >> +            description: the second sink port for even pixels
> >> +
> >> +          dual-lvds-odd-pixels:
> >> +            type: boolean
> >> +            description: the second sink port for odd pixels
> >> +
> >> +        oneOf:
> >> +          - required: [dual-lvds-even-pixels]
> >> +          - required: [dual-lvds-odd-pixels]
> > 
> > This still allows one to specify that both ports provide odd pixels. Is
> > that expected? Also why do you need two properties which specify the
> > same option.
> 
> No, that is not expected. Description for port@0 already mentions
> one link receives odd pixels while the other receives even pixels.

That's not expected, but permitted by the bindings.

> 
> Two options are supported for dual-link LVDS, not the same option:
> 1) LVDS link1(port@0) gets odd pixels
>    and
>    LVDS link2(port@1) gets even pixels.
> 
> 2) LVDS link1(port@0) gets even pixels
>    and
>    LVDS link2(port@1) gets odd pixels.
> That's the reason why each port needs two properties to define
> odd/even pixels.
> 
> > 
> > My suggestion would be to add a single root-level property which
> > specifies which port provides even pixel data.
> 
> That won't work.  The LVDS source side expects the ports of
> the sink side specify dual-lvds-{odd,even}-pixels properties.

I didn't notice that these properties are already defined.

As these properties are common between several schema files, please
extract them to a common schema file (like lvds.yaml).

> 
> > 
> >> +
> >> +      port@2:
> >> +        $ref: /schemas/graph.yaml#/properties/port
> >> +        description: video port for the HDMI output
> >> +
> >> +      port@3:
> >> +        $ref: /schemas/graph.yaml#/properties/port
> >> +        description: sound input port
> >> +
> >> +    required:
> >> +      - port@0
> >> +      - port@2
> >> +
> >> +required:
> >> +  - compatible
> >> +  - reg
> >> +  - ivdd-supply
> >> +  - ovdd-supply
> >> +  - txavcc18-supply
> >> +  - txavcc33-supply
> >> +  - pvcc1-supply
> >> +  - pvcc2-supply
> >> +  - avcc-supply
> >> +  - anvdd-supply
> >> +  - apvdd-supply
> >> +  - ite,lvds-link-num-data-lanes
> >> +  - ports
> >> +
> >> +additionalProperties: false
> >> +
> >> +examples:
> >> +  - |
> >> +    /* single-link LVDS input */
> >> +    #include <dt-bindings/gpio/gpio.h>
> >> +
> >> +    i2c {
> >> +        #address-cells = <1>;
> >> +        #size-cells = <0>;
> >> +
> >> +        hdmi@4c {
> >> +            compatible = "ite,it6263";
> >> +            reg = <0x4c>;
> >> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> >> +            ivdd-supply = <&reg_buck5>;
> >> +            ovdd-supply = <&reg_vext_3v3>;
> >> +            txavcc18-supply = <&reg_buck5>;
> >> +            txavcc33-supply = <&reg_vext_3v3>;
> >> +            pvcc1-supply = <&reg_buck5>;
> >> +            pvcc2-supply = <&reg_buck5>;
> >> +            avcc-supply = <&reg_vext_3v3>;
> >> +            anvdd-supply = <&reg_buck5>;
> >> +            apvdd-supply = <&reg_buck5>;
> >> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> >> +
> >> +            ports {
> >> +                #address-cells = <1>;
> >> +                #size-cells = <0>;
> >> +
> >> +                port@0 {
> >> +                    reg = <0>;
> >> +
> >> +                    it6263_lvds_link1: endpoint {
> >> +                        remote-endpoint = <&ldb_lvds_ch0>;
> >> +                    };
> >> +                };
> >> +
> >> +                port@2 {
> >> +                    reg = <2>;
> >> +
> >> +                    it6263_out: endpoint {
> >> +                        remote-endpoint = <&hdmi_in>;
> >> +                    };
> >> +                };
> >> +            };
> >> +        };
> >> +    };
> >> +
> >> +  - |
> >> +    /* dual-link LVDS input */
> >> +    #include <dt-bindings/gpio/gpio.h>
> >> +
> >> +    i2c {
> >> +        #address-cells = <1>;
> >> +        #size-cells = <0>;
> >> +
> >> +        hdmi@4c {
> >> +            compatible = "ite,it6263";
> >> +            reg = <0x4c>;
> >> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> >> +            ivdd-supply = <&reg_buck5>;
> >> +            ovdd-supply = <&reg_vext_3v3>;
> >> +            txavcc18-supply = <&reg_buck5>;
> >> +            txavcc33-supply = <&reg_vext_3v3>;
> >> +            pvcc1-supply = <&reg_buck5>;
> >> +            pvcc2-supply = <&reg_buck5>;
> >> +            avcc-supply = <&reg_vext_3v3>;
> >> +            anvdd-supply = <&reg_buck5>;
> >> +            apvdd-supply = <&reg_buck5>;
> >> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> >> +
> >> +            ports {
> >> +                #address-cells = <1>;
> >> +                #size-cells = <0>;
> >> +
> >> +                port@0 {
> >> +                    reg = <0>;
> >> +                    dual-lvds-odd-pixels;
> >> +
> >> +                    it6263_lvds_link1_dual: endpoint {
> >> +                        remote-endpoint = <&ldb_lvds_ch0>;
> >> +                    };
> >> +                };
> >> +
> >> +                port@1 {
> >> +                    reg = <1>;
> >> +                    dual-lvds-even-pixels;
> >> +
> >> +                    it6263_lvds_link2_dual: endpoint {
> >> +                        remote-endpoint = <&ldb_lvds_ch1>;
> >> +                    };
> >> +                };
> >> +
> >> +                port@2 {
> >> +                    reg = <2>;
> >> +
> >> +                    it6263_out_dual: endpoint {
> >> +                        remote-endpoint = <&hdmi_in>;
> >> +                    };
> >> +                };
> >> +            };
> >> +        };
> >> +    };
> >> -- 
> >> 2.34.1
> >>
> > 
> 
> -- 
> Regards,
> Liu Ying
>
Liu Ying Oct. 14, 2024, 5:33 a.m. UTC | #4
On 10/14/2024, Dmitry Baryshkov wrote:
> On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
>> On 10/12/2024, Dmitry Baryshkov wrote:
>>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
>>>> Document ITE IT6263 LVDS to HDMI converter.
>>>>
>>>> Product link:
>>>> https://www.ite.com.tw/en/product/cate1/IT6263
>>>>
>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>> ---
>>>> v2:
>>>> * Document number of LVDS link data lanes.  (Biju)
>>>> * Simplify ports property by dropping "oneOf".  (Rob)
>>>>
>>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
>>>>  1 file changed, 276 insertions(+)
>>>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>> new file mode 100644
>>>> index 000000000000..bc2bbec07623
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>> @@ -0,0 +1,276 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: ITE IT6263 LVDS to HDMI converter
>>>> +
>>>> +maintainers:
>>>> +  - Liu Ying <victor.liu@nxp.com>
>>>> +
>>>> +description: |
>>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
>>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
>>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
>>>> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
>>>> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
>>>> +  1.2 and backward compatible with DVI 1.0 specification.
>>>> +
>>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
>>>> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
>>>> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
>>>> +
>>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
>>>> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
>>>> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
>>>> +  is supported at up to 768KHz.
>>>> +
>>>> +properties:
>>>
>>> No LVDS data-mapping support?
>>
>> It is enough to document number of LVDS link data lanes
>> because OS should be able to determine the data-mapping
>> by looking at the number and the data-mapping capability
>> of the other side of the LVDS link. 
> 
> From what I can see, data-mapping is specified on the consumer sink side
> of the LVDS link. This means it should go to the bridge's device node.

Then, I won't define data-lanes, because data-mapping implies it,
e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.

Please let me know which one you prefer.

> 
>>
>>>
>>>> +  compatible:
>>>> +    const: ite,it6263
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  clocks:
>>>> +    maxItems: 1
>>>> +    description: audio master clock
>>>> +
>>>> +  clock-names:
>>>> +    const: mclk
>>>> +
>>>> +  reset-gpios:
>>>> +    maxItems: 1
>>>> +
>>>> +  ivdd-supply:
>>>> +    description: 1.8V digital logic power
>>>> +
>>>> +  ovdd-supply:
>>>> +    description: 3.3V I/O pin power
>>>> +
>>>> +  txavcc18-supply:
>>>> +    description: 1.8V HDMI analog frontend power
>>>> +
>>>> +  txavcc33-supply:
>>>> +    description: 3.3V HDMI analog frontend power
>>>> +
>>>> +  pvcc1-supply:
>>>> +    description: 1.8V HDMI frontend core PLL power
>>>> +
>>>> +  pvcc2-supply:
>>>> +    description: 1.8V HDMI frontend filter PLL power
>>>> +
>>>> +  avcc-supply:
>>>> +    description: 3.3V LVDS frontend power
>>>> +
>>>> +  anvdd-supply:
>>>> +    description: 1.8V LVDS frontend analog power
>>>> +
>>>> +  apvdd-supply:
>>>> +    description: 1.8V LVDS frontend PLL power
>>>> +
>>>> +  "#sound-dai-cells":
>>>> +    const: 0
>>>> +
>>>> +  ite,lvds-link-num-data-lanes:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint8
>>>> +    enum: [3, 4, 5]
>>>> +    description: number of data lanes per LVDS link
>>>
>>> Please use data-lanes property inside the OF graph.
>>
>> In both port@0 and port@1?
> 
> Yes

I'm assuming if data-mapping is defined, then no need to
define data-lanes.

> 
>>
>>>
>>>> +
>>>> +  ite,i2s-audio-fifo-sources:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> +    minItems: 1
>>>> +    maxItems: 4
>>>> +    items:
>>>> +      enum: [0, 1, 2, 3]
>>>> +    description:
>>>> +      Each array element indicates the pin number of an I2S serial data input
>>>> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
>>>
>>> What does that mean from the board point of view? Routed audio links for
>>> the multichannel audio?
>>
>> Yes, also for single channel audio.
>>
>>>
>>>> +
>>>> +  ite,rl-channel-swap-audio-sources:
>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>> +    minItems: 1
>>>> +    maxItems: 4
>>>> +    uniqueItems: true
>>>> +    items:
>>>> +      enum: [0, 1, 2, 3]
>>>> +    description:
>>>> +      Each array element indicates an audio source whose right channel and left
>>>> +      channel are swapped by this converter. For I2S, the element is the pin
>>>> +      number of an I2S serial data input line. For S/PDIF, the element is always
>>>> +      0.
>>>
>>> Why?
>>
>> Because this converter has the capability to swap right channel
>> and left channel and S/PDIF always uses audio source0. 
>>
>>>
>>>> +
>>>> +  ports:
>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>> +
>>>> +    properties:
>>>> +      port@0:
>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>> +        unevaluatedProperties: false
>>>> +        description:
>>>> +          The first LVDS input link.
>>>> +          In dual-link LVDS mode, this link works together with the second LVDS
>>>> +          input link, and one link receives odd pixels while the other receives
>>>> +          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
>>>> +          and dual-lvds-even-pixels properties when and only when dual-link LVDS
>>>> +          mode is used.
>>>> +
>>>> +        properties:
>>>> +          dual-lvds-odd-pixels:
>>>> +            type: boolean
>>>> +            description: the first sink port for odd pixels
>>>> +
>>>> +          dual-lvds-even-pixels:
>>>> +            type: boolean
>>>> +            description: the first sink port for even pixels
>>>> +
>>>> +      port@1:
>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>> +        unevaluatedProperties: false
>>>> +        description: the second LVDS input link
>>>> +
>>>> +        properties:
>>>> +          dual-lvds-even-pixels:
>>>> +            type: boolean
>>>> +            description: the second sink port for even pixels
>>>> +
>>>> +          dual-lvds-odd-pixels:
>>>> +            type: boolean
>>>> +            description: the second sink port for odd pixels
>>>> +
>>>> +        oneOf:
>>>> +          - required: [dual-lvds-even-pixels]
>>>> +          - required: [dual-lvds-odd-pixels]
>>>
>>> This still allows one to specify that both ports provide odd pixels. Is
>>> that expected? Also why do you need two properties which specify the
>>> same option.
>>
>> No, that is not expected. Description for port@0 already mentions
>> one link receives odd pixels while the other receives even pixels.
> 
> That's not expected, but permitted by the bindings.

It is not permitted by port@1. If "dual-lvds-odd-pixels;" is added
to port@1 in the dual-link LVDS example, the below warning will be
generated by dt_binding_check.

Documentation/devicetree/bindings/display/bridge/ite,it6263.example.dtb: hdmi@4c: ports:port@1: {'reg': [[1]], 'dual-lvds-even-pixels': True, 'dual-lvds-odd-pixels': True, 'endpoint': {'remote-endpoint': [[4294967295]]}} is valid under each of {'required': ['dual-lvds-odd-pixels']}, {'required': ['dual-lvds-even-pixels']}
	from schema $id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#

However, the binding for port@0 does allow DT writers to specify
both even and odd pixels. I raised similar concerns in v1 discussion.
According to Rob's comment in #devicetree IRC, the ports property
is simplified to this form and more description for port@0 is added
to tell when to specify the even/odd pixels.  If you know any better
way to indicate the constraints, please shout.

> 
>>
>> Two options are supported for dual-link LVDS, not the same option:
>> 1) LVDS link1(port@0) gets odd pixels
>>    and
>>    LVDS link2(port@1) gets even pixels.
>>
>> 2) LVDS link1(port@0) gets even pixels
>>    and
>>    LVDS link2(port@1) gets odd pixels.
>> That's the reason why each port needs two properties to define
>> odd/even pixels.
>>
>>>
>>> My suggestion would be to add a single root-level property which
>>> specifies which port provides even pixel data.
>>
>> That won't work.  The LVDS source side expects the ports of
>> the sink side specify dual-lvds-{odd,even}-pixels properties.
> 
> I didn't notice that these properties are already defined.
> 
> As these properties are common between several schema files, please
> extract them to a common schema file (like lvds.yaml).

I'm not sure how to do that. Is it obvious?
Please shed some light. 

Only two panel schema files are defining even/odd pixels now -
advantech,idk-2121wr.yaml and panel-simple-lvds-dual-ports.yaml.
Maybe, extract them later when more schema files(especially for
bridges) try to define the same?  I'd like to keep a low profile
for now.

> 
>>
>>>
>>>> +
>>>> +      port@2:
>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>> +        description: video port for the HDMI output
>>>> +
>>>> +      port@3:
>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>> +        description: sound input port
>>>> +
>>>> +    required:
>>>> +      - port@0
>>>> +      - port@2
>>>> +
>>>> +required:
>>>> +  - compatible
>>>> +  - reg
>>>> +  - ivdd-supply
>>>> +  - ovdd-supply
>>>> +  - txavcc18-supply
>>>> +  - txavcc33-supply
>>>> +  - pvcc1-supply
>>>> +  - pvcc2-supply
>>>> +  - avcc-supply
>>>> +  - anvdd-supply
>>>> +  - apvdd-supply
>>>> +  - ite,lvds-link-num-data-lanes
>>>> +  - ports
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +examples:
>>>> +  - |
>>>> +    /* single-link LVDS input */
>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>> +
>>>> +    i2c {
>>>> +        #address-cells = <1>;
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        hdmi@4c {
>>>> +            compatible = "ite,it6263";
>>>> +            reg = <0x4c>;
>>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
>>>> +            ivdd-supply = <&reg_buck5>;
>>>> +            ovdd-supply = <&reg_vext_3v3>;
>>>> +            txavcc18-supply = <&reg_buck5>;
>>>> +            txavcc33-supply = <&reg_vext_3v3>;
>>>> +            pvcc1-supply = <&reg_buck5>;
>>>> +            pvcc2-supply = <&reg_buck5>;
>>>> +            avcc-supply = <&reg_vext_3v3>;
>>>> +            anvdd-supply = <&reg_buck5>;
>>>> +            apvdd-supply = <&reg_buck5>;
>>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
>>>> +
>>>> +            ports {
>>>> +                #address-cells = <1>;
>>>> +                #size-cells = <0>;
>>>> +
>>>> +                port@0 {
>>>> +                    reg = <0>;
>>>> +
>>>> +                    it6263_lvds_link1: endpoint {
>>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
>>>> +                    };
>>>> +                };
>>>> +
>>>> +                port@2 {
>>>> +                    reg = <2>;
>>>> +
>>>> +                    it6263_out: endpoint {
>>>> +                        remote-endpoint = <&hdmi_in>;
>>>> +                    };
>>>> +                };
>>>> +            };
>>>> +        };
>>>> +    };
>>>> +
>>>> +  - |
>>>> +    /* dual-link LVDS input */
>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>> +
>>>> +    i2c {
>>>> +        #address-cells = <1>;
>>>> +        #size-cells = <0>;
>>>> +
>>>> +        hdmi@4c {
>>>> +            compatible = "ite,it6263";
>>>> +            reg = <0x4c>;
>>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
>>>> +            ivdd-supply = <&reg_buck5>;
>>>> +            ovdd-supply = <&reg_vext_3v3>;
>>>> +            txavcc18-supply = <&reg_buck5>;
>>>> +            txavcc33-supply = <&reg_vext_3v3>;
>>>> +            pvcc1-supply = <&reg_buck5>;
>>>> +            pvcc2-supply = <&reg_buck5>;
>>>> +            avcc-supply = <&reg_vext_3v3>;
>>>> +            anvdd-supply = <&reg_buck5>;
>>>> +            apvdd-supply = <&reg_buck5>;
>>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
>>>> +
>>>> +            ports {
>>>> +                #address-cells = <1>;
>>>> +                #size-cells = <0>;
>>>> +
>>>> +                port@0 {
>>>> +                    reg = <0>;
>>>> +                    dual-lvds-odd-pixels;
>>>> +
>>>> +                    it6263_lvds_link1_dual: endpoint {
>>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
>>>> +                    };
>>>> +                };
>>>> +
>>>> +                port@1 {
>>>> +                    reg = <1>;
>>>> +                    dual-lvds-even-pixels;
>>>> +
>>>> +                    it6263_lvds_link2_dual: endpoint {
>>>> +                        remote-endpoint = <&ldb_lvds_ch1>;
>>>> +                    };
>>>> +                };
>>>> +
>>>> +                port@2 {
>>>> +                    reg = <2>;
>>>> +
>>>> +                    it6263_out_dual: endpoint {
>>>> +                        remote-endpoint = <&hdmi_in>;
>>>> +                    };
>>>> +                };
>>>> +            };
>>>> +        };
>>>> +    };
>>>> -- 
>>>> 2.34.1
>>>>
>>>
>>
>> -- 
>> Regards,
>> Liu Ying
>>
>
Liu Ying Oct. 14, 2024, 5:54 a.m. UTC | #5
On 10/14/2024, Liu Ying wrote:
> On 10/14/2024, Dmitry Baryshkov wrote:
>> On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
>>> On 10/12/2024, Dmitry Baryshkov wrote:
>>>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
>>>>> Document ITE IT6263 LVDS to HDMI converter.
>>>>>
>>>>> Product link:
>>>>> https://www.ite.com.tw/en/product/cate1/IT6263
>>>>>
>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>>> ---
>>>>> v2:
>>>>> * Document number of LVDS link data lanes.  (Biju)
>>>>> * Simplify ports property by dropping "oneOf".  (Rob)
>>>>>
>>>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
>>>>>  1 file changed, 276 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..bc2bbec07623
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>>> @@ -0,0 +1,276 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +%YAML 1.2
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: ITE IT6263 LVDS to HDMI converter
>>>>> +
>>>>> +maintainers:
>>>>> +  - Liu Ying <victor.liu@nxp.com>
>>>>> +
>>>>> +description: |
>>>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
>>>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
>>>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
>>>>> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
>>>>> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
>>>>> +  1.2 and backward compatible with DVI 1.0 specification.
>>>>> +
>>>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
>>>>> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
>>>>> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
>>>>> +
>>>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
>>>>> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
>>>>> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
>>>>> +  is supported at up to 768KHz.
>>>>> +
>>>>> +properties:
>>>>
>>>> No LVDS data-mapping support?
>>>
>>> It is enough to document number of LVDS link data lanes
>>> because OS should be able to determine the data-mapping
>>> by looking at the number and the data-mapping capability
>>> of the other side of the LVDS link. 
>>
>> From what I can see, data-mapping is specified on the consumer sink side
>> of the LVDS link. This means it should go to the bridge's device node.
> 
> Then, I won't define data-lanes, because data-mapping implies it,
> e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> 
> Please let me know which one you prefer.
> 
>>
>>>
>>>>
>>>>> +  compatible:
>>>>> +    const: ite,it6263
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  clocks:
>>>>> +    maxItems: 1
>>>>> +    description: audio master clock
>>>>> +
>>>>> +  clock-names:
>>>>> +    const: mclk
>>>>> +
>>>>> +  reset-gpios:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  ivdd-supply:
>>>>> +    description: 1.8V digital logic power
>>>>> +
>>>>> +  ovdd-supply:
>>>>> +    description: 3.3V I/O pin power
>>>>> +
>>>>> +  txavcc18-supply:
>>>>> +    description: 1.8V HDMI analog frontend power
>>>>> +
>>>>> +  txavcc33-supply:
>>>>> +    description: 3.3V HDMI analog frontend power
>>>>> +
>>>>> +  pvcc1-supply:
>>>>> +    description: 1.8V HDMI frontend core PLL power
>>>>> +
>>>>> +  pvcc2-supply:
>>>>> +    description: 1.8V HDMI frontend filter PLL power
>>>>> +
>>>>> +  avcc-supply:
>>>>> +    description: 3.3V LVDS frontend power
>>>>> +
>>>>> +  anvdd-supply:
>>>>> +    description: 1.8V LVDS frontend analog power
>>>>> +
>>>>> +  apvdd-supply:
>>>>> +    description: 1.8V LVDS frontend PLL power
>>>>> +
>>>>> +  "#sound-dai-cells":
>>>>> +    const: 0
>>>>> +
>>>>> +  ite,lvds-link-num-data-lanes:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint8
>>>>> +    enum: [3, 4, 5]
>>>>> +    description: number of data lanes per LVDS link
>>>>
>>>> Please use data-lanes property inside the OF graph.
>>>
>>> In both port@0 and port@1?
>>
>> Yes
> 
> I'm assuming if data-mapping is defined, then no need to
> define data-lanes.
> 
>>
>>>
>>>>
>>>>> +
>>>>> +  ite,i2s-audio-fifo-sources:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>> +    minItems: 1
>>>>> +    maxItems: 4
>>>>> +    items:
>>>>> +      enum: [0, 1, 2, 3]
>>>>> +    description:
>>>>> +      Each array element indicates the pin number of an I2S serial data input
>>>>> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
>>>>
>>>> What does that mean from the board point of view? Routed audio links for
>>>> the multichannel audio?
>>>
>>> Yes, also for single channel audio.
>>>
>>>>
>>>>> +
>>>>> +  ite,rl-channel-swap-audio-sources:
>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>>>>> +    minItems: 1
>>>>> +    maxItems: 4
>>>>> +    uniqueItems: true
>>>>> +    items:
>>>>> +      enum: [0, 1, 2, 3]
>>>>> +    description:
>>>>> +      Each array element indicates an audio source whose right channel and left
>>>>> +      channel are swapped by this converter. For I2S, the element is the pin
>>>>> +      number of an I2S serial data input line. For S/PDIF, the element is always
>>>>> +      0.
>>>>
>>>> Why?
>>>
>>> Because this converter has the capability to swap right channel
>>> and left channel and S/PDIF always uses audio source0. 
>>>
>>>>
>>>>> +
>>>>> +  ports:
>>>>> +    $ref: /schemas/graph.yaml#/properties/ports
>>>>> +
>>>>> +    properties:
>>>>> +      port@0:
>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> +        unevaluatedProperties: false
>>>>> +        description:
>>>>> +          The first LVDS input link.
>>>>> +          In dual-link LVDS mode, this link works together with the second LVDS
>>>>> +          input link, and one link receives odd pixels while the other receives
>>>>> +          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
>>>>> +          and dual-lvds-even-pixels properties when and only when dual-link LVDS
>>>>> +          mode is used.
>>>>> +
>>>>> +        properties:
>>>>> +          dual-lvds-odd-pixels:
>>>>> +            type: boolean
>>>>> +            description: the first sink port for odd pixels
>>>>> +
>>>>> +          dual-lvds-even-pixels:
>>>>> +            type: boolean
>>>>> +            description: the first sink port for even pixels
>>>>> +
>>>>> +      port@1:
>>>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
>>>>> +        unevaluatedProperties: false
>>>>> +        description: the second LVDS input link
>>>>> +
>>>>> +        properties:
>>>>> +          dual-lvds-even-pixels:
>>>>> +            type: boolean
>>>>> +            description: the second sink port for even pixels
>>>>> +
>>>>> +          dual-lvds-odd-pixels:
>>>>> +            type: boolean
>>>>> +            description: the second sink port for odd pixels
>>>>> +
>>>>> +        oneOf:
>>>>> +          - required: [dual-lvds-even-pixels]
>>>>> +          - required: [dual-lvds-odd-pixels]
>>>>
>>>> This still allows one to specify that both ports provide odd pixels. Is
>>>> that expected? Also why do you need two properties which specify the
>>>> same option.
>>>
>>> No, that is not expected. Description for port@0 already mentions
>>> one link receives odd pixels while the other receives even pixels.
>>
>> That's not expected, but permitted by the bindings.
> 
> It is not permitted by port@1. If "dual-lvds-odd-pixels;" is added
> to port@1 in the dual-link LVDS example, the below warning will be
> generated by dt_binding_check.
> 
> Documentation/devicetree/bindings/display/bridge/ite,it6263.example.dtb: hdmi@4c: ports:port@1: {'reg': [[1]], 'dual-lvds-even-pixels': True, 'dual-lvds-odd-pixels': True, 'endpoint': {'remote-endpoint': [[4294967295]]}} is valid under each of {'required': ['dual-lvds-odd-pixels']}, {'required': ['dual-lvds-even-pixels']}
> 	from schema $id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> 
> However, the binding for port@0 does allow DT writers to specify
> both even and odd pixels. I raised similar concerns in v1 discussion.
> According to Rob's comment in #devicetree IRC, the ports property
> is simplified to this form and more description for port@0 is added
> to tell when to specify the even/odd pixels.  If you know any better
> way to indicate the constraints, please shout.

Dmitry, if the binding in v1 may pass dt_binding_check against
dtschema-2024.9, then it looks like all constraints are implemented.
But, it can't pass. 

> 
>>
>>>
>>> Two options are supported for dual-link LVDS, not the same option:
>>> 1) LVDS link1(port@0) gets odd pixels
>>>    and
>>>    LVDS link2(port@1) gets even pixels.
>>>
>>> 2) LVDS link1(port@0) gets even pixels
>>>    and
>>>    LVDS link2(port@1) gets odd pixels.
>>> That's the reason why each port needs two properties to define
>>> odd/even pixels.
>>>
>>>>
>>>> My suggestion would be to add a single root-level property which
>>>> specifies which port provides even pixel data.
>>>
>>> That won't work.  The LVDS source side expects the ports of
>>> the sink side specify dual-lvds-{odd,even}-pixels properties.
>>
>> I didn't notice that these properties are already defined.
>>
>> As these properties are common between several schema files, please
>> extract them to a common schema file (like lvds.yaml).
> 
> I'm not sure how to do that. Is it obvious?
> Please shed some light. 
> 
> Only two panel schema files are defining even/odd pixels now -
> advantech,idk-2121wr.yaml and panel-simple-lvds-dual-ports.yaml.
> Maybe, extract them later when more schema files(especially for
> bridges) try to define the same?  I'd like to keep a low profile
> for now.
> 
>>
>>>
>>>>
>>>>> +
>>>>> +      port@2:
>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>> +        description: video port for the HDMI output
>>>>> +
>>>>> +      port@3:
>>>>> +        $ref: /schemas/graph.yaml#/properties/port
>>>>> +        description: sound input port
>>>>> +
>>>>> +    required:
>>>>> +      - port@0
>>>>> +      - port@2
>>>>> +
>>>>> +required:
>>>>> +  - compatible
>>>>> +  - reg
>>>>> +  - ivdd-supply
>>>>> +  - ovdd-supply
>>>>> +  - txavcc18-supply
>>>>> +  - txavcc33-supply
>>>>> +  - pvcc1-supply
>>>>> +  - pvcc2-supply
>>>>> +  - avcc-supply
>>>>> +  - anvdd-supply
>>>>> +  - apvdd-supply
>>>>> +  - ite,lvds-link-num-data-lanes
>>>>> +  - ports
>>>>> +
>>>>> +additionalProperties: false
>>>>> +
>>>>> +examples:
>>>>> +  - |
>>>>> +    /* single-link LVDS input */
>>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>>> +
>>>>> +    i2c {
>>>>> +        #address-cells = <1>;
>>>>> +        #size-cells = <0>;
>>>>> +
>>>>> +        hdmi@4c {
>>>>> +            compatible = "ite,it6263";
>>>>> +            reg = <0x4c>;
>>>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
>>>>> +            ivdd-supply = <&reg_buck5>;
>>>>> +            ovdd-supply = <&reg_vext_3v3>;
>>>>> +            txavcc18-supply = <&reg_buck5>;
>>>>> +            txavcc33-supply = <&reg_vext_3v3>;
>>>>> +            pvcc1-supply = <&reg_buck5>;
>>>>> +            pvcc2-supply = <&reg_buck5>;
>>>>> +            avcc-supply = <&reg_vext_3v3>;
>>>>> +            anvdd-supply = <&reg_buck5>;
>>>>> +            apvdd-supply = <&reg_buck5>;
>>>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
>>>>> +
>>>>> +            ports {
>>>>> +                #address-cells = <1>;
>>>>> +                #size-cells = <0>;
>>>>> +
>>>>> +                port@0 {
>>>>> +                    reg = <0>;
>>>>> +
>>>>> +                    it6263_lvds_link1: endpoint {
>>>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
>>>>> +                    };
>>>>> +                };
>>>>> +
>>>>> +                port@2 {
>>>>> +                    reg = <2>;
>>>>> +
>>>>> +                    it6263_out: endpoint {
>>>>> +                        remote-endpoint = <&hdmi_in>;
>>>>> +                    };
>>>>> +                };
>>>>> +            };
>>>>> +        };
>>>>> +    };
>>>>> +
>>>>> +  - |
>>>>> +    /* dual-link LVDS input */
>>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>>> +
>>>>> +    i2c {
>>>>> +        #address-cells = <1>;
>>>>> +        #size-cells = <0>;
>>>>> +
>>>>> +        hdmi@4c {
>>>>> +            compatible = "ite,it6263";
>>>>> +            reg = <0x4c>;
>>>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
>>>>> +            ivdd-supply = <&reg_buck5>;
>>>>> +            ovdd-supply = <&reg_vext_3v3>;
>>>>> +            txavcc18-supply = <&reg_buck5>;
>>>>> +            txavcc33-supply = <&reg_vext_3v3>;
>>>>> +            pvcc1-supply = <&reg_buck5>;
>>>>> +            pvcc2-supply = <&reg_buck5>;
>>>>> +            avcc-supply = <&reg_vext_3v3>;
>>>>> +            anvdd-supply = <&reg_buck5>;
>>>>> +            apvdd-supply = <&reg_buck5>;
>>>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
>>>>> +
>>>>> +            ports {
>>>>> +                #address-cells = <1>;
>>>>> +                #size-cells = <0>;
>>>>> +
>>>>> +                port@0 {
>>>>> +                    reg = <0>;
>>>>> +                    dual-lvds-odd-pixels;
>>>>> +
>>>>> +                    it6263_lvds_link1_dual: endpoint {
>>>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
>>>>> +                    };
>>>>> +                };
>>>>> +
>>>>> +                port@1 {
>>>>> +                    reg = <1>;
>>>>> +                    dual-lvds-even-pixels;
>>>>> +
>>>>> +                    it6263_lvds_link2_dual: endpoint {
>>>>> +                        remote-endpoint = <&ldb_lvds_ch1>;
>>>>> +                    };
>>>>> +                };
>>>>> +
>>>>> +                port@2 {
>>>>> +                    reg = <2>;
>>>>> +
>>>>> +                    it6263_out_dual: endpoint {
>>>>> +                        remote-endpoint = <&hdmi_in>;
>>>>> +                    };
>>>>> +                };
>>>>> +            };
>>>>> +        };
>>>>> +    };
>>>>> -- 
>>>>> 2.34.1
>>>>>
>>>>
>>>
>>> -- 
>>> Regards,
>>> Liu Ying
>>>
>>
>
Dmitry Baryshkov Oct. 14, 2024, 7:07 a.m. UTC | #6
On Mon, Oct 14, 2024 at 01:33:44PM +0800, Liu Ying wrote:
> On 10/14/2024, Dmitry Baryshkov wrote:
> > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> >> On 10/12/2024, Dmitry Baryshkov wrote:
> >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> >>>> Document ITE IT6263 LVDS to HDMI converter.
> >>>>
> >>>> Product link:
> >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> >>>>
> >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>> ---
> >>>> v2:
> >>>> * Document number of LVDS link data lanes.  (Biju)
> >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> >>>>
> >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> >>>>  1 file changed, 276 insertions(+)
> >>>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..bc2bbec07623
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>> @@ -0,0 +1,276 @@
> >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>> +%YAML 1.2
> >>>> +---
> >>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>> +
> >>>> +title: ITE IT6263 LVDS to HDMI converter
> >>>> +
> >>>> +maintainers:
> >>>> +  - Liu Ying <victor.liu@nxp.com>
> >>>> +
> >>>> +description: |
> >>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
> >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> >>>> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
> >>>> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
> >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> >>>> +
> >>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
> >>>> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
> >>>> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
> >>>> +
> >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
> >>>> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
> >>>> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
> >>>> +  is supported at up to 768KHz.
> >>>> +
> >>>> +properties:
> >>>
> >>> No LVDS data-mapping support?
> >>
> >> It is enough to document number of LVDS link data lanes
> >> because OS should be able to determine the data-mapping
> >> by looking at the number and the data-mapping capability
> >> of the other side of the LVDS link. 
> > 
> > From what I can see, data-mapping is specified on the consumer sink side
> > of the LVDS link. This means it should go to the bridge's device node.
> 
> Then, I won't define data-lanes, because data-mapping implies it,
> e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> 
> Please let me know which one you prefer.

I'd prefer data-mapping.

> 
> > 
> >>
> >>>
> >>>> +  compatible:
> >>>> +    const: ite,it6263
> >>>> +
> >>>> +  reg:
> >>>> +    maxItems: 1
> >>>> +
> >>>> +  clocks:
> >>>> +    maxItems: 1
> >>>> +    description: audio master clock
> >>>> +
> >>>> +  clock-names:
> >>>> +    const: mclk
> >>>> +
> >>>> +  reset-gpios:
> >>>> +    maxItems: 1
> >>>> +
> >>>> +  ivdd-supply:
> >>>> +    description: 1.8V digital logic power
> >>>> +
> >>>> +  ovdd-supply:
> >>>> +    description: 3.3V I/O pin power
> >>>> +
> >>>> +  txavcc18-supply:
> >>>> +    description: 1.8V HDMI analog frontend power
> >>>> +
> >>>> +  txavcc33-supply:
> >>>> +    description: 3.3V HDMI analog frontend power
> >>>> +
> >>>> +  pvcc1-supply:
> >>>> +    description: 1.8V HDMI frontend core PLL power
> >>>> +
> >>>> +  pvcc2-supply:
> >>>> +    description: 1.8V HDMI frontend filter PLL power
> >>>> +
> >>>> +  avcc-supply:
> >>>> +    description: 3.3V LVDS frontend power
> >>>> +
> >>>> +  anvdd-supply:
> >>>> +    description: 1.8V LVDS frontend analog power
> >>>> +
> >>>> +  apvdd-supply:
> >>>> +    description: 1.8V LVDS frontend PLL power
> >>>> +
> >>>> +  "#sound-dai-cells":
> >>>> +    const: 0
> >>>> +
> >>>> +  ite,lvds-link-num-data-lanes:
> >>>> +    $ref: /schemas/types.yaml#/definitions/uint8
> >>>> +    enum: [3, 4, 5]
> >>>> +    description: number of data lanes per LVDS link
> >>>
> >>> Please use data-lanes property inside the OF graph.
> >>
> >> In both port@0 and port@1?
> > 
> > Yes
> 
> I'm assuming if data-mapping is defined, then no need to
> define data-lanes.

Yes

> 
> > 
> >>
> >>>
> >>>> +
> >>>> +  ite,i2s-audio-fifo-sources:
> >>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>> +    minItems: 1
> >>>> +    maxItems: 4
> >>>> +    items:
> >>>> +      enum: [0, 1, 2, 3]
> >>>> +    description:
> >>>> +      Each array element indicates the pin number of an I2S serial data input
> >>>> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
> >>>
> >>> What does that mean from the board point of view? Routed audio links for
> >>> the multichannel audio?
> >>
> >> Yes, also for single channel audio.
> >>
> >>>
> >>>> +
> >>>> +  ite,rl-channel-swap-audio-sources:
> >>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>> +    minItems: 1
> >>>> +    maxItems: 4
> >>>> +    uniqueItems: true
> >>>> +    items:
> >>>> +      enum: [0, 1, 2, 3]
> >>>> +    description:
> >>>> +      Each array element indicates an audio source whose right channel and left
> >>>> +      channel are swapped by this converter. For I2S, the element is the pin
> >>>> +      number of an I2S serial data input line. For S/PDIF, the element is always
> >>>> +      0.
> >>>
> >>> Why?
> >>
> >> Because this converter has the capability to swap right channel
> >> and left channel and S/PDIF always uses audio source0. 
> >>
> >>>
> >>>> +
> >>>> +  ports:
> >>>> +    $ref: /schemas/graph.yaml#/properties/ports
> >>>> +
> >>>> +    properties:
> >>>> +      port@0:
> >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>> +        unevaluatedProperties: false
> >>>> +        description:
> >>>> +          The first LVDS input link.
> >>>> +          In dual-link LVDS mode, this link works together with the second LVDS
> >>>> +          input link, and one link receives odd pixels while the other receives
> >>>> +          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
> >>>> +          and dual-lvds-even-pixels properties when and only when dual-link LVDS
> >>>> +          mode is used.
> >>>> +
> >>>> +        properties:
> >>>> +          dual-lvds-odd-pixels:
> >>>> +            type: boolean
> >>>> +            description: the first sink port for odd pixels
> >>>> +
> >>>> +          dual-lvds-even-pixels:
> >>>> +            type: boolean
> >>>> +            description: the first sink port for even pixels
> >>>> +
> >>>> +      port@1:
> >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>> +        unevaluatedProperties: false
> >>>> +        description: the second LVDS input link
> >>>> +
> >>>> +        properties:
> >>>> +          dual-lvds-even-pixels:
> >>>> +            type: boolean
> >>>> +            description: the second sink port for even pixels
> >>>> +
> >>>> +          dual-lvds-odd-pixels:
> >>>> +            type: boolean
> >>>> +            description: the second sink port for odd pixels
> >>>> +
> >>>> +        oneOf:
> >>>> +          - required: [dual-lvds-even-pixels]
> >>>> +          - required: [dual-lvds-odd-pixels]
> >>>
> >>> This still allows one to specify that both ports provide odd pixels. Is
> >>> that expected? Also why do you need two properties which specify the
> >>> same option.
> >>
> >> No, that is not expected. Description for port@0 already mentions
> >> one link receives odd pixels while the other receives even pixels.
> > 
> > That's not expected, but permitted by the bindings.
> 
> It is not permitted by port@1. If "dual-lvds-odd-pixels;" is added
> to port@1 in the dual-link LVDS example, the below warning will be
> generated by dt_binding_check.

It is permitted for both ports to have the same value (e.g. mark both
ports as odd or even).

> 
> Documentation/devicetree/bindings/display/bridge/ite,it6263.example.dtb: hdmi@4c: ports:port@1: {'reg': [[1]], 'dual-lvds-even-pixels': True, 'dual-lvds-odd-pixels': True, 'endpoint': {'remote-endpoint': [[4294967295]]}} is valid under each of {'required': ['dual-lvds-odd-pixels']}, {'required': ['dual-lvds-even-pixels']}
> 	from schema $id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> 
> However, the binding for port@0 does allow DT writers to specify
> both even and odd pixels. I raised similar concerns in v1 discussion.
> According to Rob's comment in #devicetree IRC, the ports property
> is simplified to this form and more description for port@0 is added
> to tell when to specify the even/odd pixels.  If you know any better
> way to indicate the constraints, please shout.

I don't think we can express that in schema. I don't like the bindings
(and would have preferred a single property instead), but as the
bindings are already defined, let's use them.

> 
> > 
> >>
> >> Two options are supported for dual-link LVDS, not the same option:
> >> 1) LVDS link1(port@0) gets odd pixels
> >>    and
> >>    LVDS link2(port@1) gets even pixels.
> >>
> >> 2) LVDS link1(port@0) gets even pixels
> >>    and
> >>    LVDS link2(port@1) gets odd pixels.
> >> That's the reason why each port needs two properties to define
> >> odd/even pixels.
> >>
> >>>
> >>> My suggestion would be to add a single root-level property which
> >>> specifies which port provides even pixel data.
> >>
> >> That won't work.  The LVDS source side expects the ports of
> >> the sink side specify dual-lvds-{odd,even}-pixels properties.
> > 
> > I didn't notice that these properties are already defined.
> > 
> > As these properties are common between several schema files, please
> > extract them to a common schema file (like lvds.yaml).
> 
> I'm not sure how to do that. Is it obvious?
> Please shed some light. 
> 
> Only two panel schema files are defining even/odd pixels now -
> advantech,idk-2121wr.yaml and panel-simple-lvds-dual-ports.yaml.
> Maybe, extract them later when more schema files(especially for
> bridges) try to define the same?  I'd like to keep a low profile
> for now.

I'd say, please extract those now. Adding third is more than enough and
should be avoided. Extracting is pretty simple. One patch to move the
definition and descriptions from panel-simple-lvds-dual-ports to a
common location (e.g. lvds-dual-ports.yaml). Leave the required
constrains in place. Second patch is to add oneOf constraints to the
ports. port@0 might get the same oneOf + the
dual-lvds-{odd,even}-pixels:false case, allowing a single-port
definition.

> 
> > 
> >>
> >>>
> >>>> +
> >>>> +      port@2:
> >>>> +        $ref: /schemas/graph.yaml#/properties/port
> >>>> +        description: video port for the HDMI output
> >>>> +
> >>>> +      port@3:
> >>>> +        $ref: /schemas/graph.yaml#/properties/port
> >>>> +        description: sound input port
> >>>> +
> >>>> +    required:
> >>>> +      - port@0
> >>>> +      - port@2
> >>>> +
> >>>> +required:
> >>>> +  - compatible
> >>>> +  - reg
> >>>> +  - ivdd-supply
> >>>> +  - ovdd-supply
> >>>> +  - txavcc18-supply
> >>>> +  - txavcc33-supply
> >>>> +  - pvcc1-supply
> >>>> +  - pvcc2-supply
> >>>> +  - avcc-supply
> >>>> +  - anvdd-supply
> >>>> +  - apvdd-supply
> >>>> +  - ite,lvds-link-num-data-lanes
> >>>> +  - ports
> >>>> +
> >>>> +additionalProperties: false
> >>>> +
> >>>> +examples:
> >>>> +  - |
> >>>> +    /* single-link LVDS input */
> >>>> +    #include <dt-bindings/gpio/gpio.h>
> >>>> +
> >>>> +    i2c {
> >>>> +        #address-cells = <1>;
> >>>> +        #size-cells = <0>;
> >>>> +
> >>>> +        hdmi@4c {
> >>>> +            compatible = "ite,it6263";
> >>>> +            reg = <0x4c>;
> >>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> >>>> +            ivdd-supply = <&reg_buck5>;
> >>>> +            ovdd-supply = <&reg_vext_3v3>;
> >>>> +            txavcc18-supply = <&reg_buck5>;
> >>>> +            txavcc33-supply = <&reg_vext_3v3>;
> >>>> +            pvcc1-supply = <&reg_buck5>;
> >>>> +            pvcc2-supply = <&reg_buck5>;
> >>>> +            avcc-supply = <&reg_vext_3v3>;
> >>>> +            anvdd-supply = <&reg_buck5>;
> >>>> +            apvdd-supply = <&reg_buck5>;
> >>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> >>>> +
> >>>> +            ports {
> >>>> +                #address-cells = <1>;
> >>>> +                #size-cells = <0>;
> >>>> +
> >>>> +                port@0 {
> >>>> +                    reg = <0>;
> >>>> +
> >>>> +                    it6263_lvds_link1: endpoint {
> >>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
> >>>> +                    };
> >>>> +                };
> >>>> +
> >>>> +                port@2 {
> >>>> +                    reg = <2>;
> >>>> +
> >>>> +                    it6263_out: endpoint {
> >>>> +                        remote-endpoint = <&hdmi_in>;
> >>>> +                    };
> >>>> +                };
> >>>> +            };
> >>>> +        };
> >>>> +    };
> >>>> +
> >>>> +  - |
> >>>> +    /* dual-link LVDS input */
> >>>> +    #include <dt-bindings/gpio/gpio.h>
> >>>> +
> >>>> +    i2c {
> >>>> +        #address-cells = <1>;
> >>>> +        #size-cells = <0>;
> >>>> +
> >>>> +        hdmi@4c {
> >>>> +            compatible = "ite,it6263";
> >>>> +            reg = <0x4c>;
> >>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> >>>> +            ivdd-supply = <&reg_buck5>;
> >>>> +            ovdd-supply = <&reg_vext_3v3>;
> >>>> +            txavcc18-supply = <&reg_buck5>;
> >>>> +            txavcc33-supply = <&reg_vext_3v3>;
> >>>> +            pvcc1-supply = <&reg_buck5>;
> >>>> +            pvcc2-supply = <&reg_buck5>;
> >>>> +            avcc-supply = <&reg_vext_3v3>;
> >>>> +            anvdd-supply = <&reg_buck5>;
> >>>> +            apvdd-supply = <&reg_buck5>;
> >>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> >>>> +
> >>>> +            ports {
> >>>> +                #address-cells = <1>;
> >>>> +                #size-cells = <0>;
> >>>> +
> >>>> +                port@0 {
> >>>> +                    reg = <0>;
> >>>> +                    dual-lvds-odd-pixels;
> >>>> +
> >>>> +                    it6263_lvds_link1_dual: endpoint {
> >>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
> >>>> +                    };
> >>>> +                };
> >>>> +
> >>>> +                port@1 {
> >>>> +                    reg = <1>;
> >>>> +                    dual-lvds-even-pixels;
> >>>> +
> >>>> +                    it6263_lvds_link2_dual: endpoint {
> >>>> +                        remote-endpoint = <&ldb_lvds_ch1>;
> >>>> +                    };
> >>>> +                };
> >>>> +
> >>>> +                port@2 {
> >>>> +                    reg = <2>;
> >>>> +
> >>>> +                    it6263_out_dual: endpoint {
> >>>> +                        remote-endpoint = <&hdmi_in>;
> >>>> +                    };
> >>>> +                };
> >>>> +            };
> >>>> +        };
> >>>> +    };
> >>>> -- 
> >>>> 2.34.1
> >>>>
> >>>
> >>
> >> -- 
> >> Regards,
> >> Liu Ying
> >>
> > 
> 
> -- 
> Regards,
> Liu Ying
>
Biju Das Oct. 14, 2024, 7:39 a.m. UTC | #7
Hi Liu and Dmitry,

> -----Original Message-----
> From: Liu Ying <victor.liu@nxp.com>
> Sent: Monday, October 14, 2024 6:34 AM
> Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> 
> On 10/14/2024, Dmitry Baryshkov wrote:
> > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> >> On 10/12/2024, Dmitry Baryshkov wrote:
> >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> >>>> Document ITE IT6263 LVDS to HDMI converter.
> >>>>
> >>>> Product link:
> >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> >>>>
> >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>> ---
> >>>> v2:
> >>>> * Document number of LVDS link data lanes.  (Biju)
> >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> >>>>
> >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> >>>>  1 file changed, 276 insertions(+)
> >>>>  create mode 100644
> >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..bc2bbec07623
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y
> >>>> +++ aml
> >>>> @@ -0,0 +1,276 @@
> >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> >>>> +1.2
> >>>> +---
> >>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>> +
> >>>> +title: ITE IT6263 LVDS to HDMI converter
> >>>> +
> >>>> +maintainers:
> >>>> +  - Liu Ying <victor.liu@nxp.com>
> >>>> +
> >>>> +description: |
> >>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread
> >>>> +Spectrum) LVDS
> >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a
> >>>> +transmitter,
> >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> >>>> +  The built-in LVDS receiver can support single-link and dual-link
> >>>> +LVDS inputs,
> >>>> +  and the built-in HDMI transmitter is fully compliant with HDMI
> >>>> +1.4a/3D, HDCP
> >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> >>>> +
> >>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S
> >>>> + digital audio,  with sampling rate up to 192KHz and sample size
> >>>> + up to 24 bits. In addition,  an S/PDIF input port takes in compressed audio of up to 192KHz
> frame rate.
> >>>> +
> >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> >>>> + the four I2S input ports or the  S/PDIF input port.  With both
> >>>> + interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> >>>> +
> >>>> +properties:
> >>>
> >>> No LVDS data-mapping support?
> >>
> >> It is enough to document number of LVDS link data lanes because OS
> >> should be able to determine the data-mapping by looking at the number
> >> and the data-mapping capability of the other side of the LVDS link.
> >
> > From what I can see, data-mapping is specified on the consumer sink
> > side of the LVDS link. This means it should go to the bridge's device node.
> 
> Then, I won't define data-lanes, because data-mapping implies it, e.g., jeida-24 implies data lanes
> 0/1/2/3, see lvds-data-mapping.yaml.
> 
> Please let me know which one you prefer.

Assume a top level use case where a user changes the format from JEDAI to VESA using On screen 
display or modetest(if some one adds support for lvds-mapping) then setting of the lvds data mapping
should be dynamic.

Maybe for initial version hardcode with JEDAI or VESA as default and provide a way to override
the host driver and bridge with requested lvds-data mapping dynamically later??

Cheers,
Biju
Biju Das Oct. 14, 2024, 7:58 a.m. UTC | #8
> -----Original Message-----
> From: Biju Das
> Sent: Monday, October 14, 2024 8:39 AM
> To: Liu Ying <victor.liu@nxp.com>; Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Cc: dri-devel@lists.freedesktop.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; andrzej.hajda@intel.com;
> neil.armstrong@linaro.org; rfoss@kernel.org; laurent.pinchart <laurent.pinchart@ideasonboard.com>;
> jonas@kwiboo.se; jernej.skrabec@gmail.com; airlied@gmail.com; simona@ffwll.ch;
> maarten.lankhorst@linux.intel.com; mripard@kernel.org; tzimmermann@suse.de; robh@kernel.org;
> krzk+dt@kernel.org; conor+dt@kernel.org; shawnguo@kernel.org; s.hauer@pengutronix.de;
> kernel@pengutronix.de; festevam@gmail.com; catalin.marinas@arm.com; will@kernel.org;
> quic_bjorande@quicinc.com; geert+renesas@glider.be; arnd@arndb.de; nfraprado@collabora.com;
> o.rempel@pengutronix.de; y.moog@phytec.de; marex@denx.de; isaac.scott@ideasonboard.com
> Subject: RE: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> 
> Hi Liu and Dmitry,
> 
> > -----Original Message-----
> > From: Liu Ying <victor.liu@nxp.com>
> > Sent: Monday, October 14, 2024 6:34 AM
> > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE
> > IT6263 LVDS to HDMI converter
> >
> > On 10/14/2024, Dmitry Baryshkov wrote:
> > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> > >> On 10/12/2024, Dmitry Baryshkov wrote:
> > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> > >>>> Document ITE IT6263 LVDS to HDMI converter.
> > >>>>
> > >>>> Product link:
> > >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> > >>>>
> > >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > >>>> ---
> > >>>> v2:
> > >>>> * Document number of LVDS link data lanes.  (Biju)
> > >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> > >>>>
> > >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> > >>>>  1 file changed, 276 insertions(+)  create mode 100644
> > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> > >>>>
> > >>>> diff --git
> > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yam
> > >>>> l
> > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yam
> > >>>> l
> > >>>> new file mode 100644
> > >>>> index 000000000000..bc2bbec07623
> > >>>> --- /dev/null
> > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263
> > >>>> +++ .y
> > >>>> +++ aml
> > >>>> @@ -0,0 +1,276 @@
> > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> > >>>> +1.2
> > >>>> +---
> > >>>> +$id:
> > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > >>>> +
> > >>>> +title: ITE IT6263 LVDS to HDMI converter
> > >>>> +
> > >>>> +maintainers:
> > >>>> +  - Liu Ying <victor.liu@nxp.com>
> > >>>> +
> > >>>> +description: |
> > >>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread
> > >>>> +Spectrum) LVDS
> > >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a
> > >>>> +transmitter,
> > >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> > >>>> +  The built-in LVDS receiver can support single-link and
> > >>>> +dual-link LVDS inputs,
> > >>>> +  and the built-in HDMI transmitter is fully compliant with HDMI
> > >>>> +1.4a/3D, HDCP
> > >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> > >>>> +
> > >>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S
> > >>>> + digital audio,  with sampling rate up to 192KHz and sample size
> > >>>> + up to 24 bits. In addition,  an S/PDIF input port takes in
> > >>>> + compressed audio of up to 192KHz
> > frame rate.
> > >>>> +
> > >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> > >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> > >>>> + the four I2S input ports or the  S/PDIF input port.  With both
> > >>>> + interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> > >>>> +
> > >>>> +properties:
> > >>>
> > >>> No LVDS data-mapping support?
> > >>
> > >> It is enough to document number of LVDS link data lanes because OS
> > >> should be able to determine the data-mapping by looking at the
> > >> number and the data-mapping capability of the other side of the LVDS link.
> > >
> > > From what I can see, data-mapping is specified on the consumer sink
> > > side of the LVDS link. This means it should go to the bridge's device node.
> >
> > Then, I won't define data-lanes, because data-mapping implies it,
> > e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> >
> > Please let me know which one you prefer.
> 
> Assume a top level use case where a user changes the format from JEDAI to VESA using On screen display
> or modetest(if some one adds support for lvds-mapping) then setting of the lvds data mapping should be
> dynamic.
> 
> Maybe for initial version hardcode with JEDAI or VESA as default and provide a way to override the
> host driver and bridge with requested lvds-data mapping dynamically later??
> 

Maybe use ret = drm_of_lvds_get_data_mapping(bus_node); to get LVDS data mapping see LVDS panel driver??
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/lvds-codec.c?h=next-20241011#n173

Cheeers,
Biju
Dmitry Baryshkov Oct. 14, 2024, 8:04 a.m. UTC | #9
On Mon, Oct 14, 2024 at 07:39:16AM +0000, Biju Das wrote:
> Hi Liu and Dmitry,
> 
> > -----Original Message-----
> > From: Liu Ying <victor.liu@nxp.com>
> > Sent: Monday, October 14, 2024 6:34 AM
> > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> > 
> > On 10/14/2024, Dmitry Baryshkov wrote:
> > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> > >> On 10/12/2024, Dmitry Baryshkov wrote:
> > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> > >>>> Document ITE IT6263 LVDS to HDMI converter.
> > >>>>
> > >>>> Product link:
> > >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> > >>>>
> > >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > >>>> ---
> > >>>> v2:
> > >>>> * Document number of LVDS link data lanes.  (Biju)
> > >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> > >>>>
> > >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> > >>>>  1 file changed, 276 insertions(+)
> > >>>>  create mode 100644
> > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> > >>>>
> > >>>> diff --git
> > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> > >>>> new file mode 100644
> > >>>> index 000000000000..bc2bbec07623
> > >>>> --- /dev/null
> > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y
> > >>>> +++ aml
> > >>>> @@ -0,0 +1,276 @@
> > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> > >>>> +1.2
> > >>>> +---
> > >>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > >>>> +
> > >>>> +title: ITE IT6263 LVDS to HDMI converter
> > >>>> +
> > >>>> +maintainers:
> > >>>> +  - Liu Ying <victor.liu@nxp.com>
> > >>>> +
> > >>>> +description: |
> > >>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread
> > >>>> +Spectrum) LVDS
> > >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a
> > >>>> +transmitter,
> > >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> > >>>> +  The built-in LVDS receiver can support single-link and dual-link
> > >>>> +LVDS inputs,
> > >>>> +  and the built-in HDMI transmitter is fully compliant with HDMI
> > >>>> +1.4a/3D, HDCP
> > >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> > >>>> +
> > >>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S
> > >>>> + digital audio,  with sampling rate up to 192KHz and sample size
> > >>>> + up to 24 bits. In addition,  an S/PDIF input port takes in compressed audio of up to 192KHz
> > frame rate.
> > >>>> +
> > >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> > >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> > >>>> + the four I2S input ports or the  S/PDIF input port.  With both
> > >>>> + interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> > >>>> +
> > >>>> +properties:
> > >>>
> > >>> No LVDS data-mapping support?
> > >>
> > >> It is enough to document number of LVDS link data lanes because OS
> > >> should be able to determine the data-mapping by looking at the number
> > >> and the data-mapping capability of the other side of the LVDS link.
> > >
> > > From what I can see, data-mapping is specified on the consumer sink
> > > side of the LVDS link. This means it should go to the bridge's device node.
> > 
> > Then, I won't define data-lanes, because data-mapping implies it, e.g., jeida-24 implies data lanes
> > 0/1/2/3, see lvds-data-mapping.yaml.
> > 
> > Please let me know which one you prefer.
> 
> Assume a top level use case where a user changes the format from JEDAI to VESA using On screen 
> display or modetest(if some one adds support for lvds-mapping) then setting of the lvds data mapping
> should be dynamic.
> 
> Maybe for initial version hardcode with JEDAI or VESA as default and provide a way to override
> the host driver and bridge with requested lvds-data mapping dynamically later??

The ite,lvds-link-num-data-lanes property should be removed, it is not
standard. I foresee two ways to specify the number of lanes used: either
the data-lanes property or the data-mapping property. Granted that
data-mapping replaces the data-lanes functionality for LVDS links, I
think it's better to use it from the start.

Frankly speaking, what is the usecase for specifying the data mapping
dynamically? What kind of uAPI do you have in mind and what is the
usecase for it?
Biju Das Oct. 14, 2024, 8:09 a.m. UTC | #10
Hi Dmitry,

> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Sent: Monday, October 14, 2024 9:04 AM
> Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> 
> On Mon, Oct 14, 2024 at 07:39:16AM +0000, Biju Das wrote:
> > Hi Liu and Dmitry,
> >
> > > -----Original Message-----
> > > From: Liu Ying <victor.liu@nxp.com>
> > > Sent: Monday, October 14, 2024 6:34 AM
> > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE
> > > IT6263 LVDS to HDMI converter
> > >
> > > On 10/14/2024, Dmitry Baryshkov wrote:
> > > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> > > >> On 10/12/2024, Dmitry Baryshkov wrote:
> > > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> > > >>>> Document ITE IT6263 LVDS to HDMI converter.
> > > >>>>
> > > >>>> Product link:
> > > >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> > > >>>>
> > > >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > > >>>> ---
> > > >>>> v2:
> > > >>>> * Document number of LVDS link data lanes.  (Biju)
> > > >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> > > >>>>
> > > >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> > > >>>>  1 file changed, 276 insertions(+)  create mode 100644
> > > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yam
> > > >>>> l
> > > >>>>
> > > >>>> diff --git
> > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.y
> > > >>>> aml
> > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y
> > > >>>> aml
> > > >>>> new file mode 100644
> > > >>>> index 000000000000..bc2bbec07623
> > > >>>> --- /dev/null
> > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it62
> > > >>>> +++ 63.y
> > > >>>> +++ aml
> > > >>>> @@ -0,0 +1,276 @@
> > > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > >>>> +%YAML
> > > >>>> +1.2
> > > >>>> +---
> > > >>>> +$id:
> > > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > >>>> +
> > > >>>> +title: ITE IT6263 LVDS to HDMI converter
> > > >>>> +
> > > >>>> +maintainers:
> > > >>>> +  - Liu Ying <victor.liu@nxp.com>
> > > >>>> +
> > > >>>> +description: |
> > > >>>> +  The IT6263 is a high-performance single-chip
> > > >>>> +De-SSC(De-Spread
> > > >>>> +Spectrum) LVDS
> > > >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI
> > > >>>> +1.4a transmitter,
> > > >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> > > >>>> +  The built-in LVDS receiver can support single-link and
> > > >>>> +dual-link LVDS inputs,
> > > >>>> +  and the built-in HDMI transmitter is fully compliant with
> > > >>>> +HDMI 1.4a/3D, HDCP
> > > >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> > > >>>> +
> > > >>>> +  The IT6263 also encodes and transmits up to 8 channels of
> > > >>>> + I2S digital audio,  with sampling rate up to 192KHz and
> > > >>>> + sample size up to 24 bits. In addition,  an S/PDIF input port
> > > >>>> + takes in compressed audio of up to 192KHz
> > > frame rate.
> > > >>>> +
> > > >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> > > >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> > > >>>> + the four I2S input ports or the  S/PDIF input port.  With
> > > >>>> + both interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> > > >>>> +
> > > >>>> +properties:
> > > >>>
> > > >>> No LVDS data-mapping support?
> > > >>
> > > >> It is enough to document number of LVDS link data lanes because
> > > >> OS should be able to determine the data-mapping by looking at the
> > > >> number and the data-mapping capability of the other side of the LVDS link.
> > > >
> > > > From what I can see, data-mapping is specified on the consumer
> > > > sink side of the LVDS link. This means it should go to the bridge's device node.
> > >
> > > Then, I won't define data-lanes, because data-mapping implies it,
> > > e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> > >
> > > Please let me know which one you prefer.
> >
> > Assume a top level use case where a user changes the format from JEDAI
> > to VESA using On screen display or modetest(if some one adds support
> > for lvds-mapping) then setting of the lvds data mapping should be dynamic.
> >
> > Maybe for initial version hardcode with JEDAI or VESA as default and
> > provide a way to override the host driver and bridge with requested lvds-data mapping dynamically
> later??
> 
> The ite,lvds-link-num-data-lanes property should be removed, it is not standard. I foresee two ways to
> specify the number of lanes used: either the data-lanes property or the data-mapping property. Granted
> that data-mapping replaces the data-lanes functionality for LVDS links, I think it's better to use it
> from the start.
> 
> Frankly speaking, what is the usecase for specifying the data mapping dynamically? What kind of uAPI
> do you have in mind and what is the usecase for it?

It simple just want to change from VESA to JEDAI, how do you change it with existing DRM framework?

Currently I see LVDS panel driver use drm_of_lvds_get_data_mapping(bus_node) to get this info.
IT6263 bridge device can use that API to get that info.

Some vendors use VESA as default LVDS data mapping whereas some others use JEDAI.

Cheers,
Biju
Biju Das Oct. 14, 2024, 8:30 a.m. UTC | #11
Hi Liu,

> -----Original Message-----
> From: Liu Ying <victor.liu@nxp.com>
> Sent: Monday, October 14, 2024 6:34 AM
> Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> 
> On 10/14/2024, Dmitry Baryshkov wrote:
> > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> >> On 10/12/2024, Dmitry Baryshkov wrote:
> >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> >>>> Document ITE IT6263 LVDS to HDMI converter.
> >>>>
> >>>> Product link:
> >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> >>>>
> >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>> ---
> >>>> v2:
> >>>> * Document number of LVDS link data lanes.  (Biju)
> >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> >>>>
> >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> >>>>  1 file changed, 276 insertions(+)
> >>>>  create mode 100644
> >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>>
> >>>> diff --git
> >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>> new file mode 100644
> >>>> index 000000000000..bc2bbec07623
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y
> >>>> +++ aml
> >>>> @@ -0,0 +1,276 @@
> >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML
> >>>> +1.2
> >>>> +---
> >>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>> +
> >>>> +title: ITE IT6263 LVDS to HDMI converter
> >>>> +
> >>>> +maintainers:
> >>>> +  - Liu Ying <victor.liu@nxp.com>
> >>>> +
> >>>> +description: |
> >>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread
> >>>> +Spectrum) LVDS
> >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a
> >>>> +transmitter,
> >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> >>>> +  The built-in LVDS receiver can support single-link and dual-link
> >>>> +LVDS inputs,
> >>>> +  and the built-in HDMI transmitter is fully compliant with HDMI
> >>>> +1.4a/3D, HDCP
> >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> >>>> +
> >>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S
> >>>> + digital audio,  with sampling rate up to 192KHz and sample size
> >>>> + up to 24 bits. In addition,  an S/PDIF input port takes in compressed audio of up to 192KHz
> frame rate.
> >>>> +
> >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> >>>> + the four I2S input ports or the  S/PDIF input port.  With both
> >>>> + interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> >>>> +
> >>>> +properties:
> >>>
> >>> No LVDS data-mapping support?
> >>
> >> It is enough to document number of LVDS link data lanes because OS
> >> should be able to determine the data-mapping by looking at the number
> >> and the data-mapping capability of the other side of the LVDS link.
> >
> > From what I can see, data-mapping is specified on the consumer sink
> > side of the LVDS link. This means it should go to the bridge's device node.
> 
> Then, I won't define data-lanes, because data-mapping implies it, e.g., jeida-24 implies data lanes
> 0/1/2/3, see lvds-data-mapping.yaml.
> 
> Please let me know which one you prefer.

For consistency, maybe use data-mapping. See [1]

[1]
https://elixir.bootlin.com/linux/v6.0-rc4/source/Documentation/devicetree/bindings/display/panel/advantech,idk-2121wr.yaml#L26

Cheers,
Biju

> 
> >
> >>
> >>>
> >>>> +  compatible:
> >>>> +    const: ite,it6263
> >>>> +
> >>>> +  reg:
> >>>> +    maxItems: 1
> >>>> +
> >>>> +  clocks:
> >>>> +    maxItems: 1
> >>>> +    description: audio master clock
> >>>> +
> >>>> +  clock-names:
> >>>> +    const: mclk
> >>>> +
> >>>> +  reset-gpios:
> >>>> +    maxItems: 1
> >>>> +
> >>>> +  ivdd-supply:
> >>>> +    description: 1.8V digital logic power
> >>>> +
> >>>> +  ovdd-supply:
> >>>> +    description: 3.3V I/O pin power
> >>>> +
> >>>> +  txavcc18-supply:
> >>>> +    description: 1.8V HDMI analog frontend power
> >>>> +
> >>>> +  txavcc33-supply:
> >>>> +    description: 3.3V HDMI analog frontend power
> >>>> +
> >>>> +  pvcc1-supply:
> >>>> +    description: 1.8V HDMI frontend core PLL power
> >>>> +
> >>>> +  pvcc2-supply:
> >>>> +    description: 1.8V HDMI frontend filter PLL power
> >>>> +
> >>>> +  avcc-supply:
> >>>> +    description: 3.3V LVDS frontend power
> >>>> +
> >>>> +  anvdd-supply:
> >>>> +    description: 1.8V LVDS frontend analog power
> >>>> +
> >>>> +  apvdd-supply:
> >>>> +    description: 1.8V LVDS frontend PLL power
> >>>> +
> >>>> +  "#sound-dai-cells":
> >>>> +    const: 0
> >>>> +
> >>>> +  ite,lvds-link-num-data-lanes:
> >>>> +    $ref: /schemas/types.yaml#/definitions/uint8
> >>>> +    enum: [3, 4, 5]
> >>>> +    description: number of data lanes per LVDS link
> >>>
> >>> Please use data-lanes property inside the OF graph.
> >>
> >> In both port@0 and port@1?
> >
> > Yes
> 
> I'm assuming if data-mapping is defined, then no need to define data-lanes.
> 
> >
> >>
> >>>
> >>>> +
> >>>> +  ite,i2s-audio-fifo-sources:
> >>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>> +    minItems: 1
> >>>> +    maxItems: 4
> >>>> +    items:
> >>>> +      enum: [0, 1, 2, 3]
> >>>> +    description:
> >>>> +      Each array element indicates the pin number of an I2S serial data input
> >>>> +      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
> >>>
> >>> What does that mean from the board point of view? Routed audio links
> >>> for the multichannel audio?
> >>
> >> Yes, also for single channel audio.
> >>
> >>>
> >>>> +
> >>>> +  ite,rl-channel-swap-audio-sources:
> >>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>> +    minItems: 1
> >>>> +    maxItems: 4
> >>>> +    uniqueItems: true
> >>>> +    items:
> >>>> +      enum: [0, 1, 2, 3]
> >>>> +    description:
> >>>> +      Each array element indicates an audio source whose right channel and left
> >>>> +      channel are swapped by this converter. For I2S, the element is the pin
> >>>> +      number of an I2S serial data input line. For S/PDIF, the element is always
> >>>> +      0.
> >>>
> >>> Why?
> >>
> >> Because this converter has the capability to swap right channel and
> >> left channel and S/PDIF always uses audio source0.
> >>
> >>>
> >>>> +
> >>>> +  ports:
> >>>> +    $ref: /schemas/graph.yaml#/properties/ports
> >>>> +
> >>>> +    properties:
> >>>> +      port@0:
> >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>> +        unevaluatedProperties: false
> >>>> +        description:
> >>>> +          The first LVDS input link.
> >>>> +          In dual-link LVDS mode, this link works together with the second LVDS
> >>>> +          input link, and one link receives odd pixels while the other receives
> >>>> +          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
> >>>> +          and dual-lvds-even-pixels properties when and only when dual-link LVDS
> >>>> +          mode is used.
> >>>> +
> >>>> +        properties:
> >>>> +          dual-lvds-odd-pixels:
> >>>> +            type: boolean
> >>>> +            description: the first sink port for odd pixels
> >>>> +
> >>>> +          dual-lvds-even-pixels:
> >>>> +            type: boolean
> >>>> +            description: the first sink port for even pixels
> >>>> +
> >>>> +      port@1:
> >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base
> >>>> +        unevaluatedProperties: false
> >>>> +        description: the second LVDS input link
> >>>> +
> >>>> +        properties:
> >>>> +          dual-lvds-even-pixels:
> >>>> +            type: boolean
> >>>> +            description: the second sink port for even pixels
> >>>> +
> >>>> +          dual-lvds-odd-pixels:
> >>>> +            type: boolean
> >>>> +            description: the second sink port for odd pixels
> >>>> +
> >>>> +        oneOf:
> >>>> +          - required: [dual-lvds-even-pixels]
> >>>> +          - required: [dual-lvds-odd-pixels]
> >>>
> >>> This still allows one to specify that both ports provide odd pixels.
> >>> Is that expected? Also why do you need two properties which specify
> >>> the same option.
> >>
> >> No, that is not expected. Description for port@0 already mentions one
> >> link receives odd pixels while the other receives even pixels.
> >
> > That's not expected, but permitted by the bindings.
> 
> It is not permitted by port@1. If "dual-lvds-odd-pixels;" is added to port@1 in the dual-link LVDS
> example, the below warning will be generated by dt_binding_check.
> 
> Documentation/devicetree/bindings/display/bridge/ite,it6263.example.dtb: hdmi@4c: ports:port@1:
> {'reg': [[1]], 'dual-lvds-even-pixels': True, 'dual-lvds-odd-pixels': True, 'endpoint': {'remote-
> endpoint': [[4294967295]]}} is valid under each of {'required': ['dual-lvds-odd-pixels']},
> {'required': ['dual-lvds-even-pixels']}
> 	from schema $id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> 
> However, the binding for port@0 does allow DT writers to specify both even and odd pixels. I raised
> similar concerns in v1 discussion.
> According to Rob's comment in #devicetree IRC, the ports property is simplified to this form and more
> description for port@0 is added to tell when to specify the even/odd pixels.  If you know any better
> way to indicate the constraints, please shout.
> 
> >
> >>
> >> Two options are supported for dual-link LVDS, not the same option:
> >> 1) LVDS link1(port@0) gets odd pixels
> >>    and
> >>    LVDS link2(port@1) gets even pixels.
> >>
> >> 2) LVDS link1(port@0) gets even pixels
> >>    and
> >>    LVDS link2(port@1) gets odd pixels.
> >> That's the reason why each port needs two properties to define
> >> odd/even pixels.
> >>
> >>>
> >>> My suggestion would be to add a single root-level property which
> >>> specifies which port provides even pixel data.
> >>
> >> That won't work.  The LVDS source side expects the ports of the sink
> >> side specify dual-lvds-{odd,even}-pixels properties.
> >
> > I didn't notice that these properties are already defined.
> >
> > As these properties are common between several schema files, please
> > extract them to a common schema file (like lvds.yaml).
> 
> I'm not sure how to do that. Is it obvious?
> Please shed some light.
> 
> Only two panel schema files are defining even/odd pixels now - advantech,idk-2121wr.yaml and panel-
> simple-lvds-dual-ports.yaml.
> Maybe, extract them later when more schema files(especially for
> bridges) try to define the same?  I'd like to keep a low profile for now.
> 
> >
> >>
> >>>
> >>>> +
> >>>> +      port@2:
> >>>> +        $ref: /schemas/graph.yaml#/properties/port
> >>>> +        description: video port for the HDMI output
> >>>> +
> >>>> +      port@3:
> >>>> +        $ref: /schemas/graph.yaml#/properties/port
> >>>> +        description: sound input port
> >>>> +
> >>>> +    required:
> >>>> +      - port@0
> >>>> +      - port@2
> >>>> +
> >>>> +required:
> >>>> +  - compatible
> >>>> +  - reg
> >>>> +  - ivdd-supply
> >>>> +  - ovdd-supply
> >>>> +  - txavcc18-supply
> >>>> +  - txavcc33-supply
> >>>> +  - pvcc1-supply
> >>>> +  - pvcc2-supply
> >>>> +  - avcc-supply
> >>>> +  - anvdd-supply
> >>>> +  - apvdd-supply
> >>>> +  - ite,lvds-link-num-data-lanes
> >>>> +  - ports
> >>>> +
> >>>> +additionalProperties: false
> >>>> +
> >>>> +examples:
> >>>> +  - |
> >>>> +    /* single-link LVDS input */
> >>>> +    #include <dt-bindings/gpio/gpio.h>
> >>>> +
> >>>> +    i2c {
> >>>> +        #address-cells = <1>;
> >>>> +        #size-cells = <0>;
> >>>> +
> >>>> +        hdmi@4c {
> >>>> +            compatible = "ite,it6263";
> >>>> +            reg = <0x4c>;
> >>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> >>>> +            ivdd-supply = <&reg_buck5>;
> >>>> +            ovdd-supply = <&reg_vext_3v3>;
> >>>> +            txavcc18-supply = <&reg_buck5>;
> >>>> +            txavcc33-supply = <&reg_vext_3v3>;
> >>>> +            pvcc1-supply = <&reg_buck5>;
> >>>> +            pvcc2-supply = <&reg_buck5>;
> >>>> +            avcc-supply = <&reg_vext_3v3>;
> >>>> +            anvdd-supply = <&reg_buck5>;
> >>>> +            apvdd-supply = <&reg_buck5>;
> >>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> >>>> +
> >>>> +            ports {
> >>>> +                #address-cells = <1>;
> >>>> +                #size-cells = <0>;
> >>>> +
> >>>> +                port@0 {
> >>>> +                    reg = <0>;
> >>>> +
> >>>> +                    it6263_lvds_link1: endpoint {
> >>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
> >>>> +                    };
> >>>> +                };
> >>>> +
> >>>> +                port@2 {
> >>>> +                    reg = <2>;
> >>>> +
> >>>> +                    it6263_out: endpoint {
> >>>> +                        remote-endpoint = <&hdmi_in>;
> >>>> +                    };
> >>>> +                };
> >>>> +            };
> >>>> +        };
> >>>> +    };
> >>>> +
> >>>> +  - |
> >>>> +    /* dual-link LVDS input */
> >>>> +    #include <dt-bindings/gpio/gpio.h>
> >>>> +
> >>>> +    i2c {
> >>>> +        #address-cells = <1>;
> >>>> +        #size-cells = <0>;
> >>>> +
> >>>> +        hdmi@4c {
> >>>> +            compatible = "ite,it6263";
> >>>> +            reg = <0x4c>;
> >>>> +            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> >>>> +            ivdd-supply = <&reg_buck5>;
> >>>> +            ovdd-supply = <&reg_vext_3v3>;
> >>>> +            txavcc18-supply = <&reg_buck5>;
> >>>> +            txavcc33-supply = <&reg_vext_3v3>;
> >>>> +            pvcc1-supply = <&reg_buck5>;
> >>>> +            pvcc2-supply = <&reg_buck5>;
> >>>> +            avcc-supply = <&reg_vext_3v3>;
> >>>> +            anvdd-supply = <&reg_buck5>;
> >>>> +            apvdd-supply = <&reg_buck5>;
> >>>> +            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
> >>>> +
> >>>> +            ports {
> >>>> +                #address-cells = <1>;
> >>>> +                #size-cells = <0>;
> >>>> +
> >>>> +                port@0 {
> >>>> +                    reg = <0>;
> >>>> +                    dual-lvds-odd-pixels;
> >>>> +
> >>>> +                    it6263_lvds_link1_dual: endpoint {
> >>>> +                        remote-endpoint = <&ldb_lvds_ch0>;
> >>>> +                    };
> >>>> +                };
> >>>> +
> >>>> +                port@1 {
> >>>> +                    reg = <1>;
> >>>> +                    dual-lvds-even-pixels;
> >>>> +
> >>>> +                    it6263_lvds_link2_dual: endpoint {
> >>>> +                        remote-endpoint = <&ldb_lvds_ch1>;
> >>>> +                    };
> >>>> +                };
> >>>> +
> >>>> +                port@2 {
> >>>> +                    reg = <2>;
> >>>> +
> >>>> +                    it6263_out_dual: endpoint {
> >>>> +                        remote-endpoint = <&hdmi_in>;
> >>>> +                    };
> >>>> +                };
> >>>> +            };
> >>>> +        };
> >>>> +    };
> >>>> --
> >>>> 2.34.1
> >>>>
> >>>
> >>
> >> --
> >> Regards,
> >> Liu Ying
> >>
> >
> 
> --
> Regards,
> Liu Ying
Liu Ying Oct. 14, 2024, 10:01 a.m. UTC | #12
On 10/14/2024, Dmitry Baryshkov wrote:

[...]

>>>>> My suggestion would be to add a single root-level property which
>>>>> specifies which port provides even pixel data.
>>>>
>>>> That won't work.  The LVDS source side expects the ports of
>>>> the sink side specify dual-lvds-{odd,even}-pixels properties.
>>>
>>> I didn't notice that these properties are already defined.
>>>
>>> As these properties are common between several schema files, please
>>> extract them to a common schema file (like lvds.yaml).
>>
>> I'm not sure how to do that. Is it obvious?
>> Please shed some light. 
>>
>> Only two panel schema files are defining even/odd pixels now -
>> advantech,idk-2121wr.yaml and panel-simple-lvds-dual-ports.yaml.
>> Maybe, extract them later when more schema files(especially for
>> bridges) try to define the same?  I'd like to keep a low profile
>> for now.
> 
> I'd say, please extract those now. Adding third is more than enough and
> should be avoided. Extracting is pretty simple. One patch to move the
> definition and descriptions from panel-simple-lvds-dual-ports to a
> common location (e.g. lvds-dual-ports.yaml). Leave the required
> constrains in place. Second patch is to add oneOf constraints to the
> ports. 

oneOf just sits below ports so that single-port and dual-port
are documented separately?  That won't pass dt_binding_check
as the v1 binding has proved that warnings will be generated.

> port@0 might get the same oneOf + the
> dual-lvds-{odd,even}-pixels:false case, allowing a single-port
> definition.

I don't catch this.
Below snippet is a draft lvds-dual-port.yaml.
How can it be referenced in ite,it6263.yaml?

---8<---
allOf:                                                                           
  - $ref: lvds.yaml#                                                             
                                                                                 
properties:                                                                      
  ports:                                                                         
    $ref: /schemas/graph.yaml#/properties/ports                                  
                                                                                 
    properties:                                                                  
      port@0:                                                                    
        $ref: /schemas/graph.yaml#/$defs/port-base                               
        unevaluatedProperties: false                                             
        description: the first LVDS input link                                   
                                                                                 
        properties:                                                              
          dual-lvds-odd-pixels:                                                  
            type: boolean                                                        
            description: the first sink port for odd pixels                      
                                                                                 
          dual-lvds-even-pixels:                                                           
            type: boolean                                                        
            description: the first sink port for even pixels                     
                                                                                 
        oneOf:                                                                   
          - required: [dual-lvds-even-pixels]                                    
          - required: [dual-lvds-odd-pixels]                                     
                                                                                 
      port@1:                                                                    
        $ref: /schemas/graph.yaml#/$defs/port-base                               
        unevaluatedProperties: false                                             
        description: the second LVDS input link                                  
                                                                                 
        properties:                                                              
          dual-lvds-even-pixels:                                                 
            type: boolean                                                        
            description: the second sink port for even pixels                    
                                                                                 
          dual-lvds-odd-pixels:                                                  
            type: boolean                                                        
            description: the second sink port for odd pixels                     
                                                                                 
        oneOf:                                                                   
          - required: [dual-lvds-even-pixels]                                    
          - required: [dual-lvds-odd-pixels]                                     
                                                                                 
    required:                                                                    
      - port@0                                                                   
      - port@1                                                                   
                                                                                 
unevaluatedProperties: false   
---8<---
Dmitry Baryshkov Oct. 14, 2024, 11:15 a.m. UTC | #13
On Mon, Oct 14, 2024 at 06:01:49PM +0800, Liu Ying wrote:
> On 10/14/2024, Dmitry Baryshkov wrote:
> 
> [...]
> 
> >>>>> My suggestion would be to add a single root-level property which
> >>>>> specifies which port provides even pixel data.
> >>>>
> >>>> That won't work.  The LVDS source side expects the ports of
> >>>> the sink side specify dual-lvds-{odd,even}-pixels properties.
> >>>
> >>> I didn't notice that these properties are already defined.
> >>>
> >>> As these properties are common between several schema files, please
> >>> extract them to a common schema file (like lvds.yaml).
> >>
> >> I'm not sure how to do that. Is it obvious?
> >> Please shed some light. 
> >>
> >> Only two panel schema files are defining even/odd pixels now -
> >> advantech,idk-2121wr.yaml and panel-simple-lvds-dual-ports.yaml.
> >> Maybe, extract them later when more schema files(especially for
> >> bridges) try to define the same?  I'd like to keep a low profile
> >> for now.
> > 
> > I'd say, please extract those now. Adding third is more than enough and
> > should be avoided. Extracting is pretty simple. One patch to move the
> > definition and descriptions from panel-simple-lvds-dual-ports to a
> > common location (e.g. lvds-dual-ports.yaml). Leave the required
> > constrains in place. Second patch is to add oneOf constraints to the
> > ports. 
> 
> oneOf just sits below ports so that single-port and dual-port
> are documented separately?  That won't pass dt_binding_check
> as the v1 binding has proved that warnings will be generated.
> 
> > port@0 might get the same oneOf + the
> > dual-lvds-{odd,even}-pixels:false case, allowing a single-port
> > definition.
> 
> I don't catch this.
> Below snippet is a draft lvds-dual-port.yaml.
> How can it be referenced in ite,it6263.yaml?

allOf:
 - $ref: /schemas/display/lvds-dual-port.yaml

Another option might be to use $defs, define two combinations:
single-or-dual-port, dual-only-port. Reference them from the panel
bindings and from your bridge bindings by using:

 ports:
    port@0:
      $ref: /schemas/display/lvds.yaml#/#defs/single-or-dual-port

    port@1:
      $ref: /schemas/display/lvds.yaml#/#defs/dual-only-port

(the names are just an example, feel free to come with better
suggestions).

> 
> ---8<---
> allOf:                                                                           
>   - $ref: lvds.yaml#                                                             
>                                                                                  
> properties:                                                                      
>   ports:                                                                         
>     $ref: /schemas/graph.yaml#/properties/ports                                  
>                                                                                  
>     properties:                                                                  
>       port@0:                                                                    
>         $ref: /schemas/graph.yaml#/$defs/port-base                               
>         unevaluatedProperties: false                                             
>         description: the first LVDS input link                                   
>                                                                                  
>         properties:                                                              
>           dual-lvds-odd-pixels:                                                  
>             type: boolean                                                        
>             description: the first sink port for odd pixels                      
>                                                                                  
>           dual-lvds-even-pixels:                                                           
>             type: boolean                                                        
>             description: the first sink port for even pixels                     
>                                                                                  
>         oneOf:                                                                   
>           - required: [dual-lvds-even-pixels]                                    
>           - required: [dual-lvds-odd-pixels]                                     

Also under oneOf:
 - properties:
     dual-lvds-odd-pixels: false
     dual-lvds-even-pixels: false

>                                                                                  
>       port@1:                                                                    
>         $ref: /schemas/graph.yaml#/$defs/port-base                               
>         unevaluatedProperties: false                                             
>         description: the second LVDS input link                                  
>                                                                                  
>         properties:                                                              
>           dual-lvds-even-pixels:                                                 
>             type: boolean                                                        
>             description: the second sink port for even pixels                    
>                                                                                  
>           dual-lvds-odd-pixels:                                                  
>             type: boolean                                                        
>             description: the second sink port for odd pixels                     
>                                                                                  
>         oneOf:                                                                   
>           - required: [dual-lvds-even-pixels]                                    
>           - required: [dual-lvds-odd-pixels]                                     
>                                                                                  
>     required:                                                                    
>       - port@0                                                                   
>       - port@1                                                                   

You allow both single-port and dual-port configurations, so you can not
use this required statement. Please keep this part in the corresponding
panel bindings.

>                                                                                  
> unevaluatedProperties: false   
> ---8<---
> 
> -- 
> Regards,
> Liu Ying
>
Dmitry Baryshkov Oct. 14, 2024, 11:16 a.m. UTC | #14
On Mon, Oct 14, 2024 at 08:09:44AM +0000, Biju Das wrote:
> Hi Dmitry,
> 
> > -----Original Message-----
> > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Sent: Monday, October 14, 2024 9:04 AM
> > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> > 
> > On Mon, Oct 14, 2024 at 07:39:16AM +0000, Biju Das wrote:
> > > Hi Liu and Dmitry,
> > >
> > > > -----Original Message-----
> > > > From: Liu Ying <victor.liu@nxp.com>
> > > > Sent: Monday, October 14, 2024 6:34 AM
> > > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE
> > > > IT6263 LVDS to HDMI converter
> > > >
> > > > On 10/14/2024, Dmitry Baryshkov wrote:
> > > > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> > > > >> On 10/12/2024, Dmitry Baryshkov wrote:
> > > > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> > > > >>>> Document ITE IT6263 LVDS to HDMI converter.
> > > > >>>>
> > > > >>>> Product link:
> > > > >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> > > > >>>>
> > > > >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > > > >>>> ---
> > > > >>>> v2:
> > > > >>>> * Document number of LVDS link data lanes.  (Biju)
> > > > >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> > > > >>>>
> > > > >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> > > > >>>>  1 file changed, 276 insertions(+)  create mode 100644
> > > > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263.yam
> > > > >>>> l
> > > > >>>>
> > > > >>>> diff --git
> > > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.y
> > > > >>>> aml
> > > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y
> > > > >>>> aml
> > > > >>>> new file mode 100644
> > > > >>>> index 000000000000..bc2bbec07623
> > > > >>>> --- /dev/null
> > > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it62
> > > > >>>> +++ 63.y
> > > > >>>> +++ aml
> > > > >>>> @@ -0,0 +1,276 @@
> > > > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > >>>> +%YAML
> > > > >>>> +1.2
> > > > >>>> +---
> > > > >>>> +$id:
> > > > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> > > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > >>>> +
> > > > >>>> +title: ITE IT6263 LVDS to HDMI converter
> > > > >>>> +
> > > > >>>> +maintainers:
> > > > >>>> +  - Liu Ying <victor.liu@nxp.com>
> > > > >>>> +
> > > > >>>> +description: |
> > > > >>>> +  The IT6263 is a high-performance single-chip
> > > > >>>> +De-SSC(De-Spread
> > > > >>>> +Spectrum) LVDS
> > > > >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI
> > > > >>>> +1.4a transmitter,
> > > > >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> > > > >>>> +  The built-in LVDS receiver can support single-link and
> > > > >>>> +dual-link LVDS inputs,
> > > > >>>> +  and the built-in HDMI transmitter is fully compliant with
> > > > >>>> +HDMI 1.4a/3D, HDCP
> > > > >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> > > > >>>> +
> > > > >>>> +  The IT6263 also encodes and transmits up to 8 channels of
> > > > >>>> + I2S digital audio,  with sampling rate up to 192KHz and
> > > > >>>> + sample size up to 24 bits. In addition,  an S/PDIF input port
> > > > >>>> + takes in compressed audio of up to 192KHz
> > > > frame rate.
> > > > >>>> +
> > > > >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> > > > >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> > > > >>>> + the four I2S input ports or the  S/PDIF input port.  With
> > > > >>>> + both interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> > > > >>>> +
> > > > >>>> +properties:
> > > > >>>
> > > > >>> No LVDS data-mapping support?
> > > > >>
> > > > >> It is enough to document number of LVDS link data lanes because
> > > > >> OS should be able to determine the data-mapping by looking at the
> > > > >> number and the data-mapping capability of the other side of the LVDS link.
> > > > >
> > > > > From what I can see, data-mapping is specified on the consumer
> > > > > sink side of the LVDS link. This means it should go to the bridge's device node.
> > > >
> > > > Then, I won't define data-lanes, because data-mapping implies it,
> > > > e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> > > >
> > > > Please let me know which one you prefer.
> > >
> > > Assume a top level use case where a user changes the format from JEDAI
> > > to VESA using On screen display or modetest(if some one adds support
> > > for lvds-mapping) then setting of the lvds data mapping should be dynamic.
> > >
> > > Maybe for initial version hardcode with JEDAI or VESA as default and
> > > provide a way to override the host driver and bridge with requested lvds-data mapping dynamically
> > later??
> > 
> > The ite,lvds-link-num-data-lanes property should be removed, it is not standard. I foresee two ways to
> > specify the number of lanes used: either the data-lanes property or the data-mapping property. Granted
> > that data-mapping replaces the data-lanes functionality for LVDS links, I think it's better to use it
> > from the start.
> > 
> > Frankly speaking, what is the usecase for specifying the data mapping dynamically? What kind of uAPI
> > do you have in mind and what is the usecase for it?
> 
> It simple just want to change from VESA to JEDAI, how do you change it with existing DRM framework?

Why do you want to change it on the fly?

> Currently I see LVDS panel driver use drm_of_lvds_get_data_mapping(bus_node) to get this info.
> IT6263 bridge device can use that API to get that info.
> 
> Some vendors use VESA as default LVDS data mapping whereas some others use JEDAI.

I think this is logical. Bus format is set by the system design
constraints. In theory one can use buf format negotiation for the same
purpose.

> 
> Cheers,
> Biju
Biju Das Oct. 14, 2024, 11:25 a.m. UTC | #15
Hi Dmitry,

> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> Sent: Monday, October 14, 2024 12:16 PM
> Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> 
> On Mon, Oct 14, 2024 at 08:09:44AM +0000, Biju Das wrote:
> > Hi Dmitry,
> >
> > > -----Original Message-----
> > > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > Sent: Monday, October 14, 2024 9:04 AM
> > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE
> > > IT6263 LVDS to HDMI converter
> > >
> > > On Mon, Oct 14, 2024 at 07:39:16AM +0000, Biju Das wrote:
> > > > Hi Liu and Dmitry,
> > > >
> > > > > -----Original Message-----
> > > > > From: Liu Ying <victor.liu@nxp.com>
> > > > > Sent: Monday, October 14, 2024 6:34 AM
> > > > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add
> > > > > ITE
> > > > > IT6263 LVDS to HDMI converter
> > > > >
> > > > > On 10/14/2024, Dmitry Baryshkov wrote:
> > > > > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> > > > > >> On 10/12/2024, Dmitry Baryshkov wrote:
> > > > > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> > > > > >>>> Document ITE IT6263 LVDS to HDMI converter.
> > > > > >>>>
> > > > > >>>> Product link:
> > > > > >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> > > > > >>>>
> > > > > >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > > > > >>>> ---
> > > > > >>>> v2:
> > > > > >>>> * Document number of LVDS link data lanes.  (Biju)
> > > > > >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> > > > > >>>>
> > > > > >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> > > > > >>>>  1 file changed, 276 insertions(+)  create mode 100644
> > > > > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263
> > > > > >>>> .yam
> > > > > >>>> l
> > > > > >>>>
> > > > > >>>> diff --git
> > > > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it62
> > > > > >>>> 63.y
> > > > > >>>> aml
> > > > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it62
> > > > > >>>> 63.y
> > > > > >>>> aml
> > > > > >>>> new file mode 100644
> > > > > >>>> index 000000000000..bc2bbec07623
> > > > > >>>> --- /dev/null
> > > > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,
> > > > > >>>> +++ it62
> > > > > >>>> +++ 63.y
> > > > > >>>> +++ aml
> > > > > >>>> @@ -0,0 +1,276 @@
> > > > > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > >>>> +%YAML
> > > > > >>>> +1.2
> > > > > >>>> +---
> > > > > >>>> +$id:
> > > > > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.ya
> > > > > >>>> +ml#
> > > > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > >>>> +
> > > > > >>>> +title: ITE IT6263 LVDS to HDMI converter
> > > > > >>>> +
> > > > > >>>> +maintainers:
> > > > > >>>> +  - Liu Ying <victor.liu@nxp.com>
> > > > > >>>> +
> > > > > >>>> +description: |
> > > > > >>>> +  The IT6263 is a high-performance single-chip
> > > > > >>>> +De-SSC(De-Spread
> > > > > >>>> +Spectrum) LVDS
> > > > > >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI
> > > > > >>>> +1.4a transmitter,
> > > > > >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> > > > > >>>> +  The built-in LVDS receiver can support single-link and
> > > > > >>>> +dual-link LVDS inputs,
> > > > > >>>> +  and the built-in HDMI transmitter is fully compliant
> > > > > >>>> +with HDMI 1.4a/3D, HDCP
> > > > > >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> > > > > >>>> +
> > > > > >>>> +  The IT6263 also encodes and transmits up to 8 channels
> > > > > >>>> + of I2S digital audio,  with sampling rate up to 192KHz
> > > > > >>>> + and sample size up to 24 bits. In addition,  an S/PDIF
> > > > > >>>> + input port takes in compressed audio of up to 192KHz
> > > > > frame rate.
> > > > > >>>> +
> > > > > >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> > > > > >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> > > > > >>>> + the four I2S input ports or the  S/PDIF input port.  With
> > > > > >>>> + both interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> > > > > >>>> +
> > > > > >>>> +properties:
> > > > > >>>
> > > > > >>> No LVDS data-mapping support?
> > > > > >>
> > > > > >> It is enough to document number of LVDS link data lanes
> > > > > >> because OS should be able to determine the data-mapping by
> > > > > >> looking at the number and the data-mapping capability of the other side of the LVDS link.
> > > > > >
> > > > > > From what I can see, data-mapping is specified on the consumer
> > > > > > sink side of the LVDS link. This means it should go to the bridge's device node.
> > > > >
> > > > > Then, I won't define data-lanes, because data-mapping implies
> > > > > it, e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> > > > >
> > > > > Please let me know which one you prefer.
> > > >
> > > > Assume a top level use case where a user changes the format from
> > > > JEDAI to VESA using On screen display or modetest(if some one adds
> > > > support for lvds-mapping) then setting of the lvds data mapping should be dynamic.
> > > >
> > > > Maybe for initial version hardcode with JEDAI or VESA as default
> > > > and provide a way to override the host driver and bridge with
> > > > requested lvds-data mapping dynamically
> > > later??
> > >
> > > The ite,lvds-link-num-data-lanes property should be removed, it is
> > > not standard. I foresee two ways to specify the number of lanes
> > > used: either the data-lanes property or the data-mapping property.
> > > Granted that data-mapping replaces the data-lanes functionality for LVDS links, I think it's
> better to use it from the start.
> > >
> > > Frankly speaking, what is the usecase for specifying the data
> > > mapping dynamically? What kind of uAPI do you have in mind and what is the usecase for it?
> >
> > It simple just want to change from VESA to JEDAI, how do you change it with existing DRM framework?
> 
> Why do you want to change it on the fly?

It will reduce validation effort for LVDS and bridge driver for testing various bus formats.

By allowing on the fly, with single dtb, we can validate various bus formats.
Otherwise each dtb for testing each bus format.

From a product perspective, this use case is not valid.

Cheers,
Biju
Dmitry Baryshkov Oct. 14, 2024, 11:36 a.m. UTC | #16
On Mon, Oct 14, 2024 at 11:25:00AM +0000, Biju Das wrote:
> Hi Dmitry,
> 
> > -----Original Message-----
> > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > Sent: Monday, October 14, 2024 12:16 PM
> > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
> > 
> > On Mon, Oct 14, 2024 at 08:09:44AM +0000, Biju Das wrote:
> > > Hi Dmitry,
> > >
> > > > -----Original Message-----
> > > > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > > > Sent: Monday, October 14, 2024 9:04 AM
> > > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE
> > > > IT6263 LVDS to HDMI converter
> > > >
> > > > On Mon, Oct 14, 2024 at 07:39:16AM +0000, Biju Das wrote:
> > > > > Hi Liu and Dmitry,
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Liu Ying <victor.liu@nxp.com>
> > > > > > Sent: Monday, October 14, 2024 6:34 AM
> > > > > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add
> > > > > > ITE
> > > > > > IT6263 LVDS to HDMI converter
> > > > > >
> > > > > > On 10/14/2024, Dmitry Baryshkov wrote:
> > > > > > > On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> > > > > > >> On 10/12/2024, Dmitry Baryshkov wrote:
> > > > > > >>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> > > > > > >>>> Document ITE IT6263 LVDS to HDMI converter.
> > > > > > >>>>
> > > > > > >>>> Product link:
> > > > > > >>>> https://www.ite.com.tw/en/product/cate1/IT6263
> > > > > > >>>>
> > > > > > >>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> > > > > > >>>> ---
> > > > > > >>>> v2:
> > > > > > >>>> * Document number of LVDS link data lanes.  (Biju)
> > > > > > >>>> * Simplify ports property by dropping "oneOf".  (Rob)
> > > > > > >>>>
> > > > > > >>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> > > > > > >>>>  1 file changed, 276 insertions(+)  create mode 100644
> > > > > > >>>> Documentation/devicetree/bindings/display/bridge/ite,it6263
> > > > > > >>>> .yam
> > > > > > >>>> l
> > > > > > >>>>
> > > > > > >>>> diff --git
> > > > > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it62
> > > > > > >>>> 63.y
> > > > > > >>>> aml
> > > > > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it62
> > > > > > >>>> 63.y
> > > > > > >>>> aml
> > > > > > >>>> new file mode 100644
> > > > > > >>>> index 000000000000..bc2bbec07623
> > > > > > >>>> --- /dev/null
> > > > > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,
> > > > > > >>>> +++ it62
> > > > > > >>>> +++ 63.y
> > > > > > >>>> +++ aml
> > > > > > >>>> @@ -0,0 +1,276 @@
> > > > > > >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > > > >>>> +%YAML
> > > > > > >>>> +1.2
> > > > > > >>>> +---
> > > > > > >>>> +$id:
> > > > > > >>>> +http://devicetree.org/schemas/display/bridge/ite,it6263.ya
> > > > > > >>>> +ml#
> > > > > > >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > > > >>>> +
> > > > > > >>>> +title: ITE IT6263 LVDS to HDMI converter
> > > > > > >>>> +
> > > > > > >>>> +maintainers:
> > > > > > >>>> +  - Liu Ying <victor.liu@nxp.com>
> > > > > > >>>> +
> > > > > > >>>> +description: |
> > > > > > >>>> +  The IT6263 is a high-performance single-chip
> > > > > > >>>> +De-SSC(De-Spread
> > > > > > >>>> +Spectrum) LVDS
> > > > > > >>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI
> > > > > > >>>> +1.4a transmitter,
> > > > > > >>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> > > > > > >>>> +  The built-in LVDS receiver can support single-link and
> > > > > > >>>> +dual-link LVDS inputs,
> > > > > > >>>> +  and the built-in HDMI transmitter is fully compliant
> > > > > > >>>> +with HDMI 1.4a/3D, HDCP
> > > > > > >>>> +  1.2 and backward compatible with DVI 1.0 specification.
> > > > > > >>>> +
> > > > > > >>>> +  The IT6263 also encodes and transmits up to 8 channels
> > > > > > >>>> + of I2S digital audio,  with sampling rate up to 192KHz
> > > > > > >>>> + and sample size up to 24 bits. In addition,  an S/PDIF
> > > > > > >>>> + input port takes in compressed audio of up to 192KHz
> > > > > > frame rate.
> > > > > > >>>> +
> > > > > > >>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI
> > > > > > >>>> + specifications v1.3 is  provided by the IT6263 in two interfaces:
> > > > > > >>>> + the four I2S input ports or the  S/PDIF input port.  With
> > > > > > >>>> + both interfaces the highest possible HBR frame rate  is supported at up to 768KHz.
> > > > > > >>>> +
> > > > > > >>>> +properties:
> > > > > > >>>
> > > > > > >>> No LVDS data-mapping support?
> > > > > > >>
> > > > > > >> It is enough to document number of LVDS link data lanes
> > > > > > >> because OS should be able to determine the data-mapping by
> > > > > > >> looking at the number and the data-mapping capability of the other side of the LVDS link.
> > > > > > >
> > > > > > > From what I can see, data-mapping is specified on the consumer
> > > > > > > sink side of the LVDS link. This means it should go to the bridge's device node.
> > > > > >
> > > > > > Then, I won't define data-lanes, because data-mapping implies
> > > > > > it, e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> > > > > >
> > > > > > Please let me know which one you prefer.
> > > > >
> > > > > Assume a top level use case where a user changes the format from
> > > > > JEDAI to VESA using On screen display or modetest(if some one adds
> > > > > support for lvds-mapping) then setting of the lvds data mapping should be dynamic.
> > > > >
> > > > > Maybe for initial version hardcode with JEDAI or VESA as default
> > > > > and provide a way to override the host driver and bridge with
> > > > > requested lvds-data mapping dynamically
> > > > later??
> > > >
> > > > The ite,lvds-link-num-data-lanes property should be removed, it is
> > > > not standard. I foresee two ways to specify the number of lanes
> > > > used: either the data-lanes property or the data-mapping property.
> > > > Granted that data-mapping replaces the data-lanes functionality for LVDS links, I think it's
> > better to use it from the start.
> > > >
> > > > Frankly speaking, what is the usecase for specifying the data
> > > > mapping dynamically? What kind of uAPI do you have in mind and what is the usecase for it?
> > >
> > > It simple just want to change from VESA to JEDAI, how do you change it with existing DRM framework?
> > 
> > Why do you want to change it on the fly?
> 
> It will reduce validation effort for LVDS and bridge driver for testing various bus formats.
> 
> By allowing on the fly, with single dtb, we can validate various bus formats.
> Otherwise each dtb for testing each bus format.

I see your point, but I don't think it falls into the uAPI area. Feel
free to propose a mechanism to change data-mapping through the debugfs
though. I think that's the best possible option.

> 
> From a product perspective, this use case is not valid.
> 
> Cheers,
> Biju
>
Liu Ying Oct. 15, 2024, 6:28 a.m. UTC | #17
On 10/14/2024, Dmitry Baryshkov wrote:
> On Mon, Oct 14, 2024 at 01:33:44PM +0800, Liu Ying wrote:
>> On 10/14/2024, Dmitry Baryshkov wrote:
>>> On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
>>>> On 10/12/2024, Dmitry Baryshkov wrote:
>>>>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
>>>>>> Document ITE IT6263 LVDS to HDMI converter.
>>>>>>
>>>>>> Product link:
>>>>>> https://www.ite.com.tw/en/product/cate1/IT6263
>>>>>>
>>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
>>>>>> ---
>>>>>> v2:
>>>>>> * Document number of LVDS link data lanes.  (Biju)
>>>>>> * Simplify ports property by dropping "oneOf".  (Rob)
>>>>>>
>>>>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
>>>>>>  1 file changed, 276 insertions(+)
>>>>>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..bc2bbec07623
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
>>>>>> @@ -0,0 +1,276 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +%YAML 1.2
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: ITE IT6263 LVDS to HDMI converter
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Liu Ying <victor.liu@nxp.com>
>>>>>> +
>>>>>> +description: |
>>>>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
>>>>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
>>>>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
>>>>>> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
>>>>>> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
>>>>>> +  1.2 and backward compatible with DVI 1.0 specification.
>>>>>> +
>>>>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
>>>>>> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
>>>>>> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
>>>>>> +
>>>>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
>>>>>> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
>>>>>> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
>>>>>> +  is supported at up to 768KHz.
>>>>>> +
>>>>>> +properties:
>>>>>
>>>>> No LVDS data-mapping support?
>>>>
>>>> It is enough to document number of LVDS link data lanes
>>>> because OS should be able to determine the data-mapping
>>>> by looking at the number and the data-mapping capability
>>>> of the other side of the LVDS link. 
>>>
>>> From what I can see, data-mapping is specified on the consumer sink side
>>> of the LVDS link. This means it should go to the bridge's device node.
>>
>> Then, I won't define data-lanes, because data-mapping implies it,
>> e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
>>
>> Please let me know which one you prefer.
> 
> I'd prefer data-mapping.

Before I go ahead to use it, I'd like to get confirmation that
it'll cover data mapping which supports 30-bit RGB pixel transmission,
because it is something supported by IT6263 as I mentioned in v1
dt-binding discussion.  For now, data-mapping only supports jeida-18,
jeida-24 and vesa-24, see lvds-data-mapping.yaml.  And, I'm not
sure the 30-bit data mappings specified in IT6263 datasheet are
standard or not.

Note that if we use data-lanes instead, then this is not a concern
from DT PoV, as data mapping can be inferred by OS.
Rob Herring Oct. 15, 2024, 6:58 p.m. UTC | #18
On Mon, Oct 14, 2024 at 5:01 AM Liu Ying <victor.liu@nxp.com> wrote:
>
> On 10/14/2024, Dmitry Baryshkov wrote:
>
> [...]
>
> >>>>> My suggestion would be to add a single root-level property which
> >>>>> specifies which port provides even pixel data.
> >>>>
> >>>> That won't work.  The LVDS source side expects the ports of
> >>>> the sink side specify dual-lvds-{odd,even}-pixels properties.
> >>>
> >>> I didn't notice that these properties are already defined.
> >>>
> >>> As these properties are common between several schema files, please
> >>> extract them to a common schema file (like lvds.yaml).
> >>
> >> I'm not sure how to do that. Is it obvious?
> >> Please shed some light.
> >>
> >> Only two panel schema files are defining even/odd pixels now -
> >> advantech,idk-2121wr.yaml and panel-simple-lvds-dual-ports.yaml.
> >> Maybe, extract them later when more schema files(especially for
> >> bridges) try to define the same?  I'd like to keep a low profile
> >> for now.
> >
> > I'd say, please extract those now. Adding third is more than enough and
> > should be avoided. Extracting is pretty simple. One patch to move the
> > definition and descriptions from panel-simple-lvds-dual-ports to a
> > common location (e.g. lvds-dual-ports.yaml). Leave the required
> > constrains in place. Second patch is to add oneOf constraints to the
> > ports.
>
> oneOf just sits below ports so that single-port and dual-port
> are documented separately?  That won't pass dt_binding_check
> as the v1 binding has proved that warnings will be generated.
>
> > port@0 might get the same oneOf + the
> > dual-lvds-{odd,even}-pixels:false case, allowing a single-port
> > definition.
>
> I don't catch this.
> Below snippet is a draft lvds-dual-port.yaml.

Please make panel-simple-lvds-dual-ports.yaml use this.

> How can it be referenced in ite,it6263.yaml?
>
> ---8<---
> allOf:
>   - $ref: lvds.yaml#
>
> properties:
>   ports:
>     $ref: /schemas/graph.yaml#/properties/ports
>
>     properties:
>       port@0:
>         $ref: /schemas/graph.yaml#/$defs/port-base
>         unevaluatedProperties: false
>         description: the first LVDS input link
>
>         properties:
>           dual-lvds-odd-pixels:
>             type: boolean
>             description: the first sink port for odd pixels
>
>           dual-lvds-even-pixels:
>             type: boolean
>             description: the first sink port for even pixels
>
>         oneOf:
>           - required: [dual-lvds-even-pixels]
>           - required: [dual-lvds-odd-pixels]
>
>       port@1:
>         $ref: /schemas/graph.yaml#/$defs/port-base
>         unevaluatedProperties: false
>         description: the second LVDS input link
>
>         properties:
>           dual-lvds-even-pixels:
>             type: boolean
>             description: the second sink port for even pixels
>
>           dual-lvds-odd-pixels:
>             type: boolean
>             description: the second sink port for odd pixels
>
>         oneOf:
>           - required: [dual-lvds-even-pixels]
>           - required: [dual-lvds-odd-pixels]
>
>     required:
>       - port@0
>       - port@1
>
> unevaluatedProperties: false
> ---8<---
>
> --
> Regards,
> Liu Ying
>
Dmitry Baryshkov Oct. 19, 2024, 2:44 a.m. UTC | #19
On Tue, 15 Oct 2024 at 09:27, Liu Ying <victor.liu@nxp.com> wrote:
>
> On 10/14/2024, Dmitry Baryshkov wrote:
> > On Mon, Oct 14, 2024 at 01:33:44PM +0800, Liu Ying wrote:
> >> On 10/14/2024, Dmitry Baryshkov wrote:
> >>> On Sat, Oct 12, 2024 at 05:14:13PM +0800, Liu Ying wrote:
> >>>> On 10/12/2024, Dmitry Baryshkov wrote:
> >>>>> On Sat, Oct 12, 2024 at 03:35:39PM +0800, Liu Ying wrote:
> >>>>>> Document ITE IT6263 LVDS to HDMI converter.
> >>>>>>
> >>>>>> Product link:
> >>>>>> https://www.ite.com.tw/en/product/cate1/IT6263
> >>>>>>
> >>>>>> Signed-off-by: Liu Ying <victor.liu@nxp.com>
> >>>>>> ---
> >>>>>> v2:
> >>>>>> * Document number of LVDS link data lanes.  (Biju)
> >>>>>> * Simplify ports property by dropping "oneOf".  (Rob)
> >>>>>>
> >>>>>>  .../bindings/display/bridge/ite,it6263.yaml   | 276 ++++++++++++++++++
> >>>>>>  1 file changed, 276 insertions(+)
> >>>>>>  create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>>>> new file mode 100644
> >>>>>> index 000000000000..bc2bbec07623
> >>>>>> --- /dev/null
> >>>>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
> >>>>>> @@ -0,0 +1,276 @@
> >>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>>>> +%YAML 1.2
> >>>>>> +---
> >>>>>> +$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
> >>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>>>> +
> >>>>>> +title: ITE IT6263 LVDS to HDMI converter
> >>>>>> +
> >>>>>> +maintainers:
> >>>>>> +  - Liu Ying <victor.liu@nxp.com>
> >>>>>> +
> >>>>>> +description: |
> >>>>>> +  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
> >>>>>> +  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
> >>>>>> +  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
> >>>>>> +  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
> >>>>>> +  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
> >>>>>> +  1.2 and backward compatible with DVI 1.0 specification.
> >>>>>> +
> >>>>>> +  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
> >>>>>> +  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
> >>>>>> +  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
> >>>>>> +
> >>>>>> +  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
> >>>>>> +  provided by the IT6263 in two interfaces: the four I2S input ports or the
> >>>>>> +  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
> >>>>>> +  is supported at up to 768KHz.
> >>>>>> +
> >>>>>> +properties:
> >>>>>
> >>>>> No LVDS data-mapping support?
> >>>>
> >>>> It is enough to document number of LVDS link data lanes
> >>>> because OS should be able to determine the data-mapping
> >>>> by looking at the number and the data-mapping capability
> >>>> of the other side of the LVDS link.
> >>>
> >>> From what I can see, data-mapping is specified on the consumer sink side
> >>> of the LVDS link. This means it should go to the bridge's device node.
> >>
> >> Then, I won't define data-lanes, because data-mapping implies it,
> >> e.g., jeida-24 implies data lanes 0/1/2/3, see lvds-data-mapping.yaml.
> >>
> >> Please let me know which one you prefer.
> >
> > I'd prefer data-mapping.
>
> Before I go ahead to use it, I'd like to get confirmation that
> it'll cover data mapping which supports 30-bit RGB pixel transmission,
> because it is something supported by IT6263 as I mentioned in v1
> dt-binding discussion.  For now, data-mapping only supports jeida-18,
> jeida-24 and vesa-24, see lvds-data-mapping.yaml.  And, I'm not
> sure the 30-bit data mappings specified in IT6263 datasheet are
> standard or not.

It is not. At the time the standards were written, nobody was actually
thinking about the 30bpp panels.

> Note that if we use data-lanes instead, then this is not a concern
> from DT PoV, as data mapping can be inferred by OS.

It can not. There is no way to determine if JEIDA or VESA / SPWG
format is being used if it is not declared.
Moreover, <uapi/linux/media-bus-format.h> doesn't declare 1X7X5
formats. If you are to support 30bpp LVDS, you'd need to define two
corresponding constants, then extend data-mapping definition and code
by documenting 5-lane LVDS as standards extension to support 30bpp
transfers.
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
new file mode 100644
index 000000000000..bc2bbec07623
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
@@ -0,0 +1,276 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/ite,it6263.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ITE IT6263 LVDS to HDMI converter
+
+maintainers:
+  - Liu Ying <victor.liu@nxp.com>
+
+description: |
+  The IT6263 is a high-performance single-chip De-SSC(De-Spread Spectrum) LVDS
+  to HDMI converter.  Combined with LVDS receiver and HDMI 1.4a transmitter,
+  the IT6263 supports LVDS input and HDMI 1.4 output by conversion function.
+  The built-in LVDS receiver can support single-link and dual-link LVDS inputs,
+  and the built-in HDMI transmitter is fully compliant with HDMI 1.4a/3D, HDCP
+  1.2 and backward compatible with DVI 1.0 specification.
+
+  The IT6263 also encodes and transmits up to 8 channels of I2S digital audio,
+  with sampling rate up to 192KHz and sample size up to 24 bits. In addition,
+  an S/PDIF input port takes in compressed audio of up to 192KHz frame rate.
+
+  The newly supported High-Bit Rate(HBR) audio by HDMI specifications v1.3 is
+  provided by the IT6263 in two interfaces: the four I2S input ports or the
+  S/PDIF input port.  With both interfaces the highest possible HBR frame rate
+  is supported at up to 768KHz.
+
+properties:
+  compatible:
+    const: ite,it6263
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    maxItems: 1
+    description: audio master clock
+
+  clock-names:
+    const: mclk
+
+  reset-gpios:
+    maxItems: 1
+
+  ivdd-supply:
+    description: 1.8V digital logic power
+
+  ovdd-supply:
+    description: 3.3V I/O pin power
+
+  txavcc18-supply:
+    description: 1.8V HDMI analog frontend power
+
+  txavcc33-supply:
+    description: 3.3V HDMI analog frontend power
+
+  pvcc1-supply:
+    description: 1.8V HDMI frontend core PLL power
+
+  pvcc2-supply:
+    description: 1.8V HDMI frontend filter PLL power
+
+  avcc-supply:
+    description: 3.3V LVDS frontend power
+
+  anvdd-supply:
+    description: 1.8V LVDS frontend analog power
+
+  apvdd-supply:
+    description: 1.8V LVDS frontend PLL power
+
+  "#sound-dai-cells":
+    const: 0
+
+  ite,lvds-link-num-data-lanes:
+    $ref: /schemas/types.yaml#/definitions/uint8
+    enum: [3, 4, 5]
+    description: number of data lanes per LVDS link
+
+  ite,i2s-audio-fifo-sources:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 4
+    items:
+      enum: [0, 1, 2, 3]
+    description:
+      Each array element indicates the pin number of an I2S serial data input
+      line which is connected to an audio FIFO, from audio FIFO0 to FIFO3.
+
+  ite,rl-channel-swap-audio-sources:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    minItems: 1
+    maxItems: 4
+    uniqueItems: true
+    items:
+      enum: [0, 1, 2, 3]
+    description:
+      Each array element indicates an audio source whose right channel and left
+      channel are swapped by this converter. For I2S, the element is the pin
+      number of an I2S serial data input line. For S/PDIF, the element is always
+      0.
+
+  ports:
+    $ref: /schemas/graph.yaml#/properties/ports
+
+    properties:
+      port@0:
+        $ref: /schemas/graph.yaml#/$defs/port-base
+        unevaluatedProperties: false
+        description:
+          The first LVDS input link.
+          In dual-link LVDS mode, this link works together with the second LVDS
+          input link, and one link receives odd pixels while the other receives
+          even pixels. Specify the pixels with one of the dual-lvds-odd-pixels
+          and dual-lvds-even-pixels properties when and only when dual-link LVDS
+          mode is used.
+
+        properties:
+          dual-lvds-odd-pixels:
+            type: boolean
+            description: the first sink port for odd pixels
+
+          dual-lvds-even-pixels:
+            type: boolean
+            description: the first sink port for even pixels
+
+      port@1:
+        $ref: /schemas/graph.yaml#/$defs/port-base
+        unevaluatedProperties: false
+        description: the second LVDS input link
+
+        properties:
+          dual-lvds-even-pixels:
+            type: boolean
+            description: the second sink port for even pixels
+
+          dual-lvds-odd-pixels:
+            type: boolean
+            description: the second sink port for odd pixels
+
+        oneOf:
+          - required: [dual-lvds-even-pixels]
+          - required: [dual-lvds-odd-pixels]
+
+      port@2:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: video port for the HDMI output
+
+      port@3:
+        $ref: /schemas/graph.yaml#/properties/port
+        description: sound input port
+
+    required:
+      - port@0
+      - port@2
+
+required:
+  - compatible
+  - reg
+  - ivdd-supply
+  - ovdd-supply
+  - txavcc18-supply
+  - txavcc33-supply
+  - pvcc1-supply
+  - pvcc2-supply
+  - avcc-supply
+  - anvdd-supply
+  - apvdd-supply
+  - ite,lvds-link-num-data-lanes
+  - ports
+
+additionalProperties: false
+
+examples:
+  - |
+    /* single-link LVDS input */
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        hdmi@4c {
+            compatible = "ite,it6263";
+            reg = <0x4c>;
+            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+            ivdd-supply = <&reg_buck5>;
+            ovdd-supply = <&reg_vext_3v3>;
+            txavcc18-supply = <&reg_buck5>;
+            txavcc33-supply = <&reg_vext_3v3>;
+            pvcc1-supply = <&reg_buck5>;
+            pvcc2-supply = <&reg_buck5>;
+            avcc-supply = <&reg_vext_3v3>;
+            anvdd-supply = <&reg_buck5>;
+            apvdd-supply = <&reg_buck5>;
+            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+
+                    it6263_lvds_link1: endpoint {
+                        remote-endpoint = <&ldb_lvds_ch0>;
+                    };
+                };
+
+                port@2 {
+                    reg = <2>;
+
+                    it6263_out: endpoint {
+                        remote-endpoint = <&hdmi_in>;
+                    };
+                };
+            };
+        };
+    };
+
+  - |
+    /* dual-link LVDS input */
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        hdmi@4c {
+            compatible = "ite,it6263";
+            reg = <0x4c>;
+            reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
+            ivdd-supply = <&reg_buck5>;
+            ovdd-supply = <&reg_vext_3v3>;
+            txavcc18-supply = <&reg_buck5>;
+            txavcc33-supply = <&reg_vext_3v3>;
+            pvcc1-supply = <&reg_buck5>;
+            pvcc2-supply = <&reg_buck5>;
+            avcc-supply = <&reg_vext_3v3>;
+            anvdd-supply = <&reg_buck5>;
+            apvdd-supply = <&reg_buck5>;
+            ite,lvds-link-num-data-lanes = /bits/ 8 <4>;
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+                    dual-lvds-odd-pixels;
+
+                    it6263_lvds_link1_dual: endpoint {
+                        remote-endpoint = <&ldb_lvds_ch0>;
+                    };
+                };
+
+                port@1 {
+                    reg = <1>;
+                    dual-lvds-even-pixels;
+
+                    it6263_lvds_link2_dual: endpoint {
+                        remote-endpoint = <&ldb_lvds_ch1>;
+                    };
+                };
+
+                port@2 {
+                    reg = <2>;
+
+                    it6263_out_dual: endpoint {
+                        remote-endpoint = <&hdmi_in>;
+                    };
+                };
+            };
+        };
+    };