All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxime Ripard <maxime@cerno.tech>
To: Frank Oltmanns <frank@oltmanns.dev>
Cc: Roman Beranek <romanberanek@icloud.com>,
	Chen-Yu Tsai <wens@csie.org>, David Airlie <airlied@gmail.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG
Date: Wed, 29 Mar 2023 21:56:39 +0200	[thread overview]
Message-ID: <20230329195639.iep4rv5rcigu3gj2@penduick> (raw)
In-Reply-To: <87bkkc3bzc.fsf@oltmanns.dev>

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

Hi,

On Tue, Mar 28, 2023 at 09:28:19PM +0200, Frank Oltmanns wrote:
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
>  	regulator_disable(dsi->regulator);
>  }
> 
> +static bool sun6i_dsi_encoder_mode_fixup(
> +				   struct drm_encoder *encoder,
> +				   const struct drm_display_mode *mode,
> +				   struct drm_display_mode *adjusted_mode)

So, mode_fixup is kind of deprecated in favour of atomic_check

> +{
> +	if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
> +		/*
> +		 * For DSI the PLL rate has to respect the bits per pixel and
> +		 * number of lanes.
> +		 *
> +		 * According to the BSP code:
> +		 * PLL rate = DOTCLOCK * bpp / lanes
> +		 *
> +		 * Therefore, the clock has to be adjusted in order to set the
> +		 * correct PLL rate when actually setting the clock.
> +		 */
> +		struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> +		struct mipi_dsi_device *device = dsi->device;
> +		u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> +		u8 lanes = device->lanes;
> +
> +		adjusted_mode->crtc_clock = mode->crtc_clock
> +				 * bpp / (lanes * SUN6I_DSI_TCON_DIV);

And that's visible to the userspace, so it's not where we should store
that value. I guess the best way to do something similar would be to
store it into crtc_state, and then reuse it there. But it starts to make
a lot of rather complicated code compared to your previous patch.

Maxime

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

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Frank Oltmanns <frank@oltmanns.dev>
Cc: Samuel Holland <samuel@sholland.org>,
	linux-kernel@vger.kernel.org,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Roman Beranek <romanberanek@icloud.com>,
	Chen-Yu Tsai <wens@csie.org>,
	dri-devel@lists.freedesktop.org, linux-sunxi@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG
Date: Wed, 29 Mar 2023 21:56:39 +0200	[thread overview]
Message-ID: <20230329195639.iep4rv5rcigu3gj2@penduick> (raw)
In-Reply-To: <87bkkc3bzc.fsf@oltmanns.dev>

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

Hi,

On Tue, Mar 28, 2023 at 09:28:19PM +0200, Frank Oltmanns wrote:
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
>  	regulator_disable(dsi->regulator);
>  }
> 
> +static bool sun6i_dsi_encoder_mode_fixup(
> +				   struct drm_encoder *encoder,
> +				   const struct drm_display_mode *mode,
> +				   struct drm_display_mode *adjusted_mode)

So, mode_fixup is kind of deprecated in favour of atomic_check

> +{
> +	if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
> +		/*
> +		 * For DSI the PLL rate has to respect the bits per pixel and
> +		 * number of lanes.
> +		 *
> +		 * According to the BSP code:
> +		 * PLL rate = DOTCLOCK * bpp / lanes
> +		 *
> +		 * Therefore, the clock has to be adjusted in order to set the
> +		 * correct PLL rate when actually setting the clock.
> +		 */
> +		struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> +		struct mipi_dsi_device *device = dsi->device;
> +		u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> +		u8 lanes = device->lanes;
> +
> +		adjusted_mode->crtc_clock = mode->crtc_clock
> +				 * bpp / (lanes * SUN6I_DSI_TCON_DIV);

And that's visible to the userspace, so it's not where we should store
that value. I guess the best way to do something similar would be to
store it into crtc_state, and then reuse it there. But it starts to make
a lot of rather complicated code compared to your previous patch.

Maxime

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

WARNING: multiple messages have this Message-ID (diff)
From: Maxime Ripard <maxime@cerno.tech>
To: Frank Oltmanns <frank@oltmanns.dev>
Cc: Roman Beranek <romanberanek@icloud.com>,
	Chen-Yu Tsai <wens@csie.org>, David Airlie <airlied@gmail.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG
Date: Wed, 29 Mar 2023 21:56:39 +0200	[thread overview]
Message-ID: <20230329195639.iep4rv5rcigu3gj2@penduick> (raw)
In-Reply-To: <87bkkc3bzc.fsf@oltmanns.dev>


[-- Attachment #1.1: Type: text/plain, Size: 1568 bytes --]

Hi,

On Tue, Mar 28, 2023 at 09:28:19PM +0200, Frank Oltmanns wrote:
> --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder *encoder)
>  	regulator_disable(dsi->regulator);
>  }
> 
> +static bool sun6i_dsi_encoder_mode_fixup(
> +				   struct drm_encoder *encoder,
> +				   const struct drm_display_mode *mode,
> +				   struct drm_display_mode *adjusted_mode)

So, mode_fixup is kind of deprecated in favour of atomic_check

> +{
> +	if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
> +		/*
> +		 * For DSI the PLL rate has to respect the bits per pixel and
> +		 * number of lanes.
> +		 *
> +		 * According to the BSP code:
> +		 * PLL rate = DOTCLOCK * bpp / lanes
> +		 *
> +		 * Therefore, the clock has to be adjusted in order to set the
> +		 * correct PLL rate when actually setting the clock.
> +		 */
> +		struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
> +		struct mipi_dsi_device *device = dsi->device;
> +		u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
> +		u8 lanes = device->lanes;
> +
> +		adjusted_mode->crtc_clock = mode->crtc_clock
> +				 * bpp / (lanes * SUN6I_DSI_TCON_DIV);

And that's visible to the userspace, so it's not where we should store
that value. I guess the best way to do something similar would be to
store it into crtc_state, and then reuse it there. But it starts to make
a lot of rather complicated code compared to your previous patch.

Maxime

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

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-03-29 19:56 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20 16:16 [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG Roman Beranek
2023-03-20 16:16 ` Roman Beranek
2023-03-20 16:16 ` Roman Beranek
2023-03-21 14:56 ` Maxime Ripard
2023-03-21 14:56   ` Maxime Ripard
2023-03-21 14:56   ` Maxime Ripard
2023-03-21 16:50   ` Roman Beranek
2023-03-21 16:50     ` Roman Beranek
2023-03-21 16:50     ` Roman Beranek
2023-03-21 20:53   ` Roman Beranek
2023-03-21 20:53     ` Roman Beranek
2023-03-21 20:53     ` Roman Beranek
2023-03-27 20:21     ` Maxime Ripard
2023-03-27 20:21       ` Maxime Ripard
2023-03-27 20:21       ` Maxime Ripard
2023-03-25 11:40 ` Frank Oltmanns
2023-03-25 11:40   ` Frank Oltmanns
2023-03-25 11:40   ` Frank Oltmanns
2023-03-27 20:20   ` Maxime Ripard
2023-03-27 20:20     ` Maxime Ripard
2023-03-27 20:20     ` Maxime Ripard
2023-03-27 23:48     ` Roman Beranek
2023-03-27 23:48       ` Roman Beranek
2023-03-27 23:48       ` Roman Beranek
2023-03-29 19:58       ` Maxime Ripard
2023-03-29 19:58         ` Maxime Ripard
2023-03-29 19:58         ` Maxime Ripard
2023-03-30  4:45         ` Frank Oltmanns
2023-03-30  4:45           ` Frank Oltmanns
2023-03-30  4:45           ` Frank Oltmanns
2023-03-31  5:36           ` Roman Beranek
2023-03-31  5:36             ` Roman Beranek
2023-03-31  5:36             ` Roman Beranek
2023-04-05 12:34         ` Roman Beranek
2023-04-05 12:34           ` Roman Beranek
2023-04-05 12:34           ` Roman Beranek
2023-04-05 15:03           ` Maxime Ripard
2023-04-05 15:03             ` Maxime Ripard
2023-04-05 15:03             ` Maxime Ripard
2023-04-12  7:14             ` Roman Beranek
2023-04-12  7:14               ` Roman Beranek
2023-04-12  7:14               ` Roman Beranek
2023-04-12 14:09               ` Maxime Ripard
2023-04-12 14:09                 ` Maxime Ripard
2023-04-12 14:09                 ` Maxime Ripard
2023-04-08  7:07           ` Jernej Škrabec
2023-04-08  7:07             ` Jernej Škrabec
2023-04-08  7:07             ` Jernej Škrabec
2023-04-12  1:22             ` Roman Beranek
2023-04-12  1:22               ` Roman Beranek
2023-04-12  1:22               ` Roman Beranek
2023-03-28 19:28     ` Frank Oltmanns
2023-03-28 19:28       ` Frank Oltmanns
2023-03-28 19:28       ` Frank Oltmanns
2023-03-29 19:56       ` Maxime Ripard [this message]
2023-03-29 19:56         ` Maxime Ripard
2023-03-29 19:56         ` Maxime Ripard
2023-03-30  4:41         ` Frank Oltmanns
2023-03-30  4:41           ` Frank Oltmanns
2023-03-30  4:41           ` Frank Oltmanns

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=20230329195639.iep4rv5rcigu3gj2@penduick \
    --to=maxime@cerno.tech \
    --cc=airlied@gmail.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=frank@oltmanns.dev \
    --cc=jernej.skrabec@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=romanberanek@icloud.com \
    --cc=samuel@sholland.org \
    --cc=wens@csie.org \
    /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.