From: Imre Deak <imre.deak@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 02/11] drm/i915: Make the CRTC wrt. CSC state consistent during sanitize-disabling
Date: Wed, 26 Apr 2023 22:51:26 +0300 [thread overview]
Message-ID: <ZEmAvlONRFAexX1R@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <ZElkCcFvVEx8DYez@intel.com>
On Wed, Apr 26, 2023 at 08:48:57PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2023 at 07:52:56PM +0300, Imre Deak wrote:
> > intel_crtc_free_hw_state() frees all the Intel specific CSC blobs in the
> > CRTC state, but the next memset() will only clear the corresponding
> > pointers for the ones stored in intel_crtc_state:hw. Clear the ones
> > stored in intel_crtc_state as well. Also sync the UAPI state with the HW
> > state after the HW state was reset. This will reset the uapi.active
> > flag as well, so no need to do this separately. Syncing the state will
> > create a new umode blob, so move deleting the blob after the sync call.
> >
> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_modeset_setup.c | 12 +++++++++---
> > 1 file changed, 9 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > index eefa4018dc0c2..57d087de654f8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> > @@ -30,6 +30,8 @@
> > #include "intel_wm.h"
> > #include "skl_watermark.h"
> >
> > +static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state *crtc_state);
> > +
> > static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
> > struct drm_modeset_acquire_ctx *ctx)
> > {
> > @@ -88,13 +90,17 @@ static void intel_crtc_disable_noatomic(struct intel_crtc *crtc,
> > crtc->active = false;
> > crtc->base.enabled = false;
> >
> > - drm_WARN_ON(&i915->drm,
> > - drm_atomic_set_mode_for_crtc(&crtc_state->uapi, NULL) < 0);
> > - crtc_state->uapi.active = false;
> > crtc_state->uapi.connector_mask = 0;
> > crtc_state->uapi.encoder_mask = 0;
> > +
> > intel_crtc_free_hw_state(crtc_state);
> > memset(&crtc_state->hw, 0, sizeof(crtc_state->hw));
> > + crtc_state->pre_csc_lut = NULL;
> > + crtc_state->post_csc_lut = NULL;
> > + intel_crtc_copy_hw_to_uapi_state(crtc_state);
> > +
> > + drm_WARN_ON(&i915->drm,
> > + drm_atomic_set_mode_for_crtc(&crtc_state->uapi, NULL) < 0);
>
> Hmm. Is there a reason we can't just do the full destroy+reset
> thing that intel_modeset_readout_hw_state() does?
Yes, that's better and works. It revealed that the (global) shared_dpll
state needs to be also updated here.
I'd like to use this function to disable bigjoiner configs as well
(later in this patchset), where the slave CRTC state is used during the
master CRTC disabling (in the encoder post_disable hook); so is it ok to
first disable all related CRTCs and then reset the state for all (also
moving the fbc disabling and watermark updating before the state
update)?
Both of the above changes are at
https://github.com/ideak/linux/commit/fc9b011249112369
on top of this patchset.
Also is it ok to keep the full CRTC reset change as a separate patch
(for the purpose of stable backporting the rest).
>
> >
> > for_each_encoder_on_crtc(&i915->drm, &crtc->base, encoder)
> > encoder->base.crtc = NULL;
> > --
> > 2.37.2
>
> --
> Ville Syrjälä
> Intel
next prev parent reply other threads:[~2023-04-26 19:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 16:52 [Intel-gfx] [PATCH 00/11] drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue Imre Deak
2023-04-26 16:52 ` [Intel-gfx] [PATCH 01/11] drm/i915: Fix PIPEDMC disabling for a bigjoiner configuration Imre Deak
2023-04-26 16:52 ` [Intel-gfx] [PATCH 02/11] drm/i915: Make the CRTC wrt. CSC state consistent during sanitize-disabling Imre Deak
2023-04-26 17:48 ` Ville Syrjälä
2023-04-26 19:51 ` Imre Deak [this message]
2023-04-26 16:52 ` [Intel-gfx] [PATCH 03/11] drm/i915: Update connector atomic state before crtc sanitize-disabling Imre Deak
2023-04-26 16:52 ` [Intel-gfx] [PATCH 04/11] drm/i915: Factor out set_encoder_for_connector() Imre Deak
2023-04-26 16:52 ` [Intel-gfx] [PATCH 05/11] drm/i915: Add support for disabling any CRTCs during HW readout/sanitization Imre Deak
2023-04-28 14:02 ` Ville Syrjälä
2023-04-28 17:22 ` Imre Deak
2023-04-28 17:47 ` Imre Deak
2023-04-29 7:50 ` Imre Deak
2023-04-26 16:53 ` [Intel-gfx] [PATCH 06/11] drm/i915/dp: Add link training debug and error printing helpers Imre Deak
2023-04-28 14:21 ` Ville Syrjälä
2023-04-28 19:30 ` Imre Deak
2023-04-26 16:53 ` [Intel-gfx] [PATCH 07/11] drm/i915/dp: Convert link training error to debug message on disconnected sink Imre Deak
2023-04-26 16:53 ` [Intel-gfx] [PATCH 08/11] drm/i915/dp: Prevent link training fallback on disconnected port Imre Deak
2023-04-26 16:53 ` [Intel-gfx] [PATCH 09/11] drm/i915/dp: Factor out intel_dp_get_active_pipes() Imre Deak
2023-04-26 16:53 ` [Intel-gfx] [PATCH 10/11] drm/i915: Factor out call_with_modeset_ctx() Imre Deak
2023-04-28 14:32 ` Ville Syrjälä
2023-04-28 18:34 ` Imre Deak
2023-04-26 16:53 ` [Intel-gfx] [PATCH 11/11] drm/i915/tc: Reset TypeC PHYs left enabled in DP-alt mode after the sink disconnects Imre Deak
2023-04-26 19:37 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tc: Add a workaround for an IOM/TCSS firmware hang issue Patchwork
2023-04-26 19:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-04-26 22:09 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZEmAvlONRFAexX1R@ideak-desk.fi.intel.com \
--to=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox