| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <07b47f70-5dab-4813-97fa-388a0c0f42e9@nxp.com>
Date: Sat, 12 Oct 2024 17:14:13 +0800
From: Liu Ying <victor.liu@....com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
Cc: dri-devel@...ts.freedesktop.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, andrzej.hajda@...el.com,
neil.armstrong@...aro.org, rfoss@...nel.org,
Laurent.pinchart@...asonboard.com, jonas@...boo.se,
jernej.skrabec@...il.com, airlied@...il.com, simona@...ll.ch,
maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de,
robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de,
festevam@...il.com, catalin.marinas@....com, will@...nel.org,
quic_bjorande@...cinc.com, geert+renesas@...der.be, arnd@...db.de,
nfraprado@...labora.com, o.rempel@...gutronix.de, y.moog@...tec.de,
marex@...x.de, isaac.scott@...asonboard.com, biju.das.jz@...renesas.com
Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS
to HDMI converter
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@....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@....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 = <®_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
Powered by blists - more mailing lists