From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org,
Nischal Varide <nischal.varide@intel.com>
Subject: Re: [Intel-gfx] [PATCH 2/9] drm/i915/edp: reject modes with dimensions other than fixed mode
Date: Mon, 25 Jan 2021 18:40:27 +0200 [thread overview]
Message-ID: <YA70e4YGxQaJ66zJ@intel.com> (raw)
In-Reply-To: <abbfe5a4a18f8258a92c06e7fbd4ea695bd3ca48.1611589818.git.jani.nikula@intel.com>
On Mon, Jan 25, 2021 at 05:52:26PM +0200, Jani Nikula wrote:
> Be more strict about filtering modes for eDP.
>
> Cc: Nischal Varide <nischal.varide@intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 8979996f1747..6afea0681ce9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -787,10 +787,10 @@ intel_dp_mode_valid(struct drm_connector *connector,
> return MODE_H_ILLEGAL;
>
> if (intel_dp_is_edp(intel_dp) && fixed_mode) {
> - if (mode->hdisplay > fixed_mode->hdisplay)
> + if (mode->hdisplay != fixed_mode->hdisplay)
> return MODE_PANEL;
>
> - if (mode->vdisplay > fixed_mode->vdisplay)
> + if (mode->vdisplay != fixed_mode->vdisplay)
> return MODE_PANEL;
Yeah, I think this makes sense since we never use anything
but the fixed_mode for the actual timings. I don't think I've
ever seen a display that would advertise multiple resolution.
And I think that would actually indicate that the panel can
really accept different resolutions, which we would never do
anyway.
The old behaviour would make more sense if we allowed userspace
to add custom modes to the mode list. But we don't. All custom
pfit scaled modes I think are always a purely userspace thing
(based on the presence of the scaling mode prop).
We should probably do this for the output types as well.
Not quite sure what to do about SDVO (and maybe DVO) so
probably ignore those for now.
>
> target_clock = fixed_mode->clock;
> --
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-01-25 16:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-25 15:52 [Intel-gfx] [PATCH 0/9] drm/i915/edp: enable MSO... maybe Jani Nikula
2021-01-25 15:52 ` [Intel-gfx] [PATCH 1/9] drm/dp: add MSO related DPCD registers Jani Nikula
2021-01-25 15:52 ` Jani Nikula
2021-01-25 15:52 ` [Intel-gfx] [PATCH 2/9] drm/i915/edp: reject modes with dimensions other than fixed mode Jani Nikula
2021-01-25 16:40 ` Ville Syrjälä [this message]
2021-01-25 15:52 ` [Intel-gfx] [PATCH 3/9] drm/i915/edp: always add fixed mode to probed modes in ->get_modes() Jani Nikula
2021-01-25 15:52 ` [Intel-gfx] [PATCH 4/9] drm/i915/edp: read sink MSO configuration for eDP 1.4+ Jani Nikula
2021-01-25 15:52 ` [Intel-gfx] [PATCH 5/9] drm/i915/reg: add stream splitter configuration definitions Jani Nikula
2021-01-25 15:52 ` [Intel-gfx] [PATCH 6/9] drm/i915/mso: add state readout for platforms that support it Jani Nikula
2021-01-25 16:43 ` Ville Syrjälä
2021-01-25 15:52 ` [Intel-gfx] [PATCH 7/9] drm/i915/mso: add state check Jani Nikula
2021-01-25 15:52 ` [Intel-gfx] [PATCH 8/9] drm/i915/edp: modify fixed and downclock modes for MSO Jani Nikula
2021-01-25 15:52 ` [Intel-gfx] [PATCH 9/9] drm/i915/edp: enable eDP MSO during link training Jani Nikula
2021-01-25 18:53 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/edp: enable MSO... maybe Patchwork
2021-01-25 19:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-01-26 0:49 ` [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=YA70e4YGxQaJ66zJ@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=nischal.varide@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.