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@xxxxxxx> >>>> --- >>>> 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@xxxxxxx> >>>> + >>>> +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 = <®_buck5>; >>>> + ovdd-supply = <®_vext_3v3>; >>>> + txavcc18-supply = <®_buck5>; >>>> + txavcc33-supply = <®_vext_3v3>; >>>> + pvcc1-supply = <®_buck5>; >>>> + pvcc2-supply = <®_buck5>; >>>> + avcc-supply = <®_vext_3v3>; >>>> + anvdd-supply = <®_buck5>; >>>> + apvdd-supply = <®_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 = <®_buck5>; >>>> + ovdd-supply = <®_vext_3v3>; >>>> + txavcc18-supply = <®_buck5>; >>>> + txavcc33-supply = <®_vext_3v3>; >>>> + pvcc1-supply = <®_buck5>; >>>> + pvcc2-supply = <®_buck5>; >>>> + avcc-supply = <®_vext_3v3>; >>>> + anvdd-supply = <®_buck5>; >>>> + apvdd-supply = <®_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
