From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Kahola, Mika" <mika.kahola@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
Date: Fri, 9 Feb 2024 14:06:37 +0200 [thread overview]
Message-ID: <ZcYVTcvE4Z3mo88U@intel.com> (raw)
In-Reply-To: <MW4PR11MB7054254B4B9C319878D99FCBEF4B2@MW4PR11MB7054.namprd11.prod.outlook.com>
On Fri, Feb 09, 2024 at 11:55:58AM +0000, Kahola, Mika wrote:
> > -----Original Message-----
> > From: Jani Nikula <jani.nikula@linux.intel.com>
> > Sent: Friday, February 9, 2024 11:06 AM
> > To: Kahola, Mika <mika.kahola@intel.com>; intel-gfx@lists.freedesktop.org
> > Cc: Kahola, Mika <mika.kahola@intel.com>
> > Subject: Re: [PATCH 2/2] drm/i915/display: Force full modeset for eDP
> >
> > On Tue, 06 Feb 2024, Mika Kahola <mika.kahola@intel.com> wrote:
> > > Force full modeset for eDP when booting up. GOP programs PLL
> > > parameters and hence, we would be able to use fastset for eDP.
> > > However, with fastset we are not setting PLL values from the driver
> > > and rely that GOP and driver PLL values match.
> > > We have discovered that with some of the panels this is not true and
> > > hence we would need to program PLL values by the driver. The patch
> > > suggests a workaround as enabling full modeset when booting up. This
> > > way we force the driver to write the PLL values to the hw.
> >
> > No. We want to avoid full modesets if possible, both in general and at probe.
> >
> > And when we do end up with modesets, the decision needs to be based on changes in the state that we can't write to the
> > hardware without a modeset.
> >
> > We can't unconditionally force a modeset on eDP panels at probe.
>
> Thanks! Just wondering what the options here might be? With fastest we end up having a mismatch with one PLL value with a few panels.
You seem to be stuck in some infinite loop. If your PLL parameters
are mismatching that should prevent the fastset, but then I guess
you added some hack to allow the fastset despite the mismatch, and
now you're trying to undo that hack by blindly forcing a full
modeset?
>
> Should we try identify the panels and setup some sort of quirks for these problematic panels or what would be the best solution?
>
> -Mika-
>
> >
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Mika Kahola <mika.kahola@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp.c | 13 +++++++++++++
> > > 1 file changed, 13 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > > b/drivers/gpu/drm/i915/display/intel_dp.c
> > > index ab415f41924d..9699ded1eb5f 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > > @@ -3319,6 +3319,7 @@ bool intel_dp_initial_fastset_check(struct intel_encoder *encoder,
> > > * of crtc_state->dsc, we have no way to ensure reliable fastset.
> > > * Remove once we have readout for DSC.
> > > */
> > > +
> > > if (crtc_state->dsc.compression_enable) {
> > > drm_dbg_kms(&i915->drm, "[ENCODER:%d:%s] Forcing full modeset due to DSC being enabled\n",
> > > encoder->base.base.id, encoder->base.name); @@ -3326,6
> > > +3327,18 @@ bool intel_dp_initial_fastset_check(struct intel_encoder *encoder,
> > > fastset = false;
> > > }
> > >
> > > + /*
> > > + * FIXME hack to force full modeset for eDP as not always BIOS written PLL
> > > + * values does not match with the ones defined in the driver code
> > > + */
> > > + if (!crtc_state->uapi.mode_changed &&
> > > + intel_dp_is_edp(intel_dp)) {
> > > + drm_dbg_kms(&i915->drm, "Forcing full modeset for eDP\n");
> > > + crtc_state->uapi.mode_changed = true;
> > > + fastset = false;
> > > + }
> > > +
> > > +
> > > return fastset;
> > > }
> >
> > --
> > Jani Nikula, Intel
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2024-02-09 12:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 7:09 [PATCH 0/2] drm/i915/display: Force full modeset for eDP Mika Kahola
2024-02-06 7:09 ` [PATCH 1/2] Revert "drm/i915/display: Skip C10 state verification in case of fastset" Mika Kahola
2024-02-06 7:09 ` [PATCH 2/2] drm/i915/display: Force full modeset for eDP Mika Kahola
2024-02-09 9:06 ` Jani Nikula
2024-02-09 11:55 ` Kahola, Mika
2024-02-09 12:06 ` Ville Syrjälä [this message]
2024-02-09 12:13 ` Kahola, Mika
2024-02-09 12:18 ` Ville Syrjälä
2024-02-09 12:33 ` Kahola, Mika
2024-02-09 12:49 ` Ville Syrjälä
2024-02-09 13:17 ` Kahola, Mika
2024-02-09 13:31 ` Ville Syrjälä
2024-02-06 7:51 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2024-02-06 7:51 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-02-06 8:09 ` ✓ Fi.CI.BAT: success " Patchwork
2024-02-06 10:08 ` ✗ 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=ZcYVTcvE4Z3mo88U@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=mika.kahola@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 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.