| Message ID | 1549022873-40549-2-git-send-email-narmstrong@baylibre.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | drm/meson: Add support for HDMI2.0 4k60 | expand |
On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS > Scrambling when supported or mandatory. > > This patch also adds an helper to setup the control bit to support > the high TMDS Bit Period/TMDS Clock-Period Ratio as required with > TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. > > These changes were based on work done by Huicong Xu <xhc@rock-chips.com> > and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes > on the Rockchip 4.4 BSP kernel at [1] > > [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > > Cc: Nickey Yang <nickey.yang@rock-chips.com> > Cc: Huicong Xu <xhc@rock-chips.com> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > Tested-by: Heiko Stuebner <heiko@sntech.de> > Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> > --- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 ++++++++++++++++++++++++++++++- > drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + > include/drm/bridge/dw_hdmi.h | 1 + > 3 files changed, 85 insertions(+), 2 deletions(-) This commit in drm-misc-next is breaking booting on the Rock960. I have FB and fbcon enabled. The boot hangs after this message: [ 3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 kvaddr=(____ptrval____) offset=0 size=8294400 Rob
Hi Rob, On 08/03/2019 00:13, Rob Herring wrote: > On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >> >> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS >> Scrambling when supported or mandatory. >> >> This patch also adds an helper to setup the control bit to support >> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with >> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. >> >> These changes were based on work done by Huicong Xu <xhc@rock-chips.com> >> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes >> on the Rockchip 4.4 BSP kernel at [1] >> >> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 >> >> Cc: Nickey Yang <nickey.yang@rock-chips.com> >> Cc: Huicong Xu <xhc@rock-chips.com> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >> Tested-by: Heiko Stuebner <heiko@sntech.de> >> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> >> --- >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 ++++++++++++++++++++++++++++++- >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + >> include/drm/bridge/dw_hdmi.h | 1 + >> 3 files changed, 85 insertions(+), 2 deletions(-) > > This commit in drm-misc-next is breaking booting on the Rock960. I > have FB and fbcon enabled. The boot hangs after this message: > > [ 3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > kvaddr=(____ptrval____) offset=0 size=8294400 Could you give more details on the tree used ? did you bisect to find this commit ? Neil > > Rob >
On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > Hi Rob, > > On 08/03/2019 00:13, Rob Herring wrote: > > On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >> > >> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS > >> Scrambling when supported or mandatory. > >> > >> This patch also adds an helper to setup the control bit to support > >> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with > >> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. > >> > >> These changes were based on work done by Huicong Xu <xhc@rock-chips.com> > >> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes > >> on the Rockchip 4.4 BSP kernel at [1] > >> > >> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > >> > >> Cc: Nickey Yang <nickey.yang@rock-chips.com> > >> Cc: Huicong Xu <xhc@rock-chips.com> > >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > >> Tested-by: Heiko Stuebner <heiko@sntech.de> > >> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> > >> --- > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 ++++++++++++++++++++++++++++++- > >> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + > >> include/drm/bridge/dw_hdmi.h | 1 + > >> 3 files changed, 85 insertions(+), 2 deletions(-) > > > > This commit in drm-misc-next is breaking booting on the Rock960. I > > have FB and fbcon enabled. The boot hangs after this message: > > > > [ 3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > > kvaddr=(____ptrval____) offset=0 size=8294400 > > Could you give more details on the tree used ? did you bisect to find this commit ? As I said above, drm-misc-next (from drm-misc tree) is the branch. I bisected between it and v5.0. Reverting it fixes booting. Rob
On 08/03/2019 15:54, Rob Herring wrote: > On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >> >> Hi Rob, >> >> On 08/03/2019 00:13, Rob Herring wrote: >>> On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >>>> >>>> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS >>>> Scrambling when supported or mandatory. >>>> >>>> This patch also adds an helper to setup the control bit to support >>>> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with >>>> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. >>>> >>>> These changes were based on work done by Huicong Xu <xhc@rock-chips.com> >>>> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes >>>> on the Rockchip 4.4 BSP kernel at [1] >>>> >>>> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 >>>> >>>> Cc: Nickey Yang <nickey.yang@rock-chips.com> >>>> Cc: Huicong Xu <xhc@rock-chips.com> >>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >>>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> >>>> --- >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 ++++++++++++++++++++++++++++++- >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + >>>> include/drm/bridge/dw_hdmi.h | 1 + >>>> 3 files changed, 85 insertions(+), 2 deletions(-) >>> >>> This commit in drm-misc-next is breaking booting on the Rock960. I >>> have FB and fbcon enabled. The boot hangs after this message: >>> >>> [ 3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 >>> kvaddr=(____ptrval____) offset=0 size=8294400 >> >> Could you give more details on the tree used ? did you bisect to find this commit ? > > As I said above, drm-misc-next (from drm-misc tree) is the branch. I > bisected between it and v5.0. Reverting it fixes booting. Thanks, could you give more details on the environment ? Did you test over the latest linux-next ? Can you share the EDID of your monitor ? Can you check this patch : ----><---------------------------------------------------------------------------------------- diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index a63e5f0dae56..f33c2ac158c1 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -1268,8 +1268,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi) dw_hdmi_phy_power_off(hdmi); - dw_hdmi_set_high_tmds_clock_ratio(hdmi); - /* Leave low power consumption mode by asserting SVSRET. */ if (phy->has_svsret) dw_hdmi_phy_enable_svsret(hdmi, 1);
On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > > On 08/03/2019 15:54, Rob Herring wrote: > > On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >> > >> Hi Rob, > >> > >> On 08/03/2019 00:13, Rob Herring wrote: > >>> On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >>>> > >>>> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS > >>>> Scrambling when supported or mandatory. > >>>> > >>>> This patch also adds an helper to setup the control bit to support > >>>> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with > >>>> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. > >>>> > >>>> These changes were based on work done by Huicong Xu <xhc@rock-chips.com> > >>>> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes > >>>> on the Rockchip 4.4 BSP kernel at [1] > >>>> > >>>> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > >>>> > >>>> Cc: Nickey Yang <nickey.yang@rock-chips.com> > >>>> Cc: Huicong Xu <xhc@rock-chips.com> > >>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > >>>> Tested-by: Heiko Stuebner <heiko@sntech.de> > >>>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> > >>>> --- > >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 ++++++++++++++++++++++++++++++- > >>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + > >>>> include/drm/bridge/dw_hdmi.h | 1 + > >>>> 3 files changed, 85 insertions(+), 2 deletions(-) > >>> > >>> This commit in drm-misc-next is breaking booting on the Rock960. I > >>> have FB and fbcon enabled. The boot hangs after this message: > >>> > >>> [ 3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > >>> kvaddr=(____ptrval____) offset=0 size=8294400 > >> > >> Could you give more details on the tree used ? did you bisect to find this commit ? > > > > As I said above, drm-misc-next (from drm-misc tree) is the branch. I > > bisected between it and v5.0. Reverting it fixes booting. > > Thanks, could you give more details on the environment ? Did you test over the latest linux-next ? Here's a log of the drm parts: https://pastebin.com/tFJ9Gs6h linux-next also hangs. > Can you share the EDID of your monitor ? Maybe not mode related. I tried forcing to 1280x720 and it hangs too. In any case, here's the parsed EDID: 256-byte EDID successfully retrieved from i2c bus 3 Looks like i2c was successful. Have a good day. Checksum Correct Section "Monitor" Identifier "CYS-R101" ModelName "CYS-R101" VendorName "CYX" # Monitor Manufactured week 28 of 2018 # EDID version 1.3 # Digital Display DisplaySize 220 130 Gamma 2.20 Option "DPMS" "true" Horizsync 30-102 VertRefresh 48-75 # Maximum pixel clock is 190MHz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1920x1080, 60Hz #Not giving standard mode: 1440x900, 60Hz #Not giving standard mode: 1400x1050, 60Hz #Not giving standard mode: 1280x1024, 60Hz #Not giving standard mode: 1280x960, 60Hz #Not giving standard mode: 1280x720, 60Hz #Extension block found. Parsing... Modeline "Mode 5" 54.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync +vsync Modeline "Mode 0" 267.81 2560 2608 2640 2720 1600 1603 1608 1641 +hsync +vsync Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync Modeline "Mode 2" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 +hsync +vsync interlace Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync Modeline "Mode 4" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync Option "PreferredMode" "Mode 5" EndSection > Can you check this patch : Still hangs with it. > > ----><---------------------------------------------------------------------------------------- > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > index a63e5f0dae56..f33c2ac158c1 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c > @@ -1268,8 +1268,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi) > > dw_hdmi_phy_power_off(hdmi); > > - dw_hdmi_set_high_tmds_clock_ratio(hdmi); > - > /* Leave low power consumption mode by asserting SVSRET. */ > if (phy->has_svsret) > dw_hdmi_phy_enable_svsret(hdmi, 1); > >
Hi Rob, Le 14/03/2019 19:55, Rob Herring a écrit : > On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >> >> On 08/03/2019 15:54, Rob Herring wrote: >>> On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >>>> >>>> Hi Rob, >>>> >>>> On 08/03/2019 00:13, Rob Herring wrote: >>>>> On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong <narmstrong@baylibre.com> wrote: >>>>>> >>>>>> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS >>>>>> Scrambling when supported or mandatory. >>>>>> >>>>>> This patch also adds an helper to setup the control bit to support >>>>>> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with >>>>>> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. >>>>>> >>>>>> These changes were based on work done by Huicong Xu <xhc@rock-chips.com> >>>>>> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes >>>>>> on the Rockchip 4.4 BSP kernel at [1] >>>>>> >>>>>> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 >>>>>> >>>>>> Cc: Nickey Yang <nickey.yang@rock-chips.com> >>>>>> Cc: Huicong Xu <xhc@rock-chips.com> >>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> >>>>>> Tested-by: Heiko Stuebner <heiko@sntech.de> >>>>>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> >>>>>> --- >>>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 ++++++++++++++++++++++++++++++- >>>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + >>>>>> include/drm/bridge/dw_hdmi.h | 1 + >>>>>> 3 files changed, 85 insertions(+), 2 deletions(-) >>>>> >>>>> This commit in drm-misc-next is breaking booting on the Rock960. I >>>>> have FB and fbcon enabled. The boot hangs after this message: >>>>> >>>>> [ 3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 >>>>> kvaddr=(____ptrval____) offset=0 size=8294400 >>>> >>>> Could you give more details on the tree used ? did you bisect to find this commit ? >>> >>> As I said above, drm-misc-next (from drm-misc tree) is the branch. I >>> bisected between it and v5.0. Reverting it fixes booting. >> >> Thanks, could you give more details on the environment ? Did you test over the latest linux-next ? > > Here's a log of the drm parts: https://pastebin.com/tFJ9Gs6h > > linux-next also hangs. > >> Can you share the EDID of your monitor ? > > Maybe not mode related. I tried forcing to 1280x720 and it hangs too. > In any case, here's the parsed EDID: > > 256-byte EDID successfully retrieved from i2c bus 3 > Looks like i2c was successful. Have a good day. > Checksum Correct > > Section "Monitor" > Identifier "CYS-R101" > ModelName "CYS-R101" > VendorName "CYX" > # Monitor Manufactured week 28 of 2018 > # EDID version 1.3 > # Digital Display > DisplaySize 220 130 > Gamma 2.20 > Option "DPMS" "true" > Horizsync 30-102 > VertRefresh 48-75 > # Maximum pixel clock is 190MHz > #Not giving standard mode: 1920x1080, 60Hz > #Not giving standard mode: 1920x1080, 60Hz > #Not giving standard mode: 1920x1080, 60Hz > #Not giving standard mode: 1440x900, 60Hz > #Not giving standard mode: 1400x1050, 60Hz > #Not giving standard mode: 1280x1024, 60Hz > #Not giving standard mode: 1280x960, 60Hz > #Not giving standard mode: 1280x720, 60Hz > > #Extension block found. Parsing... > Modeline "Mode 5" 54.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync +vsync > Modeline "Mode 0" 267.81 2560 2608 2640 2720 1600 1603 1608 1641 +hsync +vsync > Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync > Modeline "Mode 2" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 > +hsync +vsync interlace > Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync > Modeline "Mode 4" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync > Option "PreferredMode" "Mode 5" > EndSection > >> Can you check this patch : > > Still hangs with it. Thanks for testing, the only impact would be if hdmi_info->scdc.supported and hdmi_info->scdc.scrambling.low_rate were true. Honestly, hdmi_info->scdc.scrambling.low_rate wasn't really tested. Could you dump the edid in binary format ? or parse it with https://github.com/rpavlik/edid-decode supporting modern HDMI EDIDs. Thanks, Neil > >> >> ----><---------------------------------------------------------------------------------------- >> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> index a63e5f0dae56..f33c2ac158c1 100644 >> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c >> @@ -1268,8 +1268,6 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi) >> >> dw_hdmi_phy_power_off(hdmi); >> >> - dw_hdmi_set_high_tmds_clock_ratio(hdmi); >> - >> /* Leave low power consumption mode by asserting SVSRET. */ >> if (phy->has_svsret) >> dw_hdmi_phy_enable_svsret(hdmi, 1); >> >>
On Thu, Mar 14, 2019 at 3:07 PM Neil Armstrong <narmstrong@baylibre.com> wrote: > > Hi Rob, > > Le 14/03/2019 19:55, Rob Herring a écrit : > > On Mon, Mar 11, 2019 at 3:53 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >> > >> On 08/03/2019 15:54, Rob Herring wrote: > >>> On Fri, Mar 8, 2019 at 2:05 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >>>> > >>>> Hi Rob, > >>>> > >>>> On 08/03/2019 00:13, Rob Herring wrote: > >>>>> On Fri, Feb 1, 2019 at 6:08 AM Neil Armstrong <narmstrong@baylibre.com> wrote: > >>>>>> > >>>>>> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS > >>>>>> Scrambling when supported or mandatory. > >>>>>> > >>>>>> This patch also adds an helper to setup the control bit to support > >>>>>> the high TMDS Bit Period/TMDS Clock-Period Ratio as required with > >>>>>> TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes. > >>>>>> > >>>>>> These changes were based on work done by Huicong Xu <xhc@rock-chips.com> > >>>>>> and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes > >>>>>> on the Rockchip 4.4 BSP kernel at [1] > >>>>>> > >>>>>> [1] https://github.com/rockchip-linux/kernel/tree/release-4.4 > >>>>>> > >>>>>> Cc: Nickey Yang <nickey.yang@rock-chips.com> > >>>>>> Cc: Huicong Xu <xhc@rock-chips.com> > >>>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> > >>>>>> Tested-by: Heiko Stuebner <heiko@sntech.de> > >>>>>> Reviewed-by: Andrzej Hajda <a.hajda@samsung.com> > >>>>>> --- > >>>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 85 ++++++++++++++++++++++++++++++- > >>>>>> drivers/gpu/drm/bridge/synopsys/dw-hdmi.h | 1 + > >>>>>> include/drm/bridge/dw_hdmi.h | 1 + > >>>>>> 3 files changed, 85 insertions(+), 2 deletions(-) > >>>>> > >>>>> This commit in drm-misc-next is breaking booting on the Rock960. I > >>>>> have FB and fbcon enabled. The boot hangs after this message: > >>>>> > >>>>> [ 3.012334] [drm:rockchip_drm_fbdev_create] FB [1920x1080]-24 > >>>>> kvaddr=(____ptrval____) offset=0 size=8294400 > >>>> > >>>> Could you give more details on the tree used ? did you bisect to find this commit ? > >>> > >>> As I said above, drm-misc-next (from drm-misc tree) is the branch. I > >>> bisected between it and v5.0. Reverting it fixes booting. > >> > >> Thanks, could you give more details on the environment ? Did you test over the latest linux-next ? > > > > Here's a log of the drm parts: https://pastebin.com/tFJ9Gs6h > > > > linux-next also hangs. > > > >> Can you share the EDID of your monitor ? > > > > Maybe not mode related. I tried forcing to 1280x720 and it hangs too. > > In any case, here's the parsed EDID: > > > > 256-byte EDID successfully retrieved from i2c bus 3 > > Looks like i2c was successful. Have a good day. > > Checksum Correct > > > > Section "Monitor" > > Identifier "CYS-R101" > > ModelName "CYS-R101" > > VendorName "CYX" > > # Monitor Manufactured week 28 of 2018 > > # EDID version 1.3 > > # Digital Display > > DisplaySize 220 130 > > Gamma 2.20 > > Option "DPMS" "true" > > Horizsync 30-102 > > VertRefresh 48-75 > > # Maximum pixel clock is 190MHz > > #Not giving standard mode: 1920x1080, 60Hz > > #Not giving standard mode: 1920x1080, 60Hz > > #Not giving standard mode: 1920x1080, 60Hz > > #Not giving standard mode: 1440x900, 60Hz > > #Not giving standard mode: 1400x1050, 60Hz > > #Not giving standard mode: 1280x1024, 60Hz > > #Not giving standard mode: 1280x960, 60Hz > > #Not giving standard mode: 1280x720, 60Hz > > > > #Extension block found. Parsing... > > Modeline "Mode 5" 54.00 2560 2608 2640 2720 1440 1443 1448 1481 +hsync +vsync > > Modeline "Mode 0" 267.81 2560 2608 2640 2720 1600 1603 1608 1641 +hsync +vsync > > Modeline "Mode 1" 148.500 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync > > Modeline "Mode 2" 74.250 1920 2008 2052 2200 1080 1082 1087 1125 > > +hsync +vsync interlace > > Modeline "Mode 3" 74.250 1280 1390 1420 1650 720 725 730 750 +hsync +vsync > > Modeline "Mode 4" 148.500 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync > > Option "PreferredMode" "Mode 5" > > EndSection > > > >> Can you check this patch : > > > > Still hangs with it. > > > Thanks for testing, the only impact would be if hdmi_info->scdc.supported > and hdmi_info->scdc.scrambling.low_rate were true. > Honestly, hdmi_info->scdc.scrambling.low_rate wasn't really tested. > > Could you dump the edid in binary format ? or parse it with https://github.com/rpavlik/edid-decode > supporting modern HDMI EDIDs. Here's with edid-decode: EDID version: 1.3 Manufacturer: CYX Model 101 Serial Number 16843009 Made in week 28 of 2018 Digital display Maximum image size: 22 cm x 13 cm Gamma: 2.20 DPMS levels: Off Undefined display color type Default (sRGB) color space is primary color space First detailed timing is preferred timing Display x,y Chromaticity: Red: 0.6455, 0.3300 Green: 0.3095, 0.6171 Blue: 0.1523, 0.0732 White: 0.3134, 0.3291 Established timings supported: 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz 800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz 1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz Standard timings supported: 1920x1080@60Hz 16:9 1920x1080@60Hz 16:9 1920x1080@60Hz 16:9 1440x900@60Hz 16:10 HorFreq: 55500 Hz Clock: 88.750 MHz 1400x1050@60Hz 4:3 HorFreq: 64700 Hz Clock: 101.000 MHz 1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz 1280x960@60Hz 4:3 HorFreq: 60000 Hz Clock: 108.000 MHz 1280x720@60Hz 16:9 Detailed mode: Clock 267.810 MHz, 220 mm x 130 mm 2560 2608 2640 2720 hborder 0 1600 1603 1608 1641 vborder 0 +hsync +vsync VertFreq: 59 Hz, HorFreq: 98459 Hz Monitor name: CYS-R101 Serial number: Monitor ranges (bare limits): 48-75Hz V, 30-102kHz H, max dotclock 190MHz Has 1 extension blocks Checksum: 0x8b (valid) CTA extension block Extension version: 3 58 bytes of CTA data Video data block VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz VIC 4 1280x720@60Hz 16:9 HorFreq: 45000 Hz Clock: 74.250 MHz VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz Audio data block Linear PCM, max channels 2 Supported sample rates (kHz): 48 44.1 32 Supported sample sizes (bits): 24 20 16 Speaker allocation data block Speaker map: FL/FR - Front Left/Right Vendor-specific data block, OUI 000c03 (HDMI) Source physical address 1.0.0.0 DC_36bit DC_30bit DC_Y444 Maximum TMDS clock: 340MHz Vendor-specific data block, OUI c45dd8 (HDMI Forum) Version: 1 Maximum TMDS Character Rate: 340MHz SCDC Present Supports 10-bits/component Deep Color 4:2:0 Pixel Encoding Vendor-specific data block, OUI 00001a Extended tag: YCbCr 4:2:0 capability map data block VSD Index 17 VSD Index 18 Extended tag: Colorimetry data block BT2020YCC BT2020RGB Extended tag: Video capability data block YCbCr quantization: Selectable (via AVI YQ) (1) RGB quantization: Selectable (via AVI Q) (1) PT scan behaviour: Support both over- and underscan (3) IT scan behaviour: Support both over- and underscan (3) CE scan behaviour: Support both over- and underscan (3) Extended tag: HDR static metadata data block Electro optical transfer functions: Traditional gamma - SDR luminance range SMPTE ST2084 Supported static metadata descriptors: Static metadata type 1 Desired content max luminance: 89 (343.724 cd/m^2) Desired content max frame-average luminance: 89 (343.724 cd/m^2) Desired content min luminance: 73 (0.282 cd/m^2) Underscans PC formats by default Basic audio support Supports YCbCr 4:4:4 Supports YCbCr 4:2:2 1 native detailed modes Detailed mode: Clock 54.000 MHz, 220 mm x 130 mm 2560 2608 2640 2720 hborder 0 1440 1443 1448 1481 vborder 0 +hsync +vsync side by side interleaved VertFreq: 13 Hz, HorFreq: 19852 Hz Checksum: 0x3c (valid)
Hi Rob, On 14/03/2019 21:14, Rob Herring wrote: > On Thu, Mar 14, 2019 at 3:07 PM Neil Armstrong <narmstrong@baylibre.com> wrote: >> [...] > > Here's with edid-decode: > > EDID version: 1.3 > Manufacturer: CYX Model 101 Serial Number 16843009 > Made in week 28 of 2018 > Digital display > Maximum image size: 22 cm x 13 cm > Gamma: 2.20 > DPMS levels: Off > Undefined display color type > Default (sRGB) color space is primary color space > First detailed timing is preferred timing > Display x,y Chromaticity: > Red: 0.6455, 0.3300 > Green: 0.3095, 0.6171 > Blue: 0.1523, 0.0732 > White: 0.3134, 0.3291 > Established timings supported: > 640x480@60Hz 4:3 HorFreq: 31469 Hz Clock: 25.175 MHz > 800x600@60Hz 4:3 HorFreq: 37900 Hz Clock: 40.000 MHz > 1024x768@60Hz 4:3 HorFreq: 48400 Hz Clock: 65.000 MHz > Standard timings supported: > 1920x1080@60Hz 16:9 > 1920x1080@60Hz 16:9 > 1920x1080@60Hz 16:9 > 1440x900@60Hz 16:10 HorFreq: 55500 Hz Clock: 88.750 MHz > 1400x1050@60Hz 4:3 HorFreq: 64700 Hz Clock: 101.000 MHz > 1280x1024@60Hz 5:4 HorFreq: 64000 Hz Clock: 108.000 MHz > 1280x960@60Hz 4:3 HorFreq: 60000 Hz Clock: 108.000 MHz > 1280x720@60Hz 16:9 > Detailed mode: Clock 267.810 MHz, 220 mm x 130 mm > 2560 2608 2640 2720 hborder 0 > 1600 1603 1608 1641 vborder 0 > +hsync +vsync > VertFreq: 59 Hz, HorFreq: 98459 Hz > Monitor name: CYS-R101 > Serial number: > Monitor ranges (bare limits): 48-75Hz V, 30-102kHz H, max dotclock 190MHz > Has 1 extension blocks > Checksum: 0x8b (valid) > > CTA extension block > Extension version: 3 > 58 bytes of CTA data > Video data block > VIC 16 1920x1080@60Hz 16:9 HorFreq: 67500 Hz Clock: 148.500 MHz > VIC 5 1920x1080i@60Hz 16:9 HorFreq: 33750 Hz Clock: 74.250 MHz > VIC 4 1280x720@60Hz 16:9 HorFreq: 45000 Hz Clock: 74.250 MHz > VIC 31 1920x1080@50Hz 16:9 HorFreq: 56250 Hz Clock: 148.500 MHz > Audio data block > Linear PCM, max channels 2 > Supported sample rates (kHz): 48 44.1 32 > Supported sample sizes (bits): 24 20 16 > Speaker allocation data block > Speaker map: > FL/FR - Front Left/Right > Vendor-specific data block, OUI 000c03 (HDMI) > Source physical address 1.0.0.0 > DC_36bit > DC_30bit > DC_Y444 > Maximum TMDS clock: 340MHz > Vendor-specific data block, OUI c45dd8 (HDMI Forum) > Version: 1 > Maximum TMDS Character Rate: 340MHz > SCDC Present > Supports 10-bits/component Deep Color 4:2:0 Pixel Encoding > Vendor-specific data block, OUI 00001a > Extended tag: YCbCr 4:2:0 capability map data block > VSD Index 17 > VSD Index 18 > Extended tag: Colorimetry data block > BT2020YCC > BT2020RGB > Extended tag: Video capability data block > YCbCr quantization: Selectable (via AVI YQ) (1) > RGB quantization: Selectable (via AVI Q) (1) > PT scan behaviour: Support both over- and underscan (3) > IT scan behaviour: Support both over- and underscan (3) > CE scan behaviour: Support both over- and underscan (3) > Extended tag: HDR static metadata data block > Electro optical transfer functions: > Traditional gamma - SDR luminance range > SMPTE ST2084 > Supported static metadata descriptors: > Static metadata type 1 > Desired content max luminance: 89 (343.724 cd/m^2) > Desired content max frame-average luminance: 89 (343.724 cd/m^2) > Desired content min luminance: 73 (0.282 cd/m^2) > Underscans PC formats by default > Basic audio support > Supports YCbCr 4:4:4 > Supports YCbCr 4:2:2 > 1 native detailed modes > Detailed mode: Clock 54.000 MHz, 220 mm x 130 mm > 2560 2608 2640 2720 hborder 0 > 1440 1443 1448 1481 vborder 0 > +hsync +vsync side by side interleaved > VertFreq: 13 Hz, HorFreq: 19852 Hz > Checksum: 0x3c (valid) > Thanks for the parsed edid. I think we have multiple issues : - This EDID is severely broken, SCDC support doesn't make sense because "Maximum TMDS Character Rate: 340MHz" and "Supports scrambling for <= 340 Mcsc" is not present Same for 4:2:0, the IDs in the "YCbCr 4:2:0 capability map data block" refers to invalid modes 17 & 18 in a mode table containing only 4 entries. - DW-HDMI should not care if SCDC is present, Max TMDS <= 340MHz and low_rates is not present - In any case, the SoC should not freeze in this situation, so either the HDMI_FC_SCRAMBLER_CTRL or HDMI_MC_SWRSTZ writes makes the SoC freeze or the drm_scdc_set_scrambling() containing i2c write fails, anyway this is the root issue. This will need 3 steps : - an entry in the EDID quirk table to disable SCDC and 420 for this monitor - a fix in dw-hdmi to ignore this SCDC setup - an investigation to find why and where the SoC did freeze Rob, could you give the Commercial name of the display for the EDID quirk table ? Thanks, Neil
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c index 7aae726..6d5a2e9 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c @@ -27,6 +27,7 @@ #include <drm/drm_atomic_helper.h> #include <drm/drm_edid.h> #include <drm/drm_encoder_slave.h> +#include <drm/drm_scdc_helper.h> #include <drm/drm_probe_helper.h> #include <drm/bridge/dw_hdmi.h> @@ -43,6 +44,11 @@ #define HDMI_EDID_LEN 512 +/* DW-HDMI Controller >= 0x200a are at least compliant with SCDC version 1 */ +#define SCDC_MIN_SOURCE_VERSION 0x1 + +#define HDMI14_MAX_TMDSCLK 340000000 + enum hdmi_datamap { RGB444_8B = 0x01, RGB444_10B = 0x03, @@ -1015,6 +1021,33 @@ void dw_hdmi_phy_i2c_write(struct dw_hdmi *hdmi, unsigned short data, } EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_write); +/* + * HDMI2.0 Specifies the following procedure for High TMDS Bit Rates: + * - The Source shall suspend transmission of the TMDS clock and data + * - The Source shall write to the TMDS_Bit_Clock_Ratio bit to change it + * from a 0 to a 1 or from a 1 to a 0 + * - The Source shall allow a minimum of 1 ms and a maximum of 100 ms from + * the time the TMDS_Bit_Clock_Ratio bit is written until resuming + * transmission of TMDS clock and data + * + * To respect the 100ms maximum delay, the dw_hdmi_set_high_tmds_clock_ratio() + * helper should called right before enabling the TMDS Clock and Data in + * the PHY configuration callback. + */ +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi) +{ + unsigned long mtmdsclock = hdmi->hdmi_data.video_mode.mpixelclock; + + /* Control for TMDS Bit Period/TMDS Clock-Period Ratio */ + if (hdmi->connector.display_info.hdmi.scdc.supported) { + if (mtmdsclock > HDMI14_MAX_TMDSCLK) + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 1); + else + drm_scdc_set_high_tmds_clock_ratio(hdmi->ddc, 0); + } +} +EXPORT_SYMBOL_GPL(dw_hdmi_set_high_tmds_clock_ratio); + static void dw_hdmi_phy_enable_powerdown(struct dw_hdmi *hdmi, bool enable) { hdmi_mask_writeb(hdmi, !enable, HDMI_PHY_CONF0, @@ -1216,6 +1249,8 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi) dw_hdmi_phy_power_off(hdmi); + dw_hdmi_set_high_tmds_clock_ratio(hdmi); + /* Leave low power consumption mode by asserting SVSRET. */ if (phy->has_svsret) dw_hdmi_phy_enable_svsret(hdmi, 1); @@ -1237,6 +1272,10 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi) return ret; } + /* Wait for resuming transmission of TMDS clock and data */ + if (mpixelclock > HDMI14_MAX_TMDSCLK) + msleep(100); + return dw_hdmi_phy_power_on(hdmi); } @@ -1504,7 +1543,8 @@ static void hdmi_config_vendor_specific_infoframe(struct dw_hdmi *hdmi, static void hdmi_av_composer(struct dw_hdmi *hdmi, const struct drm_display_mode *mode) { - u8 inv_val; + u8 inv_val, bytes; + struct drm_hdmi_info *hdmi_info = &hdmi->connector.display_info.hdmi; struct hdmi_vmode *vmode = &hdmi->hdmi_data.video_mode; int hblank, vblank, h_de_hs, v_de_vs, hsync_len, vsync_len; unsigned int vdisplay; @@ -1514,7 +1554,9 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi, dev_dbg(hdmi->dev, "final pixclk = %d\n", vmode->mpixelclock); /* Set up HDMI_FC_INVIDCONF */ - inv_val = (hdmi->hdmi_data.hdcp_enable ? + inv_val = (hdmi->hdmi_data.hdcp_enable || + vmode->mpixelclock > HDMI14_MAX_TMDSCLK || + hdmi_info->scdc.scrambling.low_rates ? HDMI_FC_INVIDCONF_HDCP_KEEPOUT_ACTIVE : HDMI_FC_INVIDCONF_HDCP_KEEPOUT_INACTIVE); @@ -1563,6 +1605,45 @@ static void hdmi_av_composer(struct dw_hdmi *hdmi, vsync_len /= 2; } + /* Scrambling Control */ + if (hdmi_info->scdc.supported) { + if (vmode->mpixelclock > HDMI14_MAX_TMDSCLK || + hdmi_info->scdc.scrambling.low_rates) { + /* + * HDMI2.0 Specifies the following procedure: + * After the Source Device has determined that + * SCDC_Present is set (=1), the Source Device should + * write the accurate Version of the Source Device + * to the Source Version field in the SCDCS. + * Source Devices compliant shall set the + * Source Version = 1. + */ + drm_scdc_readb(&hdmi->i2c->adap, SCDC_SINK_VERSION, + &bytes); + drm_scdc_writeb(&hdmi->i2c->adap, SCDC_SOURCE_VERSION, + min_t(u8, bytes, SCDC_MIN_SOURCE_VERSION)); + + /* Enabled Scrambling in the Sink */ + drm_scdc_set_scrambling(&hdmi->i2c->adap, 1); + + /* + * To activate the scrambler feature, you must ensure + * that the quasi-static configuration bit + * fc_invidconf.HDCP_keepout is set at configuration + * time, before the required mc_swrstzreq.tmdsswrst_req + * reset request is issued. + */ + hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, + HDMI_MC_SWRSTZ); + hdmi_writeb(hdmi, 1, HDMI_FC_SCRAMBLER_CTRL); + } else { + hdmi_writeb(hdmi, 0, HDMI_FC_SCRAMBLER_CTRL); + hdmi_writeb(hdmi, (u8)~HDMI_MC_SWRSTZ_TMDSSWRST_REQ, + HDMI_MC_SWRSTZ); + drm_scdc_set_scrambling(&hdmi->i2c->adap, 0); + } + } + /* Set up horizontal active pixel width */ hdmi_writeb(hdmi, mode->hdisplay >> 8, HDMI_FC_INHACTV1); hdmi_writeb(hdmi, mode->hdisplay, HDMI_FC_INHACTV0); diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h index 9d90eb9..3f3c616 100644 --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.h @@ -255,6 +255,7 @@ #define HDMI_FC_MASK2 0x10DA #define HDMI_FC_POL2 0x10DB #define HDMI_FC_PRCONF 0x10E0 +#define HDMI_FC_SCRAMBLER_CTRL 0x10E1 #define HDMI_FC_GMD_STAT 0x1100 #define HDMI_FC_GMD_EN 0x1101 diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h index 9f93895..66e7077 100644 --- a/include/drm/bridge/dw_hdmi.h +++ b/include/drm/bridge/dw_hdmi.h @@ -159,6 +159,7 @@ void dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense); void dw_hdmi_set_sample_rate(struct dw_hdmi *hdmi, unsigned int rate); void dw_hdmi_audio_enable(struct dw_hdmi *hdmi); void dw_hdmi_audio_disable(struct dw_hdmi *hdmi); +void dw_hdmi_set_high_tmds_clock_ratio(struct dw_hdmi *hdmi); /* PHY configuration */ void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address);