On Mon, Oct 14, 2024 at 07:39:16AM +0000, Biju Das wrote: > Hi Liu and Dmitry, > > > -----Original Message----- > > From: Liu Ying <victor.liu@xxxxxxx> > > Sent: Monday, October 14, 2024 6:34 AM > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter > > > > 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.y > > >>>> +++ aml > > >>>> @@ -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. > > Assume a top level use case where a user changes the format from JEDAI to VESA using On screen > display or modetest(if some one adds support for lvds-mapping) then setting of the lvds data mapping > should be dynamic. > > Maybe for initial version hardcode with JEDAI or VESA as default and provide a way to override > the host driver and bridge with requested lvds-data mapping dynamically later?? The ite,lvds-link-num-data-lanes property should be removed, it is not standard. I foresee two ways to specify the number of lanes used: either the data-lanes property or the data-mapping property. Granted that data-mapping replaces the data-lanes functionality for LVDS links, I think it's better to use it from the start. Frankly speaking, what is the usecase for specifying the data mapping dynamically? What kind of uAPI do you have in mind and what is the usecase for it? -- With best wishes Dmitry
