On 2/24/20 4:07 AM, Maxime Ripard wrote:
static void vc4_hdmi_encoder_enable(struct drm_encoder *encoder)
{
struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
@@ -1314,6 +1438,92 @@ static int vc4_hdmi_init_resources(struct vc4_hdmi
*vc4_hdmi)
return 0;
}
This function fails on my Raspberry Pi 4 running patched 5.6-rc6. The
errors printed to syslog are as follows:
[ 15.167559] vc4-drm gpu: [drm] *ERROR* fbdev: Failed to setup generic
emulation (ret=-22)
[ 46.116273] WARNING: CPU: 2 PID: 1057 at
drivers/gpu/drm/vc4/vc4_hdmi_phy.c:414 vc5_hdmi_phy_init+0x7b4/0x2078 [vc4]
[ 47.127798] Timeout waiting for VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE
[ 47.127865] WARNING: CPU: 1 PID: 1057 at
drivers/gpu/drm/vc4/vc4_hdmi.c:652 vc4_hdmi_encoder_enable+0x1518/0x1e10
[vc4]
[ 47.128353] WARNING: CPU: 1 PID: 1057 at
drivers/gpu/drm/vc4/vc4_hdmi.c:671 vc4_hdmi_encoder_enable+0x18c8/0x1e10
[vc4]
-
Backtrace:
[ 46.116373] pc : vc5_hdmi_phy_init+0x7b4/0x2078 [vc4]
[ 46.116386] lr : vc4_hdmi_encoder_enable+0x1cc/0x1e10 [vc4]
[ 46.116440] vc5_hdmi_phy_init+0x7b4/0x2078 [vc4]
[ 46.116451] vc4_hdmi_encoder_enable+0x1cc/0x1e10 [vc4]
[ 46.116497] vc4_atomic_complete_commit+0x3f0/0x530 [vc4]
[ 46.116508] vc4_atomic_commit+0x1d8/0x1f8 [vc4]
The specific offending conditional (before the warning on line 652)
under vc4_hdmi_encoder_enable() in drm/vc4/vc4_hdmi.c:
645 if (vc4_encoder->hdmi_monitor) {
646 HDMI_WRITE(HDMI_SCHEDULER_CONTROL,
647 HDMI_READ(HDMI_SCHEDULER_CONTROL) |
648 VC4_HDMI_SCHEDULER_CONTROL_MODE_HDMI);
649
650 ret = wait_for(HDMI_READ(HDMI_SCHEDULER_CONTROL) &
651 VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE, 1000);
652 WARN_ONCE(ret, "Timeout waiting for "
653 "VC4_HDMI_SCHEDULER_CONTROL_HDMI_ACTIVE\n");
Which causes vc4_hdmi_encoder_enable() to fail.
The failure of vc5_hdmi_phy_init() earlier left the phy inactive,
causing the encoder enabling function above to fail.
The offending code around line 414 in vc4_hdmi_phy.c, under
vc5_hdmi_phy_init() reads
411 HDMI_WRITE(HDMI_TX_PHY_TMDS_CLK_WORD_SEL, word_sel);
412
413 HDMI_WRITE(HDMI_TX_PHY_CTL_3,
414VC4_SET_FIELD(phy_get_cp_current(vco_freq),
415 VC4_HDMI_TX_PHY_CTL_3_ICP) |
416VC4_SET_FIELD(1, VC4_HDMI_TX_PHY_CTL_3_CP) |
417VC4_SET_FIELD(1, VC4_HDMI_TX_PHY_CTL_3_CP1) |
418VC4_SET_FIELD(3, VC4_HDMI_TX_PHY_CTL_3_CZ) |
419VC4_SET_FIELD(4, VC4_HDMI_TX_PHY_CTL_3_RP) |
420VC4_SET_FIELD(6, VC4_HDMI_TX_PHY_CTL_3_RZ));
As the hdmi-related timeout occurs 30 seconds after the drm failure, I'm
bound to believe that the timeout occurs due to the drm setup failure
leaving nothing for the phy functions to act on.
Earlier in the syslog an error potentially related to the
VC4_SET_FIELD(phy_get_cp_current(vco_freq) failure:
[3.729745] raspberrypi-clk raspberrypi-clk: Missing firmware node
[3.743915] raspberrypi-clk: probe of raspberrypi-clk failed with
error -2
I thought the patch series added the firmware node? Perhaps the bcm2835
clock stub in the bcm2835 common dts is not being imported in the
bcm2711 devicetree?
The result is a connected hdmi monitor has signal from the simple
framebuffer until the failed modeswitch, upon which it loses signal.
I'm looking around for these possibilities in the kernel tree, though I
thought the code worked as it was?
I did have to disable CONFIG_DRM_VC4_HDMI_CEC in Kconfig to get the
patches to compile as another user in linux-arm-kernel discovered the
CEC code relied on removed functions (Jian-Hong Pan).
I still hope these patches can be cleaned up/fixed to make the 5.7 merge
window.
Daniel Rodriguez
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
