From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Jouni Högander" <jouni.hogander@intel.com>,
intel-gfx@lists.freedesktop.org
Cc: ville.syrjala@linux.intel.com
Subject: Re: [PATCH] drm/i915/display: use old bpp as a base when modeset is not allowed
Date: Tue, 27 Aug 2024 13:29:55 +0300 [thread overview]
Message-ID: <87mskyz2ak.fsf@intel.com> (raw)
In-Reply-To: <8e0e10a9-fd2e-4452-8a12-ba68e522a418@linux.intel.com>
On Tue, 27 Aug 2024, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
> Hey,
>
> We shouldn't have code acting differently whether modesets are allowed,
> I think I'm missing some context here?
Yeah. Since GOP is mentioned, is this really about state readout
instead?
BR,
Jani.
>
> Cheers,
> ~Marten
>
> Den 2024-08-26 kl. 12:41, skrev Jouni Högander:
>> We are currently observing failure on refresh rate change on VRR setup if
>> full modeset is not allowed. This is caused by the mismatch in bpp
>> configured by GOP and bpp value calculated by our driver. Changing bpp to
>> value calculated by our driver would require full mode set.
>>
>> We don't have mechanism to communicate current bpp to userspace ->
>> Userspace can't request to use current bpp. Changing bpp means full
>> modeset. This becomes a problem when userspace haven't allowed full mode
>> set.
>>
>> Complete solution here would mean adding mechanism to communicate current
>> bpp to userspace. User space should use this bpp to avoid changing bpp if
>> it wants to avoid full mode set.
>>
>> Tackle this for now in our driver by using existing bpp if full modeset is
>> not allowed.
>>
>> Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 33 ++++++++++++++------
>> 1 file changed, 23 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
>> index 9049b9a1209d8..7b805998b280a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -4385,21 +4385,34 @@ compute_baseline_pipe_bpp(struct intel_atomic_state *state,
>> struct intel_crtc *crtc)
>> {
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> - struct intel_crtc_state *crtc_state =
>> + struct intel_crtc_state *new_crtc_state =
>> intel_atomic_get_new_crtc_state(state, crtc);
>> + struct intel_crtc_state *old_crtc_state =
>> + intel_atomic_get_old_crtc_state(state, crtc);
>> struct drm_connector *connector;
>> struct drm_connector_state *connector_state;
>> int bpp, i;
>>
>> - if ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
>> - IS_CHERRYVIEW(dev_priv)))
>> - bpp = 10*3;
>> - else if (DISPLAY_VER(dev_priv) >= 5)
>> - bpp = 12*3;
>> - else
>> - bpp = 8*3;
>> + /*
>> + * TODO: We don't have mechanism to communicate current bpp to
>> + * userspace -> Userspace can't request to use current bpp. Changing bpp
>> + * means full modeset. This becomes a problem when userspace wants to
>> + * avoid full modeset. Tackle this on our driver by using existing bpp
>> + * if full modeset is not allowed.
>> + */
>> + if (!state->base.allow_modeset) {
>> + bpp = old_crtc_state->pipe_bpp;
>> + } else {
>> + if ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
>> + IS_CHERRYVIEW(dev_priv)))
>> + bpp = 10 * 3;
>> + else if (DISPLAY_VER(dev_priv) >= 5)
>> + bpp = 12 * 3;
>> + else
>> + bpp = 8 * 3;
>> + }
>>
>> - crtc_state->pipe_bpp = bpp;
>> + new_crtc_state->pipe_bpp = bpp;
>>
>> /* Clamp display bpp to connector max bpp */
>> for_each_new_connector_in_state(&state->base, connector, connector_state, i) {
>> @@ -4408,7 +4421,7 @@ compute_baseline_pipe_bpp(struct intel_atomic_state *state,
>> if (connector_state->crtc != &crtc->base)
>> continue;
>>
>> - ret = compute_sink_pipe_bpp(connector_state, crtc_state);
>> + ret = compute_sink_pipe_bpp(connector_state, new_crtc_state);
>> if (ret)
>> return ret;
>> }
>
--
Jani Nikula, Intel
next prev parent reply other threads:[~2024-08-27 10:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-26 10:41 [PATCH] drm/i915/display: use old bpp as a base when modeset is not allowed Jouni Högander
2024-08-26 15:51 ` ✓ Fi.CI.BAT: success for " Patchwork
2024-08-27 4:29 ` [PATCH] " Lee, Shawn C
2024-08-27 9:43 ` ✗ Fi.CI.IGT: failure for " Patchwork
2024-08-27 10:09 ` [PATCH] " Maarten Lankhorst
2024-08-27 10:29 ` Jani Nikula [this message]
2024-08-27 11:57 ` Hogander, Jouni
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=87mskyz2ak.fsf@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jouni.hogander@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--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 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.