Feedback-ID: i8771445c:Fastmail
Date:   Tue, 21 Mar 2023 15:56:46 +0100
From:   Maxime Ripard <maxime@cerno.tech>
To:     Roman Beranek <romanberanek@icloud.com>
Cc:     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
Message-ID: <20230321145646.w6kr7ddurfxpg5rt@houat>
References: <20230320161636.24411-1-romanberanek@icloud.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
        protocol="application/pgp-signature"; boundary="zucvqkk7astyp3jt"
Content-Disposition: inline
In-Reply-To: <20230320161636.24411-1-romanberanek@icloud.com>
Precedence: bulk


--zucvqkk7astyp3jt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Mon, Mar 20, 2023 at 05:16:36PM +0100, Roman Beranek wrote:
> In the case of DSI output, the value of SUN4I_TCON0_DCLK_DIV (4) does
> not represent the actual dotclock divider, PLL_MIPI instead runs at
> (bpp / lanes )-multiple [1] of the dotclock. [2] Setting 4 as dotclock
> divder thus leads to reduced frame rate, specifically by 1/3 on 4-lane
> panels, and by 2/3 on 2-lane panels respectively.
>=20
> As sun4i_dotclock driver stores its calculated divider directly in
> the register, conditional handling of the DSI output scenario is needed.
> Instead of reading the divider from SUN4I_TCON0_DCLK_REG, retrieve
> the value from tcon->dclk_min_div.
>=20
> [1] bits per pixel / number of DSI lanes
> [2] https://github.com/BPI-SINOVOIP/BPI-M64-bsp-4.4/blob/66bef0f2f30b367e=
b93b1cbad21ce85e0361f7ae/linux-sunxi/drivers/video/fbdev/sunxi/disp2/disp/d=
e/lowlevel_sun50iw1/disp_al.c#L322
>=20
> Signed-off-by: Roman Beranek <romanberanek@icloud.com>

This is similar to
https://lore.kernel.org/all/20230319160704.9858-2-frank@oltmanns.dev/

What's the story there? Also, how was it tested/confirmed?

Maxime

--zucvqkk7astyp3jt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZBnFrgAKCRDj7w1vZxhR
xW1uAP9976ZsRECK0eQpWRQZgu8XVlengWG8ooPy6U2I7N47ZgEA6brbh4HoKGtV
lwnpwiadCnsprq26idTI18GGtM6lrAY=
=giCa
-----END PGP SIGNATURE-----

--zucvqkk7astyp3jt--