The NUC J5005 uses built in Intel UHD Graphics 605 and I have it connected to a ViewSonic VG3448 34 Inch Ultra-Wide 21:9 WQHD. In the kernel config, it is configured as an i915. Short story, the first sign of problems is when the framebuffer is initialized which is followed by the first error:
fbcon: i915drmfb (fb0) is primary device
kernel: i915 0000:00:02.0: [drm] *ERROR* Invalid VCO
kernel: Console: switching to colour frame buffer device 430x90
kernel: i915 0000:00:02.0: [drm] *ERROR* Invalid VCOThere are follow on errors and X will not start. I fought this issue for a couple days then took it to work and try with a plain monitor (small Dell or something). Surprise! It worked perfect, so now I know it is a mismatch with my monitor. WTF?
So, I started with the 5.10.9 kernel and found the “Invalid VCO” is coming from intel_dpll_mgr.c.
static bool bxt_ddi_set_dpll_hw_state(struct intel_crtc_state *crtc_state, const struct bxt_clk_div *clk_div)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
struct intel_dpll_hw_state *dpll_hw_state = &crtc_state->dpll_hw_state;
int clock = crtc_state->port_clock;
int vco = clk_div->vco;
u32 prop_coef, int_coef, gain_ctl, targ_cnt;
u32 lanestagger;
memset(dpll_hw_state, 0, sizeof(*dpll_hw_state));
if (vco >= 6200000 && vco <= 6700000) {
prop_coef = 4;
int_coef = 9;
gain_ctl = 3;
targ_cnt = 8;
} else if ((vco > 5400000 && vco < 6200000) ||
(vco >= 4800000 && vco < 5400000)) {
prop_coef = 5;
int_coef = 11;
gain_ctl = 3;
targ_cnt = 9;
} else if (vco == 5400000) {
prop_coef = 3;
int_coef = 8;
gain_ctl = 1;
targ_cnt = 9;
} else {
drm_err(&i915->drm, "Invalid VCO\n");
return false;
}
...More poking around pointed to the i915 driver not being able to handle the data by monitor reported, so time to file an issue with the i915 driver group. Thanks to Ville Syrjälä who came back with a patch yesterday:
From 83e72257aca3386decb2b9d631c82e62732afd30 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
Date: Tue, 2 Feb 2021 01:16:53 +0200
Subject: [PATCH] drm/i915: Reject 446-480MHz HDMI clock on GLK
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The BXT/GLK DPLL can't generate certain frequencies. We already
reject the 233-240MHz range on both. But on GLK the DPLL max
frequency was bumped from 300MHz to 594MHz, so now we get to
also worry about the 446-480MHz range (double the original
problem range). Reject any frequency within the higher
problematic range as well.
Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 66e1ac3887c6..b593a71e6517 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2218,7 +2218,11 @@ hdmi_port_clock_valid(struct intel_hdmi *hdmi,
has_hdmi_sink))
return MODE_CLOCK_HIGH;
- /* BXT DPLL can't generate 223-240 MHz */
+ /* GLK DPLL can't generate 446-480 MHz */
+ if (IS_GEMINILAKE(dev_priv) && clock > 446666 && clock < 480000)
+ return MODE_CLOCK_RANGE;
+
+ /* BXT/GLK DPLL can't generate 223-240 MHz */
if (IS_GEN9_LP(dev_priv) && clock > 223333 && clock < 240000)
return MODE_CLOCK_RANGE;
--
2.26.2I inserted the patch into the 5.10.12 kernel code and was back in business. The down side is I’ll have to remember to keep patching until it makes it into the kernel sources proper.
