linux-kernel - RE: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <TY3PR01MB113467D658D6680491662BA3586542@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Wed, 30 Oct 2024 09:02:39 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>, Liu Ying
	<victor.liu@....com>
CC: "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>,
	"linux-media@...r.kernel.org" <linux-media@...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>,
	"maarten.lankhorst@...ux.intel.com" <maarten.lankhorst@...ux.intel.com>,
	"mripard@...nel.org" <mripard@...nel.org>, "tzimmermann@...e.de"
	<tzimmermann@...e.de>, "airlied@...il.com" <airlied@...il.com>,
	"simona@...ll.ch" <simona@...ll.ch>, "robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "quic_jesszhan@...cinc.com"
	<quic_jesszhan@...cinc.com>, "mchehab@...nel.org" <mchehab@...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>,
	"sakari.ailus@...ux.intel.com" <sakari.ailus@...ux.intel.com>,
	"hverkuil@...all.nl" <hverkuil@...all.nl>, "tomi.valkeinen@...asonboard.com"
	<tomi.valkeinen@...asonboard.com>, "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>,
	"thierry.reding@...il.com" <thierry.reding@...il.com>, Prabhakar Mahadev Lad
	<prabhakar.mahadev-lad.rj@...renesas.com>, "sam@...nborg.org"
	<sam@...nborg.org>, "marex@...x.de" <marex@...x.de>
Subject: RE: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support

Hi Dmitry Baryshkov,

> -----Original Message-----
> From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> Sent: 30 October 2024 03:17
> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI converter support
> 
> On Tue, 29 Oct 2024 at 04:41, Liu Ying <victor.liu@....com> wrote:
> >
> > On 10/28/2024, Dmitry Baryshkov wrote:
> > > On Mon, Oct 28, 2024 at 11:12:00AM +0000, Biju Das wrote:
> > >> Hi Dmitry, Liu,
> > >>
> > >>> -----Original Message-----
> > >>> From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> > >>> Sent: 28 October 2024 10:20
> > >>> Subject: Re: [PATCH v4 00/13] Add ITE IT6263 LVDS to HDMI
> > >>> converter support
> > >>>
> > >>> Hi,
> > >>>
> > >>> On Mon, 28 Oct 2024 at 04:37, Liu Ying <victor.liu@....com> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> This patch series aims to add ITE IT6263 LVDS to HDMI converter
> > >>>> on i.MX8MP EVK.  Combined with LVDS receiver and HDMI 1.4a
> > >>>> transmitter, the IT6263 supports LVDS input and HDMI 1.4 output
> > >>>> by conversion function.  IT6263 product link can be found at [1].
> > >>>>
> > >>>> Patch 1 is a preparation patch to allow display mode of an
> > >>>> existing panel to pass the added mode validation logic in patch 3.
> > >>>>
> > >>>> Patch 2 allows i.MX8MP LVDS Display Bridge(LDB) bridge driver to
> > >>>> find the next non-panel bridge, that is the IT6263 in this case.
> > >>>>
> > >>>> Patch 3 adds mode validation logic to i.MX8MP LDB bridge driver
> > >>>> against "ldb" clock so that it can filter out unsupported display
> > >>>> modes read from EDID.
> > >>>>
> > >>>> Patch 4 adds MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} support,
> > >>>> as they are supported by IT6263(with LVDS data bit reversed order).
> > >>>>
> > >>>> Patch 5 makes drm_of.c use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG}.
> > >>>>
> > >>>> Patch 6 supports getting dual-link LVDS pixel order for the sink
> > >>>> side as needed by IT6263 driver.
> > >>>>
> > >>>> Patch 7 documents jeida-30 and vesa-30 data mappings in
> > >>>> lvds-data-mapping.yaml, as needed by IT6263 DT binding.
> > >>>>
> > >>>> Patch 8 extracts common dual-link LVDS display properties into
> > >>>> new lvds-dual-ports.yaml so that IT6263 DT binding can reference it.
> > >>>>
> > >>>> Patch 9 adds DT binding for IT6263.
> > >>>>
> > >>>> Patch 10 adds IT6263 bridge driver.  Only video output is supported.
> > >>>>
> > >>>> Patch 11 adds DT overlays to support NXP adapter cards[2][3] with
> > >>>> IT6263 populated.
> > >>>>
> > >>>> Patch 12 enables the IT6263 bridge driver in defconfig.
> > >>>>
> > >>>> Patch 13 updates MAINTAINERS to add maintainer for IT6263 driver.
> > >>>
> > >>> This has pretty complicated structure from the merging point of view.
> > >>>
> > >>> I propose we take patches 6, 8, 9 (without 30-bit formats, they
> > >>> can be dropped while applying), 11, 12
> > >>> (?) and 13 through drm-misc in one batch (once DT maintainers
> > >>> review the binding parts). This looks like a minimal set, having no extra dependencies.
> > >>
> > >>>
> > >>> The second set might be 4, 5 + new patch, re-adding 30-bit formats
> > >>> to
> > >>> IT6263 binding (no driver changes are necessary). This can go in
> > >>> separately, after an Ack from media maintainers.
> > >>>
> > >>> Of course both sets can go together if linux-media maintainers
> > >>> reacts quickly and ack merging media- formats patch through drm-misc tree.
> >
> > I'm fine with merging the two sets through drm-misc tree as long as
> > linux-media and dri-devel maintainers accept this.  Up to them.
> >
> > >>>
> > >>> The rest of the patches don't have such strong dependencies and go in once ready / reviewed.
> > >>>
> > >>> WDYT?
> > >>
> > >> I guess, 6,8,9(without 30-bit formats), 10, 12 and 13.
> > >>
> > >> 11 may have dependency on 1, 2 and 3 as it is SoC specific.
> > >
> > > Yes, of course, 10, not 11.
> > >
> > >> Then 4, 5 + new patch, re-adding 30-bit formats to IT6263 binding.
> >
> > I think it would be good to directly support 30-bit formats in
> > IT6263 DT binding, not re-add them to it.  This way, we'll have one
> > version of the binding, not two.  So, a better first set would contain
> > patch 6, 7(one existing A-b from Krzysztof), 8, 9, 10, 12 and 13.
> 
> I'm not sure that 7 can go without an ack from linux-media maintainers.

You mean in describing jeida-30 and vesa-30 format in
patch#7, is valid only if patch#4 is ok with media people
or they provide an ack for patch#7 to take it through drm tree?

Cheers,
Biju