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

[Dmitry Baryshkov]

On Tue, 15 Oct 2024 at 09:27, Liu Ying <victor.liu at 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 at 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 at 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.


-- 
With best wishes
Dmitry