On Tue, 15 Oct 2024 at 09:27, Liu Ying <victor.liu@xxxxxxx> 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@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. > > > > 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. -- With best wishes Dmitry
