[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1e8526e5-d9b7-42ac-9db3-13b42ccc4fbe@nxp.com>
Date: Tue, 29 Oct 2024 10:41:43 +0800
From: Liu Ying <victor.liu@....com>
To: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Biju Das <biju.das.jz@...renesas.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
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.
--
Regards,
Liu Ying
Powered by blists - more mailing lists