| Message ID | 20171220105017.11259-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi, On 20-12-17 15:04, Ville Syrjälä wrote: > On Wed, Dec 20, 2017 at 11:50:17AM +0100, Hans de Goede wrote: >> At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image >> shifted aprox. 20% to the left (with wraparound) and sometimes also wrong >> colors, showing that the panel controller is starting with sampling the >> datastream somewhere mid-line. This happens after the first blanking and >> re-init of the panel. >> >> After looking at drm.debug output I noticed that initially we inherit the >> cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667 >> KHz, which turns out to be the cause of this problem, a quick hack to hard >> code the cdclk to 333333 KHz makes the problem go away. >> >> I've tested this on various Bay Trail devices, to make sure this not >> causes regressions on other devices and the higher cdclk does not cause >> any problems on the following devices: >> -GP-electronic T701 1024x600 333333 KHz cdclk after this patch >> -PEAQ C1010 1920x1200 333333 KHz cdclk after this patch >> -PoV mobii-wintab-800w 800x1280 333333 KHz cdclk after this patch >> -Asus Transformer-T100TA 1368x768 320000 KHz cdclk after this patch >> >> Also interesting wrt this is the comment in vlv_calc_cdclk about the >> existing workaround to avoid 200 Mhz as clock because that causes issues >> in some cases. > > IIRC the 200 MHz clock never worked on any machine/display. > >> >> This commit extends the "do not use 200 Mhz" workaround with an extra >> check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI >> panel is active. >> >> Changes in v2: >> -Change the commit message and the code comment to not treat the GOP as >> a reference, the GOP should not be treated as a reference >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> drivers/gpu/drm/i915/intel_cdclk.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c >> index 9c5ceb98d48f..a15976f55f47 100644 >> --- a/drivers/gpu/drm/i915/intel_cdclk.c >> +++ b/drivers/gpu/drm/i915/intel_cdclk.c >> @@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) >> if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9) >> min_cdclk = max(2 * 96000, min_cdclk); >> >> + /* >> + * On Valleyview some DSI panels loose (v|h)sync when the clock is lower > > s/loose/lose/ > > My VLV+DSI tablet is happy with the 266 MHz cdclk, so it's a little > disappointing to apply this to all such machines. But unless someone > can come up with a better workaround I think this will have to do. > > Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Thank you, I've just pushed this to dinq with your acked-by and the spelling error corrected. Regards, Hans >> + * then 320000KHz. >> + */ >> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) && >> + IS_VALLEYVIEW(dev_priv)) >> + min_cdclk = max(320000, min_cdclk); >> + >> if (min_cdclk > dev_priv->max_cdclk_freq) { >> DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n", >> min_cdclk, dev_priv->max_cdclk_freq); >> -- >> 2.14.3 >
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c b/drivers/gpu/drm/i915/intel_cdclk.c index 9c5ceb98d48f..a15976f55f47 100644 --- a/drivers/gpu/drm/i915/intel_cdclk.c +++ b/drivers/gpu/drm/i915/intel_cdclk.c @@ -1923,6 +1923,14 @@ int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state) if (crtc_state->has_audio && INTEL_GEN(dev_priv) >= 9) min_cdclk = max(2 * 96000, min_cdclk); + /* + * On Valleyview some DSI panels loose (v|h)sync when the clock is lower + * then 320000KHz. + */ + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DSI) && + IS_VALLEYVIEW(dev_priv)) + min_cdclk = max(320000, min_cdclk); + if (min_cdclk > dev_priv->max_cdclk_freq) { DRM_DEBUG_KMS("required cdclk (%d kHz) exceeds max (%d kHz)\n", min_cdclk, dev_priv->max_cdclk_freq);
At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image shifted aprox. 20% to the left (with wraparound) and sometimes also wrong colors, showing that the panel controller is starting with sampling the datastream somewhere mid-line. This happens after the first blanking and re-init of the panel. After looking at drm.debug output I noticed that initially we inherit the cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667 KHz, which turns out to be the cause of this problem, a quick hack to hard code the cdclk to 333333 KHz makes the problem go away. I've tested this on various Bay Trail devices, to make sure this not causes regressions on other devices and the higher cdclk does not cause any problems on the following devices: -GP-electronic T701 1024x600 333333 KHz cdclk after this patch -PEAQ C1010 1920x1200 333333 KHz cdclk after this patch -PoV mobii-wintab-800w 800x1280 333333 KHz cdclk after this patch -Asus Transformer-T100TA 1368x768 320000 KHz cdclk after this patch Also interesting wrt this is the comment in vlv_calc_cdclk about the existing workaround to avoid 200 Mhz as clock because that causes issues in some cases. This commit extends the "do not use 200 Mhz" workaround with an extra check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI panel is active. Changes in v2: -Change the commit message and the code comment to not treat the GOP as a reference, the GOP should not be treated as a reference Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/gpu/drm/i915/intel_cdclk.c | 8 ++++++++ 1 file changed, 8 insertions(+)