linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Maxime Ripard <mripard@kernel.org>
To: Sean Nyekjaer <sean@geanix.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	 Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>,
	 Simona Vetter <simona@ffwll.ch>, Chen-Yu Tsai <wens@csie.org>,
	 Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	 Yannick Fertre <yannick.fertre@foss.st.com>,
	Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com>,
	 Philippe Cornu <philippe.cornu@foss.st.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	 Alexandre Torgue <alexandre.torgue@foss.st.com>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev,
	 linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH v2 1/3] drm/modes: introduce drm_mode_validate_mode() helper function
Date: Tue, 26 Nov 2024 09:38:55 +0100	[thread overview]
Message-ID: <20241126-refreshing-slick-pig-baebab@houat> (raw)
In-Reply-To: <bfuj6w6hsbfpdw24th6dl3ugvj45op6jb45gx5ab5pulud7hiz@o2zbn45z3lt4>

[-- Attachment #1: Type: text/plain, Size: 3124 bytes --]

Hi,

On Tue, Nov 26, 2024 at 08:36:00AM +0100, Sean Nyekjaer wrote:
> On Mon, Nov 25, 2024 at 05:00:56PM +0100, Maxime Ripard wrote:
> > On Mon, Nov 25, 2024 at 02:49:26PM +0100, Sean Nyekjaer wrote:
> > > Check if the required pixel clock is in within .5% range of the
> > > desired pixel clock.
> > > This will match the requirement for HDMI where a .5% tolerance is allowed.
> > > 
> > > Signed-off-by: Sean Nyekjaer <sean@geanix.com>
> > > ---
> > >  drivers/gpu/drm/drm_modes.c | 34 ++++++++++++++++++++++++++++++++++
> > >  include/drm/drm_modes.h     |  2 ++
> > >  2 files changed, 36 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > > index 6ba167a3346134072d100af0adbbe9b49e970769..4068b904759bf80502efde6e4d977b297f5d5359 100644
> > > --- a/drivers/gpu/drm/drm_modes.c
> > > +++ b/drivers/gpu/drm/drm_modes.c
> > > @@ -1623,6 +1623,40 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct drm_display_mode *mode1,
> > >  }
> > >  EXPORT_SYMBOL(drm_mode_equal_no_clocks_no_stereo);
> > >  
> > > +/**
> > > + * drm_mode_validate_mode
> > > + * @mode: mode to check
> > > + * @rounded_rate: output pixel clock
> > > + *
> > > + * VESA DMT defines a tolerance of 0.5% on the pixel clock, while the
> > > + * CVT spec reuses that tolerance in its examples, so it looks to be a
> > > + * good default tolerance for the EDID-based modes. Define it to 5 per
> > > + * mille to avoid floating point operations.
> > > + *
> > > + * Returns:
> > > + * The mode status
> > > + */
> > > +enum drm_mode_status drm_mode_validate_mode(const struct drm_display_mode *mode,
> > > +					    unsigned long long rounded_rate)
> > > +{
> > > +	enum drm_mode_status status;
> > > +	unsigned long long rate = mode->clock * 1000;
> > > +	unsigned long long lowest, highest;
> > > +
> > > +	lowest = rate * (1000 - 5);
> > > +	do_div(lowest, 1000);
> > > +	if (rounded_rate < lowest)
> > > +		return MODE_CLOCK_LOW;
> > > +
> > > +	highest = rate * (1000 + 5);
> > > +	do_div(highest, 1000);
> > > +	if (rounded_rate > highest)
> > > +		return MODE_CLOCK_HIGH;
> > > +
> > > +	return MODE_OK;
> > > +}
> > > +EXPORT_SYMBOL(drm_mode_validate_mode);
> > 
> > Thanks a lot for doing that!
> > 
> > I wonder about the naming though (and prototype). I doesn't really
> > validates a mode, but rather makes sure that a given rate is a good
> > approximation of a pixel clock. So maybe something like
> > drm_mode_check_pixel_clock?
> 
> Naming is hard :) I will use drm_mode_check_pixel_clock() for V2.
> 
> Would it make sense to have the pixel clock requirement as a input
> parameter? For HDMI it is 0.5%

This code was only used for panels so far. It reuses the same tolerance
than HDMI because we couldn't come up with anything better, but it
should totally apply to other things.

> and in my case the LVDS panel 10%.

10% is a lot, and I'm not sure we'll want that. The framerate being
anywhere between 54 and 66 fps will trip a lot of applications too.

Why do you need such a big tolerance?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]

  reply	other threads:[~2024-11-26  8:40 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-25 13:49 [PATCH v2 0/3] drm/stm: dsi: relax mode_valid clock tolerance Sean Nyekjaer
2024-11-25 13:49 ` [PATCH v2 1/3] drm/modes: introduce drm_mode_validate_mode() helper function Sean Nyekjaer
2024-11-25 16:00   ` Maxime Ripard
2024-11-26  7:36     ` Sean Nyekjaer
2024-11-26  8:38       ` Maxime Ripard [this message]
2024-11-26 11:34         ` Sean Nyekjaer
2024-11-26 12:09           ` Maxime Ripard
2024-11-26 12:11             ` Sean Nyekjaer
2024-11-26  8:47       ` Raphael Gallais-Pou
2024-11-26  9:30         ` Maxime Ripard
2024-11-26 13:30       ` Sean Nyekjaer
2024-12-02 10:32         ` Maxime Ripard
2024-11-26 10:16     ` Jani Nikula
2024-11-26 12:09       ` Maxime Ripard
2024-11-26 12:24         ` Jani Nikula
2024-11-26 15:49           ` Maxime Ripard
2025-01-06 16:16   ` Raphael Gallais-Pou
2024-11-25 13:49 ` [PATCH v2 2/3] drm/sun4i: use " Sean Nyekjaer
2024-11-25 16:01   ` Maxime Ripard
2024-11-25 16:10   ` Chen-Yu Tsai
2024-11-25 13:49 ` [PATCH v2 3/3] drm/stm: dsi: " Sean Nyekjaer
2024-11-25 16:01   ` Maxime Ripard
2025-01-06 16:04   ` Raphael Gallais-Pou

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=20241126-refreshing-slick-pig-baebab@houat \
    --to=mripard@kernel.org \
    --cc=airlied@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=philippe.cornu@foss.st.com \
    --cc=raphael.gallais-pou@foss.st.com \
    --cc=samuel@sholland.org \
    --cc=sean@geanix.com \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=wens@csie.org \
    --cc=yannick.fertre@foss.st.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;
as well as URLs for NNTP newsgroup(s).