* Fixes that failed to apply to v5.0-rc5
@ 2019-02-05 13:42 Jani Nikula
2019-02-05 14:18 ` Ville Syrjala
` (3 more replies)
0 siblings, 4 replies; 11+ messages in thread
From: Jani Nikula @ 2019-02-05 13:42 UTC (permalink / raw)
To: intel-gfx
The following commits have been marked as Cc: stable or fixing something
in v5.0-rc5 or earlier, but failed to cherry-pick to
drm-intel-fixes. Please see if they are worth backporting, and please do
so if they are.
Failed to cherry-pick:
b14c06ec0249 ("drm/i915/cnl: Fix CNL macros for Voltage Swing programming")
32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with i965gm TV output")
Cherry-pick fine but fail to build:
7bed8adcd9f8 ("drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen")
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 11+ messages in thread* [PATCH -fixes] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen 2019-02-05 13:42 Fixes that failed to apply to v5.0-rc5 Jani Nikula @ 2019-02-05 14:18 ` Ville Syrjala 2019-02-05 14:23 ` Fixes that failed to apply to v5.0-rc5 Ville Syrjälä ` (2 subsequent siblings) 3 siblings, 0 replies; 11+ messages in thread From: Ville Syrjala @ 2019-02-05 14:18 UTC (permalink / raw) To: intel-gfx; +Cc: stable, Daniel Kamil Kozar From: Ville Syrjälä <ville.syrjala@linux.intel.com> Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS which misprograms the hardware badly when encountering a suitably high resolution display. The programmed pipe timings are somewhat bonkers and the DPLL is totally misprogrammed (P divider == 0). That will result in atomic commit timeouts as apparently the pipe is sufficiently stuck to not signal vblank interrupts. IIRC something like this was also observed on some other SNB machine years ago (might have been a Dell XPS 8300) but a BIOS update cured it. Sadly looks like this was never fixed for the ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still broken. The quickest way to deal with this seems to be to shut down the pipe+ports+DPLL. Unfortunately doing this during the normal sanitization phase isn't quite soon enough as we already spew several WARNs about the bogus hardware state. But it's better than hanging the boot for a few dozen seconds. Since this is limited to a few old machines it doesn't seem entirely worthwile to try and rework the readout+sanitization code to handle it more gracefully. v2: Fix potential NULL deref (kbuild test robot) Constify has_bogus_dpll_config() Cc: stable@vger.kernel.org # v4.20+ Cc: Daniel Kamil Kozar <dkk089@gmail.com> Reported-by: Daniel Kamil Kozar <dkk089@gmail.com> Tested-by: Daniel Kamil Kozar <dkk089@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245 Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111174950.10681-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> (cherry picked from commit 7bed8adcd9f86231bb69bbc02f88ad89330f99e3) --- drivers/gpu/drm/i915/intel_display.c | 50 ++++++++++++++++++++++++---- 1 file changed, 44 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3da9c0f9e948..248128126422 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15415,16 +15415,45 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc, } } +static bool has_bogus_dpll_config(const struct intel_crtc_state *crtc_state) +{ + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev); + + /* + * Some SNB BIOSen (eg. ASUS K53SV) are known to misprogram + * the hardware when a high res displays plugged in. DPLL P + * divider is zero, and the pipe timings are bonkers. We'll + * try to disable everything in that case. + * + * FIXME would be nice to be able to sanitize this state + * without several WARNs, but for now let's take the easy + * road. + */ + return IS_GEN6(dev_priv) && + crtc_state->base.active && + crtc_state->shared_dpll && + crtc_state->port_clock == 0; +} + static void intel_sanitize_encoder(struct intel_encoder *encoder) { struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); struct intel_connector *connector; + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc); + struct intel_crtc_state *crtc_state = crtc ? + to_intel_crtc_state(crtc->base.state) : NULL; /* We need to check both for a crtc link (meaning that the * encoder is active and trying to read from a pipe) and the * pipe itself being active. */ - bool has_active_crtc = encoder->base.crtc && - to_intel_crtc(encoder->base.crtc)->active; + bool has_active_crtc = crtc_state && + crtc_state->base.active; + + if (crtc_state && has_bogus_dpll_config(crtc_state)) { + DRM_DEBUG_KMS("BIOS has misprogrammed the hardware. Disabling pipe %c\n", + pipe_name(crtc->pipe)); + has_active_crtc = false; + } connector = intel_encoder_find_connector(encoder); if (connector && !has_active_crtc) { @@ -15435,16 +15464,25 @@ static void intel_sanitize_encoder(struct intel_encoder *encoder) /* Connector is active, but has no active pipe. This is * fallout from our resume register restoring. Disable * the encoder manually again. */ - if (encoder->base.crtc) { - struct drm_crtc_state *crtc_state = encoder->base.crtc->state; + if (crtc_state) { + struct drm_encoder *best_encoder; DRM_DEBUG_KMS("[ENCODER:%d:%s] manually disabled\n", encoder->base.base.id, encoder->base.name); + + /* avoid oopsing in case the hooks consult best_encoder */ + best_encoder = connector->base.state->best_encoder; + connector->base.state->best_encoder = &encoder->base; + if (encoder->disable) - encoder->disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); + encoder->disable(encoder, crtc_state, + connector->base.state); if (encoder->post_disable) - encoder->post_disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); + encoder->post_disable(encoder, crtc_state, + connector->base.state); + + connector->base.state->best_encoder = best_encoder; } encoder->base.crtc = NULL; -- 2.19.2 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH -fixes] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen @ 2019-02-05 14:18 ` Ville Syrjala 0 siblings, 0 replies; 11+ messages in thread From: Ville Syrjala @ 2019-02-05 14:18 UTC (permalink / raw) To: intel-gfx; +Cc: Daniel Kamil Kozar, stable From: Ville Syrjälä <ville.syrjala@linux.intel.com> Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS which misprograms the hardware badly when encountering a suitably high resolution display. The programmed pipe timings are somewhat bonkers and the DPLL is totally misprogrammed (P divider == 0). That will result in atomic commit timeouts as apparently the pipe is sufficiently stuck to not signal vblank interrupts. IIRC something like this was also observed on some other SNB machine years ago (might have been a Dell XPS 8300) but a BIOS update cured it. Sadly looks like this was never fixed for the ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still broken. The quickest way to deal with this seems to be to shut down the pipe+ports+DPLL. Unfortunately doing this during the normal sanitization phase isn't quite soon enough as we already spew several WARNs about the bogus hardware state. But it's better than hanging the boot for a few dozen seconds. Since this is limited to a few old machines it doesn't seem entirely worthwile to try and rework the readout+sanitization code to handle it more gracefully. v2: Fix potential NULL deref (kbuild test robot) Constify has_bogus_dpll_config() Cc: stable@vger.kernel.org # v4.20+ Cc: Daniel Kamil Kozar <dkk089@gmail.com> Reported-by: Daniel Kamil Kozar <dkk089@gmail.com> Tested-by: Daniel Kamil Kozar <dkk089@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245 Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190111174950.10681-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> (cherry picked from commit 7bed8adcd9f86231bb69bbc02f88ad89330f99e3) --- drivers/gpu/drm/i915/intel_display.c | 50 ++++++++++++++++++++++++---- 1 file changed, 44 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 3da9c0f9e948..248128126422 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15415,16 +15415,45 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc, } } +static bool has_bogus_dpll_config(const struct intel_crtc_state *crtc_state) +{ + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev); + + /* + * Some SNB BIOSen (eg. ASUS K53SV) are known to misprogram + * the hardware when a high res displays plugged in. DPLL P + * divider is zero, and the pipe timings are bonkers. We'll + * try to disable everything in that case. + * + * FIXME would be nice to be able to sanitize this state + * without several WARNs, but for now let's take the easy + * road. + */ + return IS_GEN6(dev_priv) && + crtc_state->base.active && + crtc_state->shared_dpll && + crtc_state->port_clock == 0; +} + static void intel_sanitize_encoder(struct intel_encoder *encoder) { struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); struct intel_connector *connector; + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc); + struct intel_crtc_state *crtc_state = crtc ? + to_intel_crtc_state(crtc->base.state) : NULL; /* We need to check both for a crtc link (meaning that the * encoder is active and trying to read from a pipe) and the * pipe itself being active. */ - bool has_active_crtc = encoder->base.crtc && - to_intel_crtc(encoder->base.crtc)->active; + bool has_active_crtc = crtc_state && + crtc_state->base.active; + + if (crtc_state && has_bogus_dpll_config(crtc_state)) { + DRM_DEBUG_KMS("BIOS has misprogrammed the hardware. Disabling pipe %c\n", + pipe_name(crtc->pipe)); + has_active_crtc = false; + } connector = intel_encoder_find_connector(encoder); if (connector && !has_active_crtc) { @@ -15435,16 +15464,25 @@ static void intel_sanitize_encoder(struct intel_encoder *encoder) /* Connector is active, but has no active pipe. This is * fallout from our resume register restoring. Disable * the encoder manually again. */ - if (encoder->base.crtc) { - struct drm_crtc_state *crtc_state = encoder->base.crtc->state; + if (crtc_state) { + struct drm_encoder *best_encoder; DRM_DEBUG_KMS("[ENCODER:%d:%s] manually disabled\n", encoder->base.base.id, encoder->base.name); + + /* avoid oopsing in case the hooks consult best_encoder */ + best_encoder = connector->base.state->best_encoder; + connector->base.state->best_encoder = &encoder->base; + if (encoder->disable) - encoder->disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); + encoder->disable(encoder, crtc_state, + connector->base.state); if (encoder->post_disable) - encoder->post_disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); + encoder->post_disable(encoder, crtc_state, + connector->base.state); + + connector->base.state->best_encoder = best_encoder; } encoder->base.crtc = NULL; -- 2.19.2 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] [PATCH -fixes] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen 2019-02-05 14:18 ` Ville Syrjala (?) @ 2019-02-06 7:11 ` Jani Nikula -1 siblings, 0 replies; 11+ messages in thread From: Jani Nikula @ 2019-02-06 7:11 UTC (permalink / raw) To: Ville Syrjala, intel-gfx; +Cc: Daniel Kamil Kozar, stable On Tue, 05 Feb 2019, Ville Syrjala <ville.syrjala@linux.intel.com> wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Certain SNB machines (eg. ASUS K53SV) seem to have a broken BIOS > which misprograms the hardware badly when encountering a suitably > high resolution display. The programmed pipe timings are somewhat > bonkers and the DPLL is totally misprogrammed (P divider == 0). > That will result in atomic commit timeouts as apparently the pipe > is sufficiently stuck to not signal vblank interrupts. > > IIRC something like this was also observed on some other SNB > machine years ago (might have been a Dell XPS 8300) but a BIOS > update cured it. Sadly looks like this was never fixed for the > ASUS K53SV as the latest BIOS (K53SV.320 11/11/2011) is still > broken. > > The quickest way to deal with this seems to be to shut down > the pipe+ports+DPLL. Unfortunately doing this during the > normal sanitization phase isn't quite soon enough as we > already spew several WARNs about the bogus hardware state. > But it's better than hanging the boot for a few dozen seconds. > Since this is limited to a few old machines it doesn't seem > entirely worthwile to try and rework the readout+sanitization > code to handle it more gracefully. > > v2: Fix potential NULL deref (kbuild test robot) > Constify has_bogus_dpll_config() > > Cc: stable@vger.kernel.org # v4.20+ > Cc: Daniel Kamil Kozar <dkk089@gmail.com> > Reported-by: Daniel Kamil Kozar <dkk089@gmail.com> > Tested-by: Daniel Kamil Kozar <dkk089@gmail.com> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109245 > Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> > Link: https://patchwork.freedesktop.org/patch/msgid/20190111174950.10681-1-ville.syrjala@linux.intel.com > Reviewed-by: Mika Kahola <mika.kahola@intel.com> > (cherry picked from commit 7bed8adcd9f86231bb69bbc02f88ad89330f99e3) Pushed to drm-intel-fixes, thanks. BR, Jani. > --- > drivers/gpu/drm/i915/intel_display.c | 50 ++++++++++++++++++++++++---- > 1 file changed, 44 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > index 3da9c0f9e948..248128126422 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -15415,16 +15415,45 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc, > } > } > > +static bool has_bogus_dpll_config(const struct intel_crtc_state *crtc_state) > +{ > + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev); > + > + /* > + * Some SNB BIOSen (eg. ASUS K53SV) are known to misprogram > + * the hardware when a high res displays plugged in. DPLL P > + * divider is zero, and the pipe timings are bonkers. We'll > + * try to disable everything in that case. > + * > + * FIXME would be nice to be able to sanitize this state > + * without several WARNs, but for now let's take the easy > + * road. > + */ > + return IS_GEN6(dev_priv) && > + crtc_state->base.active && > + crtc_state->shared_dpll && > + crtc_state->port_clock == 0; > +} > + > static void intel_sanitize_encoder(struct intel_encoder *encoder) > { > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > struct intel_connector *connector; > + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc); > + struct intel_crtc_state *crtc_state = crtc ? > + to_intel_crtc_state(crtc->base.state) : NULL; > > /* We need to check both for a crtc link (meaning that the > * encoder is active and trying to read from a pipe) and the > * pipe itself being active. */ > - bool has_active_crtc = encoder->base.crtc && > - to_intel_crtc(encoder->base.crtc)->active; > + bool has_active_crtc = crtc_state && > + crtc_state->base.active; > + > + if (crtc_state && has_bogus_dpll_config(crtc_state)) { > + DRM_DEBUG_KMS("BIOS has misprogrammed the hardware. Disabling pipe %c\n", > + pipe_name(crtc->pipe)); > + has_active_crtc = false; > + } > > connector = intel_encoder_find_connector(encoder); > if (connector && !has_active_crtc) { > @@ -15435,16 +15464,25 @@ static void intel_sanitize_encoder(struct intel_encoder *encoder) > /* Connector is active, but has no active pipe. This is > * fallout from our resume register restoring. Disable > * the encoder manually again. */ > - if (encoder->base.crtc) { > - struct drm_crtc_state *crtc_state = encoder->base.crtc->state; > + if (crtc_state) { > + struct drm_encoder *best_encoder; > > DRM_DEBUG_KMS("[ENCODER:%d:%s] manually disabled\n", > encoder->base.base.id, > encoder->base.name); > + > + /* avoid oopsing in case the hooks consult best_encoder */ > + best_encoder = connector->base.state->best_encoder; > + connector->base.state->best_encoder = &encoder->base; > + > if (encoder->disable) > - encoder->disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); > + encoder->disable(encoder, crtc_state, > + connector->base.state); > if (encoder->post_disable) > - encoder->post_disable(encoder, to_intel_crtc_state(crtc_state), connector->base.state); > + encoder->post_disable(encoder, crtc_state, > + connector->base.state); > + > + connector->base.state->best_encoder = best_encoder; > } > encoder->base.crtc = NULL; -- Jani Nikula, Intel Open Source Graphics Center ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH -fixes] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen 2019-02-05 14:18 ` Ville Syrjala (?) (?) @ 2019-02-07 16:32 ` Sasha Levin -1 siblings, 0 replies; 11+ messages in thread From: Sasha Levin @ 2019-02-07 16:32 UTC (permalink / raw) To: Sasha Levin, Ville Syrjala, intel-gfx; +Cc: Daniel Kamil Kozar, stable Hi, [This is an automated email] This commit has been processed because it contains a "Fixes:" tag, fixing commit: 516a49cc1946 drm/i915: Fix assert_plane() warning on bootup with external display. The bot has tested the following trees: v4.20.6. v4.20.6: Failed to apply! Possible dependencies: c84c6fe30302 ("drm/i915: make encoder enable and disable hooks optional") How should we proceed with this patch? -- Thanks, Sasha _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fixes that failed to apply to v5.0-rc5 2019-02-05 13:42 Fixes that failed to apply to v5.0-rc5 Jani Nikula 2019-02-05 14:18 ` Ville Syrjala @ 2019-02-05 14:23 ` Ville Syrjälä 2019-02-06 7:13 ` Jani Nikula 2019-02-05 16:01 ` ✗ Fi.CI.BAT: failure for drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen (rev3) Patchwork 2019-02-08 13:07 ` Fixes that failed to apply to v5.0-rc5 Aditya Swarup 3 siblings, 1 reply; 11+ messages in thread From: Ville Syrjälä @ 2019-02-05 14:23 UTC (permalink / raw) To: Jani Nikula; +Cc: Daniel Vetter, intel-gfx On Tue, Feb 05, 2019 at 03:42:05PM +0200, Jani Nikula wrote: > > The following commits have been marked as Cc: stable or fixing something > in v5.0-rc5 or earlier, but failed to cherry-pick to > drm-intel-fixes. Please see if they are worth backporting, and please do > so if they are. > > Failed to cherry-pick: > 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with i965gm TV output") This one depends on d20151a7699 ("drm/vblank: Allow dynamic per-crtc max_vblank_count") which I seem to have pushed to drm-misc-next. Is it OK if we just cherry-pick that into drm-intel-fixes? Dave / Daniel? -- Ville Syrjälä Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fixes that failed to apply to v5.0-rc5 2019-02-05 14:23 ` Fixes that failed to apply to v5.0-rc5 Ville Syrjälä @ 2019-02-06 7:13 ` Jani Nikula 2019-02-07 21:26 ` Sean Paul 0 siblings, 1 reply; 11+ messages in thread From: Jani Nikula @ 2019-02-06 7:13 UTC (permalink / raw) To: Ville Syrjälä; +Cc: Maxime Ripard, Daniel Vetter, intel-gfx On Tue, 05 Feb 2019, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > On Tue, Feb 05, 2019 at 03:42:05PM +0200, Jani Nikula wrote: >> >> The following commits have been marked as Cc: stable or fixing something >> in v5.0-rc5 or earlier, but failed to cherry-pick to >> drm-intel-fixes. Please see if they are worth backporting, and please do >> so if they are. >> >> Failed to cherry-pick: >> 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with i965gm TV output") > > This one depends on d20151a7699 ("drm/vblank: Allow dynamic per-crtc > max_vblank_count") which I seem to have pushed to drm-misc-next. > > Is it OK if we just cherry-pick that into drm-intel-fixes? Dave / Daniel? Ping. Also Cc: drm-misc maintainers. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fixes that failed to apply to v5.0-rc5 2019-02-06 7:13 ` Jani Nikula @ 2019-02-07 21:26 ` Sean Paul 0 siblings, 0 replies; 11+ messages in thread From: Sean Paul @ 2019-02-07 21:26 UTC (permalink / raw) To: Jani Nikula; +Cc: Maxime Ripard, Daniel Vetter, intel-gfx On Wed, Feb 06, 2019 at 09:13:32AM +0200, Jani Nikula wrote: > On Tue, 05 Feb 2019, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote: > > On Tue, Feb 05, 2019 at 03:42:05PM +0200, Jani Nikula wrote: > >> > >> The following commits have been marked as Cc: stable or fixing something > >> in v5.0-rc5 or earlier, but failed to cherry-pick to > >> drm-intel-fixes. Please see if they are worth backporting, and please do > >> so if they are. > >> > >> Failed to cherry-pick: > >> 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with i965gm TV output") > > > > This one depends on d20151a7699 ("drm/vblank: Allow dynamic per-crtc *ed20151a7699 Is it being used in -misc-next right now? If not, perhaps revert there and apply to -intel-fixes? It doesn't look like it's landed in stable either. ....or just cherry-pick and make sure everything drops out nicely :) Sean > > max_vblank_count") which I seem to have pushed to drm-misc-next. > > > > Is it OK if we just cherry-pick that into drm-intel-fixes? Dave / Daniel? > > Ping. Also Cc: drm-misc maintainers. > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center -- Sean Paul, Software Engineer, Google / Chromium OS _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* ✗ Fi.CI.BAT: failure for drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen (rev3) 2019-02-05 13:42 Fixes that failed to apply to v5.0-rc5 Jani Nikula 2019-02-05 14:18 ` Ville Syrjala 2019-02-05 14:23 ` Fixes that failed to apply to v5.0-rc5 Ville Syrjälä @ 2019-02-05 16:01 ` Patchwork 2019-02-08 13:07 ` Fixes that failed to apply to v5.0-rc5 Aditya Swarup 3 siblings, 0 replies; 11+ messages in thread From: Patchwork @ 2019-02-05 16:01 UTC (permalink / raw) To: Ville Syrjala; +Cc: intel-gfx == Series Details == Series: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen (rev3) URL : https://patchwork.freedesktop.org/series/54942/ State : failure == Summary == Applying: drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/intel_display.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_display.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_display.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fixes that failed to apply to v5.0-rc5 2019-02-05 13:42 Fixes that failed to apply to v5.0-rc5 Jani Nikula ` (2 preceding siblings ...) 2019-02-05 16:01 ` ✗ Fi.CI.BAT: failure for drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen (rev3) Patchwork @ 2019-02-08 13:07 ` Aditya Swarup 2019-02-08 17:51 ` Rodrigo Vivi 3 siblings, 1 reply; 11+ messages in thread From: Aditya Swarup @ 2019-02-08 13:07 UTC (permalink / raw) To: Jani Nikula; +Cc: intel-gfx On Tue, Feb 05, 2019 at 03:42:05PM +0200, Jani Nikula wrote: > > The following commits have been marked as Cc: stable or fixing something > in v5.0-rc5 or earlier, but failed to cherry-pick to > drm-intel-fixes. Please see if they are worth backporting, and please do > so if they are. > > Failed to cherry-pick: > b14c06ec0249 ("drm/i915/cnl: Fix CNL macros for Voltage Swing programming") b14c06ec0249 is dependent on 265a2a6255f5 drm/i915/icl: combo port vswing programming changes per BSPEC https://patchwork.freedesktop.org/patch/268514/ How should I go about the backport to drm-intel-fixes? > 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with i965gm TV output") > > Cherry-pick fine but fail to build: > 7bed8adcd9f8 ("drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen") > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center Regards, Aditya Swarup _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Fixes that failed to apply to v5.0-rc5 2019-02-08 13:07 ` Fixes that failed to apply to v5.0-rc5 Aditya Swarup @ 2019-02-08 17:51 ` Rodrigo Vivi 0 siblings, 0 replies; 11+ messages in thread From: Rodrigo Vivi @ 2019-02-08 17:51 UTC (permalink / raw) To: Aditya Swarup; +Cc: Jani Nikula, intel-gfx On Fri, Feb 08, 2019 at 05:07:52AM -0800, Aditya Swarup wrote: > On Tue, Feb 05, 2019 at 03:42:05PM +0200, Jani Nikula wrote: > > > > The following commits have been marked as Cc: stable or fixing something > > in v5.0-rc5 or earlier, but failed to cherry-pick to > > drm-intel-fixes. Please see if they are worth backporting, and please do > > so if they are. > > > > Failed to cherry-pick: > > b14c06ec0249 ("drm/i915/cnl: Fix CNL macros for Voltage Swing programming") > b14c06ec0249 is dependent on > 265a2a6255f5 drm/i915/icl: combo port vswing programming changes per BSPEC It is actually b265a2a6255f5 b265a2a6255f ("drm/i915/icl: combo port vswing programming changes per BSPEC") > https://patchwork.freedesktop.org/patch/268514/ > > How should I go about the backport to drm-intel-fixes? Nothing. Well, you already did by providing the dependency ;) Jani could cherry-pick both because both applies cleanly on drm-intel-fixes > > > 32db0b6501d9 ("drm/i915: Don't try to use the hardware frame counter with i965gm TV output") > > > > Cherry-pick fine but fail to build: > > 7bed8adcd9f8 ("drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen") > > > > BR, > > Jani. > > > > > > -- > > Jani Nikula, Intel Open Source Graphics Center > > Regards, > Aditya Swarup _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-02-08 17:51 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-05 13:42 Fixes that failed to apply to v5.0-rc5 Jani Nikula 2019-02-05 14:18 ` [PATCH -fixes] drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen Ville Syrjala 2019-02-05 14:18 ` Ville Syrjala 2019-02-06 7:11 ` [Intel-gfx] " Jani Nikula 2019-02-07 16:32 ` Sasha Levin 2019-02-05 14:23 ` Fixes that failed to apply to v5.0-rc5 Ville Syrjälä 2019-02-06 7:13 ` Jani Nikula 2019-02-07 21:26 ` Sean Paul 2019-02-05 16:01 ` ✗ Fi.CI.BAT: failure for drm/i915: Try to sanitize bogus DPLL state left over by broken SNB BIOSen (rev3) Patchwork 2019-02-08 13:07 ` Fixes that failed to apply to v5.0-rc5 Aditya Swarup 2019-02-08 17:51 ` Rodrigo Vivi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.