| 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: <p42wdftkplib2c3hrnobinhytglok53cunqywtbcdfcp4gg7cg@4oclcixgcxso> Date: Mon, 14 Oct 2024 14:16:28 +0300 From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org> To: Biju Das <biju.das.jz@...renesas.com> Cc: Liu Ying <victor.liu@....com>, "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "andrzej.hajda@...el.com" <andrzej.hajda@...el.com>, "neil.armstrong@...aro.org" <neil.armstrong@...aro.org>, "rfoss@...nel.org" <rfoss@...nel.org>, "laurent.pinchart" <laurent.pinchart@...asonboard.com>, "jonas@...boo.se" <jonas@...boo.se>, "jernej.skrabec@...il.com" <jernej.skrabec@...il.com>, "airlied@...il.com" <airlied@...il.com>, "simona@...ll.ch" <simona@...ll.ch>, "maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>, "mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de" <tzimmermann@...e.de>, "robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>, "shawnguo@...nel.org" <shawnguo@...nel.org>, "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>, "kernel@...gutronix.de" <kernel@...gutronix.de>, "festevam@...il.com" <festevam@...il.com>, "catalin.marinas@....com" <catalin.marinas@....com>, "will@...nel.org" <will@...nel.org>, "quic_bjorande@...cinc.com" <quic_bjorande@...cinc.com>, "geert+renesas@...der.be" <geert+renesas@...der.be>, "arnd@...db.de" <arnd@...db.de>, "nfraprado@...labora.com" <nfraprado@...labora.com>, "o.rempel@...gutronix.de" <o.rempel@...gutronix.de>, "y.moog@...tec.de" <y.moog@...tec.de>, "marex@...x.de" <marex@...x.de>, "isaac.scott@...asonboard.com" <isaac.scott@...asonboard.com> Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter On Mon, Oct 14, 2024 at 08:09:44AM +0000, Biju Das wrote: > Hi Dmitry, > > > -----Original Message----- > > From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org> > > Sent: Monday, October 14, 2024 9:04 AM > > Subject: Re: [PATCH v2 5/9] dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter > > > > On Mon, Oct 14, 2024 at 07:39:16AM +0000, Biju Das wrote: > > > Hi Liu and Dmitry, > > > > > > > -----Original Message----- > > > > From: Liu Ying <victor.liu@....com> > > > > 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@....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.yam > > > > >>>> l > > > > >>>> > > > > >>>> diff --git > > > > >>>> a/Documentation/devicetree/bindings/display/bridge/ite,it6263.y > > > > >>>> aml > > > > >>>> b/Documentation/devicetree/bindings/display/bridge/ite,it6263.y > > > > >>>> aml > > > > >>>> new file mode 100644 > > > > >>>> index 000000000000..bc2bbec07623 > > > > >>>> --- /dev/null > > > > >>>> +++ b/Documentation/devicetree/bindings/display/bridge/ite,it62 > > > > >>>> +++ 63.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@....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. > > > > > > 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? > > It simple just want to change from VESA to JEDAI, how do you change it with existing DRM framework? Why do you want to change it on the fly? > Currently I see LVDS panel driver use drm_of_lvds_get_data_mapping(bus_node) to get this info. > IT6263 bridge device can use that API to get that info. > > Some vendors use VESA as default LVDS data mapping whereas some others use JEDAI. I think this is logical. Bus format is set by the system design constraints. In theory one can use buf format negotiation for the same purpose. > > Cheers, > Biju -- With best wishes Dmitry
Powered by blists - more mailing lists