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@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. 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 = <®_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
