mbox series

[v4,00/13] Add ITE IT6263 LVDS to HDMI converter support

Message ID 20241028023740.19732-1-victor.liu@nxp.com
Headers show
Series Add ITE IT6263 LVDS to HDMI converter support | expand

Message

Liu Ying Oct. 28, 2024, 2:37 a.m. UTC
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.

Note that patch 3 depends on patch[4] in shawnguo/imx/fixes.

[1] https://www.ite.com.tw/en/product/cate1/IT6263
[2] https://www.nxp.com/part/IMX-LVDS-HDMI
[3] https://www.nxp.com/part/IMX-DLVDS-HDMI
[4] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20241017031146.157996-1-marex@denx.de/

v4:
* Squash change for advantech,idk-2121wr.yaml and
  panel-simple-lvds-dual-ports.yaml with lvds-dual-ports.yaml in patch 8.  (Rob)
* Improve description in lvds-dual-ports.yaml in patch 8.  (Krzysztof)
* Require dual-lvds-odd-pixels or dual-lvds-even-pixels DT properties for port@1
  in ite,it6263.yaml in patch 9.
* Drop "data-mirror: true" from ite,it6263.yaml in patch 9.
* Use local variable reset_gpio in IT6263 driver's probe() in patch 10.  (Biju)
* Move pixel clock rate validation from mode_valid callback to
  hdmi_tmds_char_rate_valid callback in IT6263 driver in patch 10.  (Maxime)
* Document IT6263 video processing throughput constraints by adding comments
  in IT6263 driver in patch 10.  (Maxime)
* Fix IT6263 LVDS 8-bit color depth macro BIT8 in IT6263 driver in patch 10.
* Drop 30-bit LVDS data bit order validation in IT6263 driver in patch 10.
* Rebase patch 11 upon next-20241025 to resolve conflicts when apply.
* Collect R-b and A-b tags.

v3:
* Use assigned-clock-rates DT property to set pixel clock rate for
  "multi-inno,mi1010ait-1cp" LVDS panel in patch 1 instead of using
  panel-timing node.  (Marek)
* Drop the patch for fixing pixel clock rate for "edt,etml1010g3dra"
  LVDS panel because there is already another better patch[4].
* Collect Dmitry's R-b tag for patch 2.
* Define MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG,JEIDA} in patch 4.
* Use MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA,SPWG} in drm_of.c in patch 5.
* Add drm_of_lvds_get_dual_link_pixel_order_sink() in patch 6.  (Dmitry)
* Document jeida-30 and vesa-30 in lvds-data-mapping.yaml in patch 7.
* Extract dual-link LVDS display common properties(patch 8-10).  (Dmitry)
* Reference lvds-dual-ports.yaml in ite,it6263.yaml in patch 11.  (Dmitry)
* Add data-mapping DT property in ite,it6263.yaml in patch 11.  (Dmitry, Biju)
* Allow data-mirror in ite,it6263.yaml in patch 11.
* Drop ite,lvds-link-num-data-lanes DT property from ite,it6263.yaml
  in patch 11.  (Dmitry, Biju)
* Use HDMI connector framework in IT6263 driver in patch 12.  (Maxime)
* Control the missing HDMI_REG_AVI_INFOFRM_CTRL register in IT6263 driver
  in patch 12.
* Validate the maximal HDMI TMDS character rate in IT6263 driver in patch 12.
  (Dmitry)
* Get LVDS data mapping from data-mapping DT property in IT6263 driver
  in patch 12.  (Dmitry, Biju)
* Validate 30bit LVDS data bit order by checking data-mirror DT property
  in IT6263 driver in patch 12.
* Use drm_of_lvds_get_dual_link_pixel_order_sink() in IT6263 driver
  in patch 12.  (Dmitry)
* Initialize a bridge connector instead of open coding in IT6263 driver
  in patch 12.  (Dmitry)
* Add a comment that IT6263 chip has no HPD IRQ support in IT6263 driver
  in patch 12.  (Dmitry)
* Use devm_drm_bridge_add() instead of drm_bridge_add() in IT6263 driver
  in patch 12.  (Dmitry)
* Fix a minor build warning reported by kernel test robot in IT6263 driver
  in patch 12.
* Use data-mapping DT property instead of ite,lvds-link-num-data-lanes
  in i.MX8MP evk DT files in patch 13.  (Dmitry, Biju)

v2:
* Add more comments in fsl-ldb.c and commit message about pixel clock
  rate validation for patch 4.  (Maxime)
* Document number of LVDS link data lanes in patch 5.  (Biju)
* Simplify ports property by dropping "oneOf" in patch 5.  (Rob)
* Add AVI inforframe support in patch 6.  (Maxime)
* Add DRM_MODE_CONNECTOR_HDMIA in patch 6.  (Biju)
* Rename it6263_reset() to it6263_hw_reset() in patch 6.  (Biju)
* Check number of LVDS link data lanes in patch 6.  (Biju)
* Add ite,lvds-link-num-data-lanes properties in patch 7.
* Update MAINTAINERS.  (Maxime)

*** BLURB HERE ***

Liu Ying (13):
  arm64: dts: imx8mp-skov-revb-mi1010ait-1cp1: Set "media_disp2_pix"
    clock rate to 70MHz
  drm/bridge: fsl-ldb: Get the next non-panel bridge
  drm/bridge: fsl-ldb: Use clk_round_rate() to validate "ldb" clock rate
  media: uapi: Add MEDIA_BUS_FMT_RGB101010_1X7X5_{SPWG, JEIDA}
  drm: of: Get MEDIA_BUS_FMT_RGB101010_1X7X5_{JEIDA, SPWG} LVDS data
    mappings
  drm: of: Add drm_of_lvds_get_dual_link_pixel_order_sink()
  dt-bindings: display: lvds-data-mapping: Add 30-bit RGB pixel data
    mappings
  dt-bindings: display: Document dual-link LVDS display common
    properties
  dt-bindings: display: bridge: Add ITE IT6263 LVDS to HDMI converter
  drm/bridge: Add ITE IT6263 LVDS to HDMI converter
  arm64: dts: imx8mp-evk: Add NXP LVDS to HDMI adapter cards
  arm64: defconfig: Enable ITE IT6263 driver
  MAINTAINERS: Add maintainer for ITE IT6263 driver

 .../bindings/display/bridge/ite,it6263.yaml   | 250 +++++
 .../bindings/display/lvds-data-mapping.yaml   |  31 +
 .../bindings/display/lvds-dual-ports.yaml     |  76 ++
 .../display/panel/advantech,idk-2121wr.yaml   |  14 +-
 .../panel/panel-simple-lvds-dual-ports.yaml   |  20 +-
 .../media/v4l/subdev-formats.rst              | 156 ++-
 MAINTAINERS                                   |   8 +
 arch/arm64/boot/dts/freescale/Makefile        |   8 +
 .../imx8mp-evk-imx-lvds-hdmi-common.dtsi      |  29 +
 ...8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso |  44 +
 ...imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi |  43 +
 .../imx8mp-evk-lvds0-imx-lvds-hdmi.dtso       |  28 +
 ...8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso |  44 +
 ...imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi |  43 +
 .../imx8mp-evk-lvds1-imx-lvds-hdmi.dtso       |  28 +
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts  |   6 +
 .../imx8mp-skov-revb-mi1010ait-1cp1.dts       |   8 +-
 arch/arm64/configs/defconfig                  |   1 +
 drivers/gpu/drm/bridge/Kconfig                |  11 +
 drivers/gpu/drm/bridge/Makefile               |   1 +
 drivers/gpu/drm/bridge/fsl-ldb.c              |  55 +-
 drivers/gpu/drm/bridge/ite-it6263.c           | 898 ++++++++++++++++++
 drivers/gpu/drm/drm_of.c                      |  82 +-
 include/drm/drm_of.h                          |   9 +
 include/uapi/linux/media-bus-format.h         |   4 +-
 25 files changed, 1827 insertions(+), 70 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ite,it6263.yaml
 create mode 100644 Documentation/devicetree/bindings/display/lvds-dual-ports.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-dlvds-hdmi-channel0.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds0-imx-lvds-hdmi.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-dlvds-hdmi-channel0.dtso
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi-common.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-evk-lvds1-imx-lvds-hdmi.dtso
 create mode 100644 drivers/gpu/drm/bridge/ite-it6263.c

Comments

Liu Ying Oct. 29, 2024, 2:41 a.m. UTC | #1
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.
Dmitry Baryshkov Oct. 30, 2024, 3:16 a.m. UTC | #2
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.
Biju Das Oct. 30, 2024, 9:02 a.m. UTC | #3
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
Dmitry Baryshkov Oct. 31, 2024, 6:20 p.m. UTC | #4
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.