| Message ID | 169afe64b4985c3f420177cd6f4e1e72feeb2449.1645895582.git.hns@goldelico.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | MIPS: JZ4780 and CI20 HDMI | expand |
Hi, On 26/02/2022 18:13, H. Nikolaus Schaller wrote: > Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") > > introduced a new mechanism to negotiate bus formats between hdmi connectors > and bridges which is to be used e.g. for the jz4780 based CI20 board. > > In this case dw-hdmi sets up a list of formats in > dw_hdmi_bridge_atomic_get_output_bus_fmts(). > > This includes e.g. MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the CI20 but > only produces a black screen. > > Analysis revealed an omission in > > Commit 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") > > to check for 8 bit with when adding UYVY8 or YUV8 formats. > > This fix is based on the observation that max_bpc = 0 when running this > function while info->bpc = 8. In fact if bpc = 0, it should be considered as 8, so the issue is elsewhere. > > Adding the proposed patch makes the jz4780/CI20 panel work again with default > MEDIA_BUS_FMT_RGB888_1X24 mode. > > Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") > Fixes: 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") > Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 ++++++---- > 1 file changed, 6 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 43e375da131e8..c08e2cc96584c 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -2621,11 +2621,13 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, > output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; > } > > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > - output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; > + if (max_bpc >= 8 && info->bpc >= 8) { > + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > + output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; > > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > - output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; > + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; > + } It should not select YUV here if it's not possible, so something is wrong. Can you check if https://lore.kernel.org/r/20220119123656.1456355-2-narmstrong@baylibre.com fixes this issue instead ? Neil > > /* Default 8bit RGB fallback */ > output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
Hi Neil, > Am 01.03.2022 um 10:18 schrieb Neil Armstrong <narmstrong@baylibre.com>: > > Hi, > > On 26/02/2022 18:13, H. Nikolaus Schaller wrote: >> Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") >> introduced a new mechanism to negotiate bus formats between hdmi connectors >> and bridges which is to be used e.g. for the jz4780 based CI20 board. >> In this case dw-hdmi sets up a list of formats in >> dw_hdmi_bridge_atomic_get_output_bus_fmts(). >> This includes e.g. MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the CI20 but >> only produces a black screen. >> Analysis revealed an omission in >> Commit 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") >> to check for 8 bit with when adding UYVY8 or YUV8 formats. >> This fix is based on the observation that max_bpc = 0 when running this >> function while info->bpc = 8. > > In fact if bpc = 0, it should be considered as 8, so the issue is elsewhere. > >> Adding the proposed patch makes the jz4780/CI20 panel work again with default >> MEDIA_BUS_FMT_RGB888_1X24 mode. >> Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") >> Fixes: 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") >> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >> --- >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 ++++++---- >> 1 file changed, 6 insertions(+), 4 deletions(-) >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> index 43e375da131e8..c08e2cc96584c 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> @@ -2621,11 +2621,13 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, >> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; >> } >> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) >> - output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; >> + if (max_bpc >= 8 && info->bpc >= 8) { >> + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) >> + output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; >> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) >> - output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >> + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) >> + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >> + } > > It should not select YUV here if it's not possible, so something is wrong. > > Can you check if https://lore.kernel.org/r/20220119123656.1456355-2-narmstrong@baylibre.com fixes this issue instead ? Well, I had to manually fix it to be appliable to drm-misc/drm-misc-next and specifically: c03d0b52ff71 ("drm/connector: Fix typo in output format") My resulting patch is attached. Unfortunately it did not work. I added a printk for hdmi->sink_is_hdmi. This returns 1. Which IMHO is to be expected since I am using a HDMI connector and panel... So your patch will still add the UYVY formats. Either the synposys module inside the jz4780 or the panel does not understand them. Here is the EDID. Unfortunately it does not pretty print the extended descriptors for UYVY etc. so that I don't know the exact capabilities of the panel. And what I am not sure is if the jz4780 SoC can convert to UYVY or how it can. root@letux:~# parse-edid </sys/devices/platform/13050000.lcdc0/drm/card0/card0-HDMI-A-1/edid Checksum Correct Section "Monitor" Identifier "LEN L1950wD" ModelName "LEN L1950wD" VendorName "LEN" # Monitor Manufactured week 34 of 2011 # EDID version 1.3 # Digital Display DisplaySize 410 260 Gamma 2.20 Option "DPMS" "true" Horizsync 30-81 VertRefresh 50-76 # Maximum pixel clock is 140MHz #Not giving standard mode: 1152x864, 75Hz #Not giving standard mode: 1280x720, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1440x900, 75Hz #Not giving standard mode: 1920x1080, 60Hz #Extension block found. Parsing... Modeline "Mode 15" -hsync -vsync Modeline "Mode 0" -hsync +vsync Modeline "Mode 1" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace Modeline "Mode 2" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 4" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync Modeline "Mode 5" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace Modeline "Mode 6" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace Modeline "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 8" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync Modeline "Mode 9" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync Modeline "Mode 10" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 11" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace Modeline "Mode 12" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 13" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 14" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 16" +hsync +vsync interlace Modeline "Mode 17" +hsync +vsync interlace Modeline "Mode 18" +hsync +vsync Option "PreferredMode" "Mode 15" EndSection root@letux:~# xxd /sys/devices/platform/13050000.lcdc0/drm/card0/card0-HDMI-A-1/ 00000000: 00ff ffff ffff ff00 30ae 8610 0101 0101 ........0....... 00000010: 2215 0103 8029 1a78 eee5 b5a3 5549 9927 "....).x....UI.' 00000020: 1350 54af ef00 714f 81c0 8180 8180 8180 .PT...qO........ 00000030: 9500 950f d1c0 2413 0020 4158 1620 050d ......$.. AX. .. 00000040: 2300 ffff 0000 001c 0000 00fc 004c 454e #............LEN 00000050: 204c 3139 3530 7744 0a20 0000 00fd 0032 L1950wD. .....2 00000060: 4c1e 510e 000a 2020 2020 2020 0000 00ff L.Q... .... 00000070: 0042 3334 3332 3834 350a 2020 2020 0101 .B3432845. .. 00000080: 0203 2171 4e06 0702 0315 9611 1213 0414 ..!qN........... 00000090: 051f 9023 0907 0783 0100 0065 030c 0010 ...#.......e.... 000000a0: 008c 0ad0 9020 4031 200c 4055 00b9 8821 ..... @1 .@U...! 000000b0: 0000 1801 1d80 1871 1c16 2058 2c25 00b9 .......q.. X,%.. 000000c0: 8821 0000 9e01 1d80 d072 1c16 2010 2c25 .!.......r.. .,% 000000d0: 80b9 8821 0000 9e01 1d00 bc52 d01e 20b8 ...!.......R.. . 000000e0: 2855 40b9 8821 0000 1e02 3a80 d072 382d (U@..!....:..r8- 000000f0: 4010 2c45 80b9 8821 0000 1e00 0000 00d0 @.,E...!........ root@letux:~# root@letux:~# dmesg|grep dw.hdmi [ 9.622138] dw-hdmi-ingenic 10180000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY) [ 9.727840] dw-hdmi-ingenic 10180000.hdmi: registered DesignWare HDMI I2C bus driver [ 10.103864] dw_hdmi_bridge_atomic_get_output_bus_fmts: hdmi->sink_is_hdmi=1 So please let me know which parameters I should try to printk()... BR and thanks, Nikolaus ------ From c84a3c4a500684e57b1243fe5386696c48fa1e1b Mon Sep 17 00:00:00 2001 From: Neil Armstrong <narmstrong@baylibre.com> Date: Wed, 19 Jan 2022 13:36:56 +0100 Subject: [PATCH] drm/bridge: dw-hdmi: filter out YUV output formats when DVI When the display is not an HDMI sink, only the RGB output format is valid. Thus stop returning YUV output formats when sink is not HDMI. Fixes: 6c3c719936da ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 43e375da131e8..0ec0cbe448e05 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2538,6 +2538,7 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, struct drm_connector *conn = conn_state->connector; struct drm_display_info *info = &conn->display_info; struct drm_display_mode *mode = &crtc_state->mode; + struct dw_hdmi *hdmi = bridge->driver_private; u8 max_bpc = conn_state->max_requested_bpc; bool is_hdmi2_sink = info->hdmi.scdc.supported || (info->color_formats & DRM_COLOR_FORMAT_YCBCR420); @@ -2564,7 +2565,7 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, * If the current mode enforces 4:2:0, force the output but format * to 4:2:0 and do not add the YUV422/444/RGB formats */ - if (conn->ycbcr_420_allowed && + if (hdmi->sink_is_hdmi && conn->ycbcr_420_allowed && (drm_mode_is_420_only(info, mode) || (is_hdmi2_sink && drm_mode_is_420_also(info, mode)))) { @@ -2595,36 +2596,36 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, */ if (max_bpc >= 16 && info->bpc == 16) { - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) output_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48; output_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48; } if (max_bpc >= 12 && info->bpc >= 12) { - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR422) output_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24; - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) output_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36; output_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36; } if (max_bpc >= 10 && info->bpc >= 10) { - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR422) output_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20; - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) output_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30; output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; } - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR422) output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; /* Default 8bit RGB fallback */
H, On 01/03/2022 21:37, H. Nikolaus Schaller wrote: > Hi Neil, > > >> Am 01.03.2022 um 10:18 schrieb Neil Armstrong <narmstrong@baylibre.com>: >> >> Hi, >> >> On 26/02/2022 18:13, H. Nikolaus Schaller wrote: >>> Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") >>> introduced a new mechanism to negotiate bus formats between hdmi connectors >>> and bridges which is to be used e.g. for the jz4780 based CI20 board. >>> In this case dw-hdmi sets up a list of formats in >>> dw_hdmi_bridge_atomic_get_output_bus_fmts(). >>> This includes e.g. MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the CI20 but >>> only produces a black screen. >>> Analysis revealed an omission in >>> Commit 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") >>> to check for 8 bit with when adding UYVY8 or YUV8 formats. >>> This fix is based on the observation that max_bpc = 0 when running this >>> function while info->bpc = 8. >> >> In fact if bpc = 0, it should be considered as 8, so the issue is elsewhere. >> >>> Adding the proposed patch makes the jz4780/CI20 panel work again with default >>> MEDIA_BUS_FMT_RGB888_1X24 mode. >>> Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") >>> Fixes: 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") >>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> >>> --- >>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 ++++++---- >>> 1 file changed, 6 insertions(+), 4 deletions(-) >>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> index 43e375da131e8..c08e2cc96584c 100644 >>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >>> @@ -2621,11 +2621,13 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, >>> output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; >>> } >>> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) >>> - output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; >>> + if (max_bpc >= 8 && info->bpc >= 8) { >>> + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) >>> + output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; >>> - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) >>> - output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >>> + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) >>> + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >>> + } >> >> It should not select YUV here if it's not possible, so something is wrong. >> >> Can you check if https://lore.kernel.org/r/20220119123656.1456355-2-narmstrong@baylibre.com fixes this issue instead ? > > Well, I had to manually fix it to be appliable to drm-misc/drm-misc-next > and specifically: > > c03d0b52ff71 ("drm/connector: Fix typo in output format") > > My resulting patch is attached. > > Unfortunately it did not work. > > I added a printk for hdmi->sink_is_hdmi. This returns 1. Which IMHO is to be expected > since I am using a HDMI connector and panel... So your patch will still add the UYVY formats. > > Either the synposys module inside the jz4780 or the panel does not understand them. By selecting the UYVY formats, the driver will enable the colorspace converters in the dw-hdmi IP, I don't see why it doesn't work here... There is a bit called `Support Color Space Converter` in config0_id: bit | Name | R/W | Desc 2 | csc | R | Indicates if Color Space Conversion block is present Could you dump all the config0 bits: =======================><============================= diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 54d8fdad395f..547731482da8 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -3431,6 +3431,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, pdevinfo.id = PLATFORM_DEVID_AUTO; config0 = hdmi_readb(hdmi, HDMI_CONFIG0_ID); + dev_info(dev, "config0: %x\n", config0); config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID); if (iores && config3 & HDMI_CONFIG3_AHBAUDDMA) { =======================><============================= If this bit is missing, this would explain the black screen. Neil > > Here is the EDID. Unfortunately it does not pretty print the extended descriptors for UYVY etc. > so that I don't know the exact capabilities of the panel. And what I am not sure is if the > jz4780 SoC can convert to UYVY or how it can. > > root@letux:~# parse-edid </sys/devices/platform/13050000.lcdc0/drm/card0/card0-HDMI-A-1/edid > Checksum Correct > > Section "Monitor" > Identifier "LEN L1950wD" > ModelName "LEN L1950wD" > VendorName "LEN" > # Monitor Manufactured week 34 of 2011 > # EDID version 1.3 > # Digital Display > DisplaySize 410 260 > Gamma 2.20 > Option "DPMS" "true" > Horizsync 30-81 > VertRefresh 50-76 > # Maximum pixel clock is 140MHz > #Not giving standard mode: 1152x864, 75Hz > #Not giving standard mode: 1280x720, 60Hz > #Not giving standard mode: 1280x1024, 60Hz > #Not giving standard mode: 1280x1024, 60Hz > #Not giving standard mode: 1280x1024, 60Hz > #Not giving standard mode: 1440x900, 60Hz > #Not giving standard mode: 1440x900, 75Hz > #Not giving standard mode: 1920x1080, 60Hz > > #Extension block found. Parsing... > Modeline "Mode 15" -hsync -vsync > Modeline "Mode 0" -hsync +vsync > Modeline "Mode 1" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace > Modeline "Mode 2" 27.027 1440 1478 1602 1716 480 484 487 525 -hsync -vsync interlace > Modeline "Mode 3" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync > Modeline "Mode 4" 27.027 720 736 798 858 480 489 495 525 -hsync -vsync > Modeline "Mode 5" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace > Modeline "Mode 6" 27.000 1440 1464 1590 1728 576 578 581 625 -hsync -vsync interlace > Modeline "Mode 7" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync > Modeline "Mode 8" 27.000 720 732 796 864 576 581 586 625 -hsync -vsync > Modeline "Mode 9" 74.250 1280 1720 1760 1980 720 725 730 750 +hsync +vsync > Modeline "Mode 10" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync > Modeline "Mode 11" 74.250 1920 2448 2492 2640 1080 1082 1089 1125 +hsync +vsync interlace > Modeline "Mode 12" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace > Modeline "Mode 13" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync > Modeline "Mode 14" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync > Modeline "Mode 16" +hsync +vsync interlace > Modeline "Mode 17" +hsync +vsync interlace > Modeline "Mode 18" +hsync +vsync > Option "PreferredMode" "Mode 15" > EndSection > root@letux:~# xxd /sys/devices/platform/13050000.lcdc0/drm/card0/card0-HDMI-A-1/ > 00000000: 00ff ffff ffff ff00 30ae 8610 0101 0101 ........0....... > 00000010: 2215 0103 8029 1a78 eee5 b5a3 5549 9927 "....).x....UI.' > 00000020: 1350 54af ef00 714f 81c0 8180 8180 8180 .PT...qO........ > 00000030: 9500 950f d1c0 2413 0020 4158 1620 050d ......$.. AX. .. > 00000040: 2300 ffff 0000 001c 0000 00fc 004c 454e #............LEN > 00000050: 204c 3139 3530 7744 0a20 0000 00fd 0032 L1950wD. .....2 > 00000060: 4c1e 510e 000a 2020 2020 2020 0000 00ff L.Q... .... > 00000070: 0042 3334 3332 3834 350a 2020 2020 0101 .B3432845. .. > 00000080: 0203 2171 4e06 0702 0315 9611 1213 0414 ..!qN........... > 00000090: 051f 9023 0907 0783 0100 0065 030c 0010 ...#.......e.... > 000000a0: 008c 0ad0 9020 4031 200c 4055 00b9 8821 ..... @1 .@U...! > 000000b0: 0000 1801 1d80 1871 1c16 2058 2c25 00b9 .......q.. X,%.. > 000000c0: 8821 0000 9e01 1d80 d072 1c16 2010 2c25 .!.......r.. .,% > 000000d0: 80b9 8821 0000 9e01 1d00 bc52 d01e 20b8 ...!.......R.. . > 000000e0: 2855 40b9 8821 0000 1e02 3a80 d072 382d (U@..!....:..r8- > 000000f0: 4010 2c45 80b9 8821 0000 1e00 0000 00d0 @.,E...!........ > root@letux:~# root@letux:~# dmesg|grep dw.hdmi > [ 9.622138] dw-hdmi-ingenic 10180000.hdmi: Detected HDMI TX controller v1.31a with HDCP (DWC HDMI 3D TX PHY) > [ 9.727840] dw-hdmi-ingenic 10180000.hdmi: registered DesignWare HDMI I2C bus driver > [ 10.103864] dw_hdmi_bridge_atomic_get_output_bus_fmts: hdmi->sink_is_hdmi=1 > > So please let me know which parameters I should try to printk()... > > BR and thanks, > Nikolaus > > > ------ > > From c84a3c4a500684e57b1243fe5386696c48fa1e1b Mon Sep 17 00:00:00 2001 > From: Neil Armstrong <narmstrong@baylibre.com> > Date: Wed, 19 Jan 2022 13:36:56 +0100 > Subject: [PATCH] drm/bridge: dw-hdmi: filter out YUV output formats when DVI > > When the display is not an HDMI sink, only the RGB output format is > valid. Thus stop returning YUV output formats when sink is not HDMI. > > Fixes: 6c3c719936da ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 43e375da131e8..0ec0cbe448e05 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -2538,6 +2538,7 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, > struct drm_connector *conn = conn_state->connector; > struct drm_display_info *info = &conn->display_info; > struct drm_display_mode *mode = &crtc_state->mode; > + struct dw_hdmi *hdmi = bridge->driver_private; > u8 max_bpc = conn_state->max_requested_bpc; > bool is_hdmi2_sink = info->hdmi.scdc.supported || > (info->color_formats & DRM_COLOR_FORMAT_YCBCR420); > @@ -2564,7 +2565,7 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, > * If the current mode enforces 4:2:0, force the output but format > * to 4:2:0 and do not add the YUV422/444/RGB formats > */ > - if (conn->ycbcr_420_allowed && > + if (hdmi->sink_is_hdmi && conn->ycbcr_420_allowed && > (drm_mode_is_420_only(info, mode) || > (is_hdmi2_sink && drm_mode_is_420_also(info, mode)))) { > > @@ -2595,36 +2596,36 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, > */ > > if (max_bpc >= 16 && info->bpc == 16) { > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > output_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48; > > output_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48; > } > > if (max_bpc >= 12 && info->bpc >= 12) { > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > output_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24; > > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > output_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36; > > output_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36; > } > > if (max_bpc >= 10 && info->bpc >= 10) { > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > output_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20; > > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > output_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30; > > output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; > } > > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR422) > output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; > > - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > + if (hdmi->sink_is_hdmi && info->color_formats & DRM_COLOR_FORMAT_YCBCR444) > output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; > > /* Default 8bit RGB fallback */
Hi Neil, > Am 02.03.2022 um 11:25 schrieb Neil Armstrong <narmstrong@baylibre.com>: > >> I added a printk for hdmi->sink_is_hdmi. This returns 1. Which IMHO is to be expected >> since I am using a HDMI connector and panel... So your patch will still add the UYVY formats. >> Either the synposys module inside the jz4780 or the panel does not understand them. > > By selecting the UYVY formats, the driver will enable the colorspace converters in the dw-hdmi IP, > I don't see why it doesn't work here... > > There is a bit called `Support Color Space Converter` in config0_id: > bit | Name | R/W | Desc > 2 | csc | R | Indicates if Color Space Conversion block is present > > Could you dump all the config0 bits: > > =======================><============================= > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index 54d8fdad395f..547731482da8 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -3431,6 +3431,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, > pdevinfo.id = PLATFORM_DEVID_AUTO; > > config0 = hdmi_readb(hdmi, HDMI_CONFIG0_ID); > + dev_info(dev, "config0: %x\n", config0); > config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID); > > if (iores && config3 & HDMI_CONFIG3_AHBAUDDMA) { > =======================><============================= > > If this bit is missing, this would explain the black screen. [ 9.291011] dw-hdmi-ingenic 10180000.hdmi: config0: bf Hm. Or is the color-space conversion of the sw-hdmi module inside the jz4780 broken or not configured properly? (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) BR and thanks, Nikolaus
Hi, On 02/03/2022 12:15, H. Nikolaus Schaller wrote: > Hi Neil, > >> Am 02.03.2022 um 11:25 schrieb Neil Armstrong <narmstrong@baylibre.com>: >> >>> I added a printk for hdmi->sink_is_hdmi. This returns 1. Which IMHO is to be expected >>> since I am using a HDMI connector and panel... So your patch will still add the UYVY formats. >>> Either the synposys module inside the jz4780 or the panel does not understand them. >> >> By selecting the UYVY formats, the driver will enable the colorspace converters in the dw-hdmi IP, >> I don't see why it doesn't work here... >> >> There is a bit called `Support Color Space Converter` in config0_id: >> bit | Name | R/W | Desc >> 2 | csc | R | Indicates if Color Space Conversion block is present >> >> Could you dump all the config0 bits: >> >> =======================><============================= >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> index 54d8fdad395f..547731482da8 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> @@ -3431,6 +3431,7 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, >> pdevinfo.id = PLATFORM_DEVID_AUTO; >> >> config0 = hdmi_readb(hdmi, HDMI_CONFIG0_ID); >> + dev_info(dev, "config0: %x\n", config0); >> config3 = hdmi_readb(hdmi, HDMI_CONFIG3_ID); >> >> if (iores && config3 & HDMI_CONFIG3_AHBAUDDMA) { >> =======================><============================= >> >> If this bit is missing, this would explain the black screen. > > [ 9.291011] dw-hdmi-ingenic 10180000.hdmi: config0: bf > > Hm. Or is the color-space conversion of the sw-hdmi module inside the jz4780 broken > or not configured properly? > > (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) I don't understand what's wrong, can you try to make the logic select MEDIA_BUS_FMT_YUV8_1X24 instead of DRM_COLOR_FORMAT_YCBCR422 ? If your CSC is broken, we'll need to disable it on your platform. Thanks, Neil > > BR and thanks, > Nikolaus >
Hi Neil, > Am 02.03.2022 um 15:34 schrieb Neil Armstrong <narmstrong@baylibre.com>: > > Hi, > >> (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) > > I don't understand what's wrong, can you try to make the logic select MEDIA_BUS_FMT_YUV8_1X24 instead of DRM_COLOR_FORMAT_YCBCR422 ? I have forced hdmi->sink_is_hdmi = false and replaced /* Default 8bit RGB fallback */ - output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; And then screen remains black. MEDIA_BUS_FMT_RGB888_1X24 works. (MEDIA_BUS_FMT_VUY8_1X24 doesn't work either). So this indicates that YUV conversion is not working properly. Maybe missing some special setup. What I have to test if it works on a different monitor. Not that this specific panel (a 7 inch waveshare touch with HDMIinput) is buggy and reports YUV capabilities but does not handle them... On the other hand this panel works on RasPi and OMAP5 (where I admit I do not know in which mode). > If your CSC is broken, we'll need to disable it on your platform. Indeed. So it seems as if we need a mechanism to overwrite dw_hdmi_bridge_atomic_get_output_bus_fmts() in our ingenic-dw-hdmi platform specialization [1] to always return MEDIA_BUS_FMT_RGB888_1X24. Or alternatively set sink_is_hdmi = false there (unfortunately there is no direct access to struct dw_hdmi in a specialization drivers). Is this already possible or how can it be done? BR and thanks, Nikolaus [1]: https://lore.kernel.org/all/24a27226a22adf5f5573f013e5d7d89b0ec73664.1645895582.git.hns@goldelico.com/
Hi, On 02/03/2022 23:24, H. Nikolaus Schaller wrote: > Hi Neil, > >> Am 02.03.2022 um 15:34 schrieb Neil Armstrong <narmstrong@baylibre.com>: >> >> Hi, >> >>> (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) >> >> I don't understand what's wrong, can you try to make the logic select MEDIA_BUS_FMT_YUV8_1X24 instead of DRM_COLOR_FORMAT_YCBCR422 ? > > I have forced hdmi->sink_is_hdmi = false and replaced > > /* Default 8bit RGB fallback */ > - output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; > + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; > > And then screen remains black. MEDIA_BUS_FMT_RGB888_1X24 works. > (MEDIA_BUS_FMT_VUY8_1X24 doesn't work either). > > So this indicates that YUV conversion is not working properly. Maybe missing some special > setup. > > What I have to test if it works on a different monitor. Not that this specific panel > (a 7 inch waveshare touch with HDMIinput) is buggy and reports YUV capabilities > but does not handle them... > > On the other hand this panel works on RasPi and OMAP5 (where I admit I do not know in > which mode). Pretty sure they don't support YUV HDMI output. If you can try on a certified HDMI devices like a TV, it would here figuring out where comes the issue. > >> If your CSC is broken, we'll need to disable it on your platform. > > Indeed. > > So it seems as if we need a mechanism to overwrite dw_hdmi_bridge_atomic_get_output_bus_fmts() > in our ingenic-dw-hdmi platform specialization [1] to always return MEDIA_BUS_FMT_RGB888_1X24. > > Or alternatively set sink_is_hdmi = false there (unfortunately there is no direct access to > struct dw_hdmi in a specialization drivers). > > Is this already possible or how can it be done? It's not handled yet, but we may add the logic to handle the lack of CSC config bit and add a glue config bit to override this like we already did for CEC. I wrote an initial support to disable CSC (only compile-tested), could you try on your platform with setting disable_csc = 1 in your dw-hdmi glue code ? ================><======================================= diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 54d8fdad395f..d345166a69aa 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -158,6 +158,8 @@ struct dw_hdmi { struct hdmi_data_info hdmi_data; const struct dw_hdmi_plat_data *plat_data; + bool csc_available; /* indicates if the CSC engine is usable */ + int vic; u8 edid[HDMI_EDID_LEN]; @@ -1009,9 +1011,10 @@ static int is_color_space_interpolation(struct dw_hdmi *hdmi) static bool is_csc_needed(struct dw_hdmi *hdmi) { - return is_color_space_conversion(hdmi) || - is_color_space_decimation(hdmi) || - is_color_space_interpolation(hdmi); + return hdmi->csc_available && + (is_color_space_conversion(hdmi) || + is_color_space_decimation(hdmi) || + is_color_space_interpolation(hdmi)); } static void dw_hdmi_update_csc_coeffs(struct dw_hdmi *hdmi) @@ -1064,6 +1067,9 @@ static void hdmi_video_csc(struct dw_hdmi *hdmi) int interpolation = HDMI_CSC_CFG_INTMODE_DISABLE; int decimation = 0; + if (!hdmi->csc_available) + return; + /* YCC422 interpolation to 444 mode */ if (is_color_space_interpolation(hdmi)) interpolation = HDMI_CSC_CFG_INTMODE_CHROMA_INT_FORMULA1; @@ -2663,6 +2669,7 @@ static u32 *dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge, u32 output_fmt, unsigned int *num_input_fmts) { + struct dw_hdmi *hdmi = bridge->driver_private; u32 *input_fmts; unsigned int i = 0; @@ -2681,62 +2688,81 @@ static u32 *dw_hdmi_bridge_atomic_get_input_bus_fmts(struct drm_bridge *bridge, /* 8bit */ case MEDIA_BUS_FMT_RGB888_1X24: input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; - input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; - input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; + input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; + } break; case MEDIA_BUS_FMT_YUV8_1X24: input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; - input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; - input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; + input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; + } break; case MEDIA_BUS_FMT_UYVY8_1X16: input_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; - input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; - input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; + input_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; + } break; /* 10bit */ case MEDIA_BUS_FMT_RGB101010_1X30: input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; - input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30; - input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30; + input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20; + } break; case MEDIA_BUS_FMT_YUV10_1X30: input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30; - input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20; - input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20; + input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; + } break; case MEDIA_BUS_FMT_UYVY10_1X20: input_fmts[i++] = MEDIA_BUS_FMT_UYVY10_1X20; - input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30; - input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_YUV10_1X30; + input_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; + } break; /* 12bit */ case MEDIA_BUS_FMT_RGB121212_1X36: input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36; - input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36; - input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36; + input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24; + } break; case MEDIA_BUS_FMT_YUV12_1X36: input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36; - input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24; - input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24; + input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36; + } break; case MEDIA_BUS_FMT_UYVY12_1X24: input_fmts[i++] = MEDIA_BUS_FMT_UYVY12_1X24; - input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36; - input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36; + if (hdmi->csc_available) { + input_fmts[i++] = MEDIA_BUS_FMT_YUV12_1X36; + input_fmts[i++] = MEDIA_BUS_FMT_RGB121212_1X36; + } break; /* 16bit */ case MEDIA_BUS_FMT_RGB161616_1X48: input_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48; - input_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48; + if (hdmi->csc_available) + input_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48; break; case MEDIA_BUS_FMT_YUV16_1X48: - input_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48; - input_fmts[i++] = MEDIA_BUS_FMT_RGB161616_1X48; + if (hdmi->csc_available) + input_fmts[i++] = MEDIA_BUS_FMT_YUV16_1X48; break; /*YUV 4:2:0 */ @@ -2765,15 +2791,24 @@ static int dw_hdmi_bridge_atomic_check(struct drm_bridge *bridge, { struct dw_hdmi *hdmi = bridge->driver_private; - hdmi->hdmi_data.enc_out_bus_format = - bridge_state->output_bus_cfg.format; + if (!hdmi->csc_available && + bridge_state->output_bus_cfg.format != bridge_state->input_bus_cfg.format) { + dev_warn(hdmi->dev, "different input format 0x%04x & output format 0x%04x while CSC isn't usable, fallback to safe format\n", + bridge_state->input_bus_cfg.format, + bridge_state->output_bus_cfg.format); + hdmi->hdmi_data.enc_out_bus_format = MEDIA_BUS_FMT_FIXED; + hdmi->hdmi_data.enc_in_bus_format = MEDIA_BUS_FMT_FIXED; + } else { + hdmi->hdmi_data.enc_out_bus_format = + bridge_state->output_bus_cfg.format; - hdmi->hdmi_data.enc_in_bus_format = - bridge_state->input_bus_cfg.format; + hdmi->hdmi_data.enc_in_bus_format = + bridge_state->input_bus_cfg.format; - dev_dbg(hdmi->dev, "input format 0x%04x, output format 0x%04x\n", - bridge_state->input_bus_cfg.format, - bridge_state->output_bus_cfg.format); + dev_dbg(hdmi->dev, "input format 0x%04x, output format 0x%04x\n", + bridge_state->input_bus_cfg.format, + bridge_state->output_bus_cfg.format); + } return 0; } @@ -3479,6 +3514,9 @@ struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, hdmi->cec = platform_device_register_full(&pdevinfo); } + /* Get CSC useability from config0 register and permit override for platforms */ + hdmi->csc_available = !plat_data->disable_csc || (config0 & HDMI_CONFIG0_CSC); + drm_bridge_add(&hdmi->bridge); return hdmi; diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index 1999db05bc3b..279722e4d189 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h @@ -541,6 +541,7 @@ enum { /* CONFIG0_ID field values */ HDMI_CONFIG0_I2S = 0x10, + HDMI_CONFIG0_CSC = 0x04, HDMI_CONFIG0_CEC = 0x02, /* CONFIG1_ID field values */ diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h index 2a1f85f9a8a3..b2f689cbe864 100644 --- a/include/drm/bridge/dw_hdmi.h +++ b/include/drm/bridge/dw_hdmi.h @@ -157,6 +157,7 @@ struct dw_hdmi_plat_data { unsigned long mpixelclock); unsigned int disable_cec : 1; + unsigned int disable_csc : 1; }; struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev, =================><============================================================== Neil > > BR and thanks, > Nikolaus > > [1]: https://lore.kernel.org/all/24a27226a22adf5f5573f013e5d7d89b0ec73664.1645895582.git.hns@goldelico.com/
Hi Neil, > Am 03.03.2022 um 09:35 schrieb Neil Armstrong <narmstrong@baylibre.com>: > > Hi, > > On 02/03/2022 23:24, H. Nikolaus Schaller wrote: >> Hi Neil, >>> Am 02.03.2022 um 15:34 schrieb Neil Armstrong <narmstrong@baylibre.com>: >>> >>> Hi, >>> >>>> (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) >>> >>> I don't understand what's wrong, can you try to make the logic select MEDIA_BUS_FMT_YUV8_1X24 instead of DRM_COLOR_FORMAT_YCBCR422 ? >> I have forced hdmi->sink_is_hdmi = false and replaced >> /* Default 8bit RGB fallback */ >> - output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; >> + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >> And then screen remains black. MEDIA_BUS_FMT_RGB888_1X24 works. >> (MEDIA_BUS_FMT_VUY8_1X24 doesn't work either). >> So this indicates that YUV conversion is not working properly. Maybe missing some special >> setup. >> What I have to test if it works on a different monitor. Same effect on a Xiaomi monitor (user manual just telling HDMI1,4 compatible), an older Acer video projector and a Sharp TV set. The Xiaomi monitor does not say "No signal" but shows a black screen. The others do not even report any HDMI signals. All work well with MEDIA_BUS_FMT_RGB888_1X24. This means the transcoding to YUV does not work properly on the jz4780 SoC setup. So it looks as if we have to disable it (at least unless someone finds a fix). >> Not that this specific panel >> (a 7 inch waveshare touch with HDMIinput) is buggy and reports YUV capabilities >> but does not handle them... >> On the other hand this panel works on RasPi and OMAP5 (where I admit I do not know in >> which mode). > > Pretty sure they don't support YUV HDMI output. > > If you can try on a certified HDMI devices like a TV, it would here figuring out where comes the issue. I am not sure if the Sharp TV is fully certified but would assume... > >>> If your CSC is broken, we'll need to disable it on your platform. >> Indeed. >> So it seems as if we need a mechanism to overwrite dw_hdmi_bridge_atomic_get_output_bus_fmts() >> in our ingenic-dw-hdmi platform specialization [1] to always return MEDIA_BUS_FMT_RGB888_1X24. >> Or alternatively set sink_is_hdmi = false there (unfortunately there is no direct access to >> struct dw_hdmi in a specialization drivers). >> Is this already possible or how can it be done? > > It's not handled yet, but we may add the logic to handle the lack of CSC config bit and > add a glue config bit to override this like we already did for CEC. > > I wrote an initial support to disable CSC (only compile-tested), could you try on your platform with setting disable_csc = 1 in your dw-hdmi glue code ? This works! So how can we get that merged? IMHO your proposal should be before we add ingenic-dw-hdmi. If you have a version with proper commit message I can add it to the beginning of my seried and include it in a v17. Or if you get yours merged to drm-misc/drm-misc-next I can build on top. BR and thanks, Nikolaus
On 03/03/2022 11:40, H. Nikolaus Schaller wrote: > Hi Neil, > >> Am 03.03.2022 um 09:35 schrieb Neil Armstrong <narmstrong@baylibre.com>: >> >> Hi, >> >> On 02/03/2022 23:24, H. Nikolaus Schaller wrote: >>> Hi Neil, >>>> Am 02.03.2022 um 15:34 schrieb Neil Armstrong <narmstrong@baylibre.com>: >>>> >>>> Hi, >>>> >>>>> (cross-checked: RGB mode still works if I force hdmi->sink_is_hdmi = false) >>>> >>>> I don't understand what's wrong, can you try to make the logic select MEDIA_BUS_FMT_YUV8_1X24 instead of DRM_COLOR_FORMAT_YCBCR422 ? >>> I have forced hdmi->sink_is_hdmi = false and replaced >>> /* Default 8bit RGB fallback */ >>> - output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; >>> + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >>> And then screen remains black. MEDIA_BUS_FMT_RGB888_1X24 works. >>> (MEDIA_BUS_FMT_VUY8_1X24 doesn't work either). >>> So this indicates that YUV conversion is not working properly. Maybe missing some special >>> setup. >>> What I have to test if it works on a different monitor. > > Same effect on a Xiaomi monitor (user manual just telling HDMI1,4 compatible), an > older Acer video projector and a Sharp TV set. > > The Xiaomi monitor does not say "No signal" but shows a black screen. The others > do not even report any HDMI signals. All work well with MEDIA_BUS_FMT_RGB888_1X24. > > This means the transcoding to YUV does not work properly on the jz4780 SoC setup. > > So it looks as if we have to disable it (at least unless someone finds a fix). > >>> Not that this specific panel >>> (a 7 inch waveshare touch with HDMIinput) is buggy and reports YUV capabilities >>> but does not handle them... >>> On the other hand this panel works on RasPi and OMAP5 (where I admit I do not know in >>> which mode). >> >> Pretty sure they don't support YUV HDMI output. >> >> If you can try on a certified HDMI devices like a TV, it would here figuring out where comes the issue. > > I am not sure if the Sharp TV is fully certified but would assume... > >> >>>> If your CSC is broken, we'll need to disable it on your platform. >>> Indeed. >>> So it seems as if we need a mechanism to overwrite dw_hdmi_bridge_atomic_get_output_bus_fmts() >>> in our ingenic-dw-hdmi platform specialization [1] to always return MEDIA_BUS_FMT_RGB888_1X24. >>> Or alternatively set sink_is_hdmi = false there (unfortunately there is no direct access to >>> struct dw_hdmi in a specialization drivers). >>> Is this already possible or how can it be done? >> >> It's not handled yet, but we may add the logic to handle the lack of CSC config bit and >> add a glue config bit to override this like we already did for CEC. >> >> I wrote an initial support to disable CSC (only compile-tested), could you try on your platform with setting disable_csc = 1 in your dw-hdmi glue code ? > > This works! > > So how can we get that merged? IMHO your proposal should be before we add ingenic-dw-hdmi. > If you have a version with proper commit message I can add it to the beginning of my > seried and include it in a v17. Or if you get yours merged to drm-misc/drm-misc-next I > can build on top. You can add it in your v17 patchset with my authorship and my Signed-off-by tag + yours. As commit message something like : ==================== drm/bridge: dw-hdmi: handle unusable or non-configured CSC module The dw-hdmi integrates an optional Color Space Conversion feature used to handle color-space conversions. On some platforms, the CSC isn't built-in or non-functional. This adds the necessary code to disable the CSC functionality and limit the bus format negotiation to force using the same input bus format as the output bus format. ==================== Thanks, Neil > > BR and thanks, > Nikolaus >
Hi Neil, > Am 03.03.2022 um 12:42 schrieb Neil Armstrong <narmstrong@baylibre.com>: > >> So how can we get that merged? IMHO your proposal should be before we add ingenic-dw-hdmi. >> If you have a version with proper commit message I can add it to the beginning of my >> seried and include it in a v17. Or if you get yours merged to drm-misc/drm-misc-next I >> can build on top. > > You can add it in your v17 patchset with my authorship and my Signed-off-by tag + yours. > > As commit message something like : > ==================== > drm/bridge: dw-hdmi: handle unusable or non-configured CSC module > > The dw-hdmi integrates an optional Color Space Conversion feature used > to handle color-space conversions. > > On some platforms, the CSC isn't built-in or non-functional. > > This adds the necessary code to disable the CSC functionality > and limit the bus format negotiation to force using the same > input bus format as the output bus format. > ==================== Fine! Will do. BR and thanks, Nikolaus
Hi Neil, Any feedback on the other patches? They look fine to me, but I still need an ack to merge them in drm-misc-next. Cheers, -Paul Le jeu., mars 3 2022 at 12:42:02 +0100, Neil Armstrong <narmstrong@baylibre.com> a écrit : > On 03/03/2022 11:40, H. Nikolaus Schaller wrote: >> Hi Neil, >> >>> Am 03.03.2022 um 09:35 schrieb Neil Armstrong >>> <narmstrong@baylibre.com>: >>> >>> Hi, >>> >>> On 02/03/2022 23:24, H. Nikolaus Schaller wrote: >>>> Hi Neil, >>>>> Am 02.03.2022 um 15:34 schrieb Neil Armstrong >>>>> <narmstrong@baylibre.com>: >>>>> >>>>> Hi, >>>>> >>>>>> (cross-checked: RGB mode still works if I force >>>>>> hdmi->sink_is_hdmi = false) >>>>> >>>>> I don't understand what's wrong, can you try to make the logic >>>>> select MEDIA_BUS_FMT_YUV8_1X24 instead of >>>>> DRM_COLOR_FORMAT_YCBCR422 ? >>>> I have forced hdmi->sink_is_hdmi = false and replaced >>>> /* Default 8bit RGB fallback */ >>>> - output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24; >>>> + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; >>>> And then screen remains black. MEDIA_BUS_FMT_RGB888_1X24 works. >>>> (MEDIA_BUS_FMT_VUY8_1X24 doesn't work either). >>>> So this indicates that YUV conversion is not working properly. >>>> Maybe missing some special >>>> setup. >>>> What I have to test if it works on a different monitor. >> >> Same effect on a Xiaomi monitor (user manual just telling HDMI1,4 >> compatible), an >> older Acer video projector and a Sharp TV set. >> >> The Xiaomi monitor does not say "No signal" but shows a black >> screen. The others >> do not even report any HDMI signals. All work well with >> MEDIA_BUS_FMT_RGB888_1X24. >> >> This means the transcoding to YUV does not work properly on the >> jz4780 SoC setup. >> >> So it looks as if we have to disable it (at least unless someone >> finds a fix). >> >>>> Not that this specific panel >>>> (a 7 inch waveshare touch with HDMIinput) is buggy and reports YUV >>>> capabilities >>>> but does not handle them... >>>> On the other hand this panel works on RasPi and OMAP5 (where I >>>> admit I do not know in >>>> which mode). >>> >>> Pretty sure they don't support YUV HDMI output. >>> >>> If you can try on a certified HDMI devices like a TV, it would here >>> figuring out where comes the issue. >> >> I am not sure if the Sharp TV is fully certified but would assume... >> >>> >>>>> If your CSC is broken, we'll need to disable it on your platform. >>>> Indeed. >>>> So it seems as if we need a mechanism to overwrite >>>> dw_hdmi_bridge_atomic_get_output_bus_fmts() >>>> in our ingenic-dw-hdmi platform specialization [1] to always >>>> return MEDIA_BUS_FMT_RGB888_1X24. >>>> Or alternatively set sink_is_hdmi = false there (unfortunately >>>> there is no direct access to >>>> struct dw_hdmi in a specialization drivers). >>>> Is this already possible or how can it be done? >>> >>> It's not handled yet, but we may add the logic to handle the lack >>> of CSC config bit and >>> add a glue config bit to override this like we already did for CEC. >>> >>> I wrote an initial support to disable CSC (only compile-tested), >>> could you try on your platform with setting disable_csc = 1 in your >>> dw-hdmi glue code ? >> >> This works! >> >> So how can we get that merged? IMHO your proposal should be before >> we add ingenic-dw-hdmi. >> If you have a version with proper commit message I can add it to the >> beginning of my >> seried and include it in a v17. Or if you get yours merged to >> drm-misc/drm-misc-next I >> can build on top. > > You can add it in your v17 patchset with my authorship and my > Signed-off-by tag + yours. > > As commit message something like : > ==================== > drm/bridge: dw-hdmi: handle unusable or non-configured CSC module > > The dw-hdmi integrates an optional Color Space Conversion feature used > to handle color-space conversions. > > On some platforms, the CSC isn't built-in or non-functional. > > This adds the necessary code to disable the CSC functionality > and limit the bus format negotiation to force using the same > input bus format as the output bus format. > ==================== > > Thanks, > Neil > >> >> BR and thanks, >> Nikolaus >> >
Hi Neil, > Am 03.03.2022 um 12:45 schrieb H. Nikolaus Schaller <hns@goldelico.com>: > > Hi Neil, > >> Am 03.03.2022 um 12:42 schrieb Neil Armstrong <narmstrong@baylibre.com>: >> >>> So how can we get that merged? IMHO your proposal should be before we add ingenic-dw-hdmi. >>> If you have a version with proper commit message I can add it to the beginning of my >>> seried and include it in a v17. Or if you get yours merged to drm-misc/drm-misc-next I >>> can build on top. >> >> You can add it in your v17 patchset with my authorship and my Signed-off-by tag + yours. >> >> As commit message something like : >> ==================== >> drm/bridge: dw-hdmi: handle unusable or non-configured CSC module >> >> The dw-hdmi integrates an optional Color Space Conversion feature used >> to handle color-space conversions. >> >> On some platforms, the CSC isn't built-in or non-functional. >> >> This adds the necessary code to disable the CSC functionality >> and limit the bus format negotiation to force using the same >> input bus format as the output bus format. >> ==================== > > Fine! Will do. I was a little too early. While preparing the patches I found that I still had the hack to force sink_is_hdmi = false in my test branch. Sorry for that. Removing this made the panel go black again, even with your latest proposal. So I looked deeper into your patch and it seems to influence the input formats only in dw_hdmi_bridge_atomic_get_input_bus_fmts()? While the problem I see is with output formats and we had worked on modifying dw_hdmi_bridge_atomic_get_output_bus_fmts(). BR and thanks, Nikolaus
Hi, On 03/03/2022 16:37, H. Nikolaus Schaller wrote: > Hi Neil, > >> Am 03.03.2022 um 12:45 schrieb H. Nikolaus Schaller <hns@goldelico.com>: >> >> Hi Neil, >> >>> Am 03.03.2022 um 12:42 schrieb Neil Armstrong <narmstrong@baylibre.com>: >>> >>>> So how can we get that merged? IMHO your proposal should be before we add ingenic-dw-hdmi. >>>> If you have a version with proper commit message I can add it to the beginning of my >>>> seried and include it in a v17. Or if you get yours merged to drm-misc/drm-misc-next I >>>> can build on top. >>> >>> You can add it in your v17 patchset with my authorship and my Signed-off-by tag + yours. >>> >>> As commit message something like : >>> ==================== >>> drm/bridge: dw-hdmi: handle unusable or non-configured CSC module >>> >>> The dw-hdmi integrates an optional Color Space Conversion feature used >>> to handle color-space conversions. >>> >>> On some platforms, the CSC isn't built-in or non-functional. >>> >>> This adds the necessary code to disable the CSC functionality >>> and limit the bus format negotiation to force using the same >>> input bus format as the output bus format. >>> ==================== >> >> Fine! Will do. > > I was a little too early. > > While preparing the patches I found that I still had the hack to force > sink_is_hdmi = false in my test branch. Sorry for that. > > Removing this made the panel go black again, even with your latest > proposal. > > So I looked deeper into your patch and it seems to influence the > input formats only in dw_hdmi_bridge_atomic_get_input_bus_fmts()? > > While the problem I see is with output formats and we had worked on > modifying dw_hdmi_bridge_atomic_get_output_bus_fmts(). I just looked and the ingenic drm driver first bridge uses drm_atomic_helper_bridge_propagate_bus_fmt() which is why this last patch doesn't work, and perhaps would be the main issue here. Indeed, the core will loop on all the possible output formats for your HDMI monitor : - MEDIA_BUS_FMT_UYVY8_1X16 - MEDIA_BUS_FMT_YUV8_1X24 - MEDIA_BUS_FMT_RGB888_1X24 For each of these, the dw-hdmi dw_hdmi_bridge_atomic_get_input_bus_fmts() will return the same format + the possible CSC transformations, for example for MEDIA_BUS_FMT_UYVY8_1X16 will return as possible inputs: - MEDIA_BUS_FMT_UYVY8_1X16 - MEDIA_BUS_FMT_YUV8_1X24 - MEDIA_BUS_FMT_RGB888_1X24 The the core will call for each of the those the .atomic_get_input_bus_fmts of the Ingenic DRM driver, but by using drm_atomic_helper_bridge_propagate_bus_fmt() it basically sets a pass-through and accepts any format. This is why MEDIA_BUS_FMT_UYVY8_1X16 is selected, but in this case the ingenic ingenic_drm_bridge_atomic_check() would fail in the switch. The Ingenic should implement a proper .atomic_get_input_bus_fmts returning only the possible supported formats. Can you check if you hit the default case in ingenic_drm_bridge_atomic_check() ? Neil > > BR and thanks, > Nikolaus >
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 43e375da131e8..c08e2cc96584c 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -2621,11 +2621,13 @@ static u32 *dw_hdmi_bridge_atomic_get_output_bus_fmts(struct drm_bridge *bridge, output_fmts[i++] = MEDIA_BUS_FMT_RGB101010_1X30; } - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) - output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; + if (max_bpc >= 8 && info->bpc >= 8) { + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR422) + output_fmts[i++] = MEDIA_BUS_FMT_UYVY8_1X16; - if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) - output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; + if (info->color_formats & DRM_COLOR_FORMAT_YCBCR444) + output_fmts[i++] = MEDIA_BUS_FMT_YUV8_1X24; + } /* Default 8bit RGB fallback */ output_fmts[i++] = MEDIA_BUS_FMT_RGB888_1X24;
Commit 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") introduced a new mechanism to negotiate bus formats between hdmi connectors and bridges which is to be used e.g. for the jz4780 based CI20 board. In this case dw-hdmi sets up a list of formats in dw_hdmi_bridge_atomic_get_output_bus_fmts(). This includes e.g. MEDIA_BUS_FMT_UYVY8_1X16 which is chosen for the CI20 but only produces a black screen. Analysis revealed an omission in Commit 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") to check for 8 bit with when adding UYVY8 or YUV8 formats. This fix is based on the observation that max_bpc = 0 when running this function while info->bpc = 8. Adding the proposed patch makes the jz4780/CI20 panel work again with default MEDIA_BUS_FMT_RGB888_1X24 mode. Fixes: 7cd70656d1285b ("drm/bridge: display-connector: implement bus fmts callbacks") Fixes: 6c3c719936dafe ("drm/bridge: synopsys: dw-hdmi: add bus format negociation") Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> --- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)