linux-kernel - Re: [PATCH 5/5] drm/sun4i: Run the mixer clock at 297 MHz on V3s

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aGUi8ot1-0WaReyp@collins>
Date: Wed, 2 Jul 2025 14:15:46 +0200
From: Paul Kocialkowski <paulk@...-base.io>
To: Maxime Ripard <mripard@...nel.org>
Cc: linux-media@...r.kernel.org, devicetree@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
	linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, linux-gpio@...r.kernel.org,
	Yong Deng <yong.deng@...ewell.com>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
	Jernej Skrabec <jernej.skrabec@...il.com>,
	Samuel Holland <samuel@...lland.org>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...nel.org>,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
	Linus Walleij <linus.walleij@...aro.org>,
	Icenowy Zheng <icenowy@...c.xyz>,
	Andre Przywara <andre.przywara@....com>
Subject: Re: [PATCH 5/5] drm/sun4i: Run the mixer clock at 297 MHz on V3s

Hi Maxime,

Le Wed 02 Jul 25, 13:36, Maxime Ripard a écrit :
> On Tue, Jul 01, 2025 at 10:11:24PM +0200, Paul Kocialkowski wrote:
> > The DE mixer clock is currently set to run at 150 MHz, while the
> > Allwinner BSP configures it at 300 MHz and other platforms typically
> > run at 297 MHz.
> > 
> > 150 MHz appears to be enough given the restricted graphics capabilities
> > of the SoC (with a work area of only 1024x1024). However it typically
> > causes the DE clock to be parented to the periph0 pll instead of the
> > video PLL.
> > 
> > While this should generally not be a concern, it appears (based on
> > experimentation) that both the DE and TCON clocks need to be parented
> > to the same PLL for these units to work. While we cannot represent this
> > constraint in the clock driver, it appears that the TCON clock will
> > often get parented to the video pll (typically running at 297 MHz for
> > the CSI units needs), for instance when driving displays with a 33 MHz
> > pixel clock (33 being a natural divider of 297).
> > 
> > Running the DE clock at 297 MHz will typically result in parenting to
> > the video pll instead of the periph0 pll, thus making the display
> > output functional.
> > 
> > This is all a bit fragile but it solves the issue with displays running
> > at 33 Mhz and brings V3s to use the same frequency as other platforms,
> > making support more unified.
> 
> It's beyond fragile, and doesn't have anything to do with the DRM driver.
> 
> You should set up the clock tree properly in the clock driver, and then
> add NO_REPARENT to the DE clock to make sure it stays that way.

Thanks for the suggestion! I wasn't aware there was a flag to avoid
reparenting, sounds like the most reasonable way to solve this issue then.

I'll send another iteration reworking the clock tree then.

> And then, you can change the clock rate if you want to, but at least you
> don't set a rate and hope that the side effects work your way, and won't
> happen again.

We might as well still change it. To be honest I don't really see why it was
set to 150 MHz in the first place.

Cheers,

Paul

-- 
Paul Kocialkowski,

Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/

Expert in multimedia, graphics and embedded hardware support with Linux.

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)