[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <i5sad34yvpcdavj76imjeifdz72ah3ue6mi6g6tf4cxc54yzla@gzhfmogh3oar>
Date: Thu, 27 Apr 2023 11:31:29 +0200
From: Maxime Ripard <maxime@...no.tech>
To: Roman Beranek <me@...y.cz>
Cc: Chen-Yu Tsai <wens@...e.org>, David Airlie <airlied@...il.com>,
Daniel Vetter <daniel@...ll.ch>,
Jernej Skrabec <jernej.skrabec@...il.com>,
Samuel Holland <samuel@...lland.org>,
Frank Oltmanns <frank@...manns.dev>,
Icenowy Zheng <icenowy@...c.io>, Ondrej Jirman <megi@....cz>,
dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 4/7] arm64: dts: allwinner: a64: reset pll-video0 rate
Hi,
I'm not sure I understand what you're doing here
On Thu, Apr 27, 2023 at 11:16:08AM +0200, Roman Beranek wrote:
> With pll-mipi as its source clock, the exact rate to which TCON0's data
> clock can be set to is constrained by the current rate of pll-video0.
What in the TCON exactly is constrained by pll-video0 rate?
> Unless changed on a request of another consumer, the rate of pll-video0
> is left as inherited from the bootloader.
>
> The default rate on reset is 297 MHz, a value preferable to what it is
> later set to in u-boot (294 MHz). This happens unintentionally though,
> as u-boot, for the sake of simplicity, rounds the rate requested by DE2
> driver (297 MHz) to 6 MHz steps.
>
> Reset the PLL to its default rate of 297 MHz.
>
> Signed-off-by: Roman Beranek <me@...y.cz>
If the driver depends on the value being the reset value, then that's
the issue we should fix, either by reading the clock rate and adjusting
to it, or enforcing the rate we expect in the TCON driver.
Maxime
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists