Message ID | 20241028023740.19732-1-victor.liu@nxp.com |
---|---|
Headers | show |
Series | Add ITE IT6263 LVDS to HDMI converter support | expand |
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@linaro.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@nxp.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.
On Tue, 29 Oct 2024 at 04:41, Liu Ying <victor.liu@nxp.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@linaro.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@nxp.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.
Hi Dmitry Baryshkov, > -----Original Message----- > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.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@nxp.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@linaro.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@nxp.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
On Wed, 30 Oct 2024 at 11:02, Biju Das <biju.das.jz@bp.renesas.com> wrote: > > Hi Dmitry Baryshkov, > > > -----Original Message----- > > From: Dmitry Baryshkov <dmitry.baryshkov@linaro.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@nxp.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@linaro.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@nxp.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? The former one. I'd prefer an ack from linux-media maintainers to accept bindings based on those names.