devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Bee <knaerzche@gmail.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: "Sandy Huang" <hjc@rock-chips.com>,
	"Heiko Stübner" <heiko@sntech.de>, "Andy Yan" <andyshrk@163.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@gmail.com>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation
Date: Thu, 14 Dec 2023 12:17:39 +0100	[thread overview]
Message-ID: <1b7402b2-ec03-420b-a81b-3e6ea46e402a@gmail.com> (raw)
In-Reply-To: <wz4e43ateg3gb7745mz22wwyruwavevvpfbqsdxeynejcjxhzn@qbqldsnkktei>

Hi Maxime,

Am 14.12.23 um 09:05 schrieb Maxime Ripard:
> Hi,
>
> On Wed, Dec 13, 2023 at 08:51:21PM +0100, Alex Bee wrote:
>> As per TRM this controller supports pixelclocks starting from 25 MHz. The
>> maximum supported pixelclocks are defined by the phy configurations we
>> have. Also it can't support modes that require doubled clocks.
>> If there is a phy reference clock we can additionally validate against
>> VESA DMT's recommendations.
>> Those checks are added to the mode_valid hook of the connector and
>> encoder's mode_fixup hook.
>>
>> Signed-off-by: Alex Bee <knaerzche@gmail.com>
>> ---
>>   drivers/gpu/drm/rockchip/inno_hdmi.c | 38 ++++++++++++++++++++++++++--
>>   1 file changed, 36 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> index f7f0bec725f9..2f839ff31c1c 100644
>> --- a/drivers/gpu/drm/rockchip/inno_hdmi.c
>> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
>> @@ -38,6 +38,8 @@ struct inno_hdmi_variant {
>>   	struct inno_hdmi_phy_config *default_phy_config;
>>   };
>>   
>> +#define INNO_HDMI_MIN_TMDS_CLOCK  25000000U
>> +
>>   struct hdmi_data_info {
>>   	int vic;
>>   	bool sink_has_audio;
>> @@ -572,6 +574,34 @@ static int inno_hdmi_setup(struct inno_hdmi *hdmi,
>>   	return 0;
>>   }
>>   
>> +static enum drm_mode_status inno_hdmi_mode_valid(struct inno_hdmi *hdmi,
>> +						 struct drm_display_mode *mode)
>> +{
> So, mode_valid is only called to filter out the modes retrieved by
> get_modes, but it won't be called when userspace programs a mode. That's
> atomic_check's job.
>
> So you probably want to create a shared function between atomic_check
> and mode_valid, and call it from both places (or call mode_valid from
> atomic_check).
This actually _is_ a shared function called in 
inno_hdmi_connector_mode_valid and inno_hdmi_encoder_mode_fixup. Yes, I  
probably should use it in atomic_check _also_.
>
>> +	/* No support for double-clock modes */
>> +	if (mode->flags & DRM_MODE_FLAG_DBLCLK)
>> +		return MODE_BAD;
>> +
>> +	unsigned int mpixelclk = mode->clock * 1000;
> Variables should be declared at the top of the function.
Oookay ... can move them.
>> +	if (mpixelclk < INNO_HDMI_MIN_TMDS_CLOCK)
>> +		return MODE_CLOCK_LOW;
> You probably want to check the max TMDS clock too?
Not sure what you mean here. For the currently supported formats of this 
driver (rgb only) tmds clock and pixel clock are always the same.
>
>> +	if (inno_hdmi_find_phy_config(hdmi, mpixelclk) < 0)
>> +		return MODE_CLOCK_HIGH;
>> +
>> +	if (hdmi->refclk) {
>> +		long refclk = clk_round_rate(hdmi->refclk, mpixelclk);
>> +		unsigned int max_tolerance = mpixelclk / 5000;
>> +
>> +		/* Vesa DMT standard mentions +/- 0.5% max tolerance */
>> +		if (abs(refclk - mpixelclk) > max_tolerance ||
>> +		    mpixelclk - refclk > max_tolerance;
>> +			return MODE_NOCLOCK;
> You should use abs_diff here. abs() will get confused by the unsigned vs
> signed comparison.
Ack.
>
>> +	}
>> +
>> +	return MODE_OK;
>> +}
>> +
>>   static void inno_hdmi_encoder_mode_set(struct drm_encoder *encoder,
>>   				       struct drm_display_mode *mode,
>>   				       struct drm_display_mode *adj_mode)
>> @@ -602,7 +632,9 @@ static bool inno_hdmi_encoder_mode_fixup(struct drm_encoder *encoder,
>>   					 const struct drm_display_mode *mode,
>>   					 struct drm_display_mode *adj_mode)
>>   {
>> -	return true;
>> +	struct inno_hdmi *hdmi = encoder_to_inno_hdmi(encoder);
>> +
>> +	return inno_hdmi_mode_valid(hdmi, adj_mode) == MODE_OK;
>>   }
> Why do you call mode_valid in mode_fixup?

I'm calling the shared function you asked me to introduce 
(inno_hdmi_connector_mode_valid != inno_mode_valid)

Alex

>
> Maxime

  reply	other threads:[~2023-12-14 11:17 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-13 19:51 [PATCH 00/11] Add HDMI support for RK3128 Alex Bee
2023-12-13 19:51 ` [PATCH 01/11] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible Alex Bee
2023-12-14  7:53   ` Krzysztof Kozlowski
2023-12-14 15:22     ` Alex Bee
2023-12-14 16:07       ` Krzysztof Kozlowski
2023-12-14 16:20         ` Heiko Stübner
2023-12-14 16:26           ` Krzysztof Kozlowski
2023-12-13 19:51 ` [PATCH 02/11] drm/rockchip: vop: Add output selection registers for RK312x Alex Bee
2023-12-13 19:51 ` [PATCH 03/11] drm/rockchip: inno_hdmi: Fix video timing Alex Bee
2023-12-13 19:51 ` [PATCH 04/11] drm/rockchip: inno_hdmi: Correctly setup HDMI quantization range Alex Bee
2023-12-14  7:56   ` Maxime Ripard
2023-12-14 11:12     ` Alex Bee
2023-12-14 11:17       ` Heiko Stübner
2023-12-14 11:36         ` Maxime Ripard
2023-12-14 11:50           ` Andy Yan
2023-12-14 16:34           ` Alex Bee
2023-12-15 12:29             ` Maxime Ripard
2023-12-14 11:33       ` Maxime Ripard
2023-12-14 14:05         ` Alex Bee
2023-12-15 12:27           ` Maxime Ripard
2023-12-13 19:51 ` [PATCH 05/11] drm/rockchip: inno_hdmi: Add variant support Alex Bee
2023-12-13 19:51 ` [PATCH 06/11] drm/rockchip: inno_hdmi: Add RK3128 support Alex Bee
2023-12-13 19:51 ` [PATCH 07/11] drm/rockchip: inno_hdmi: Add basic mode validation Alex Bee
2023-12-14  8:05   ` Maxime Ripard
2023-12-14 11:17     ` Alex Bee [this message]
2023-12-14 11:40       ` Maxime Ripard
2023-12-14 13:05         ` Alex Bee
2023-12-13 19:51 ` [PATCH 08/11] drm/rockchip: inno_hdmi: Drop custom fill_modes hook Alex Bee
2023-12-13 19:51 ` [PATCH 09/11] ARM: dts: rockchip: Add display subsystem for RK3128 Alex Bee
2023-12-13 19:51 ` [PATCH 10/11] ARM: dts rockchip: Add HDMI node " Alex Bee
2023-12-13 19:51 ` [PATCH 11/11] ARM: dts: rockchip: Enable HDMI output for XPI-3128 Alex Bee

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=1b7402b2-ec03-420b-a81b-3e6ea46e402a@gmail.com \
    --to=knaerzche@gmail.com \
    --cc=airlied@gmail.com \
    --cc=andyshrk@163.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=tzimmermann@suse.de \
    /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).