Received-SPF: pass (google.com: domain of linux-kernel+bounces-211691-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Wed, 12 Jun 2024 16:42:20 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?= <mans@mansr.com>,
	Frank Oltmanns <frank@oltmanns.dev>, stable@vger.kernel.org,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Guido =?iso-8859-1?Q?G=FCnther?= <agx@sigxcpu.org>,
	Purism Kernel Team <kernel@puri.sm>, Ondrej Jirman <megi@xff.cz>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jessica Zhang <quic_jesszhan@quicinc.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>, linux-clk@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and
 maximum rate
Message-ID: <2024061208-trapping-diminish-fda6@gregkh>
References: <20240310-pinephone-pll-fixes-v4-0-46fc80c83637@oltmanns.dev>
 <20240310-pinephone-pll-fixes-v4-1-46fc80c83637@oltmanns.dev>
 <yw1xo78z8ez0.fsf@mansr.com>
 <c4c1229c-1ed3-4b6e-a53a-e1ace2502ded@oltmanns.dev>
 <yw1x4jap90va.fsf@mansr.com>
 <yw1xo78w73uv.fsf@mansr.com>
 <8be80682-067a-4685-9830-cfed0287e617@leemhuis.info>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8be80682-067a-4685-9830-cfed0287e617@leemhuis.info>

On Wed, Jun 12, 2024 at 03:28:01PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 23.05.24 20:58, M?ns Rullg?rd wrote:
> > M?ns Rullg?rd <mans@mansr.com> writes:
> >> Frank Oltmanns <frank@oltmanns.dev> writes:
> >>> 21.05.2024 15:43:10 M?ns Rullg?rd <mans@mansr.com>:
> >>>> Frank Oltmanns <frank@oltmanns.dev> writes:
> >>>>
> >>>>> The Allwinner SoC's typically have an upper and lower limit for their
> >>>>> clocks' rates. Up until now, support for that has been implemented
> >>>>> separately for each clock type.
> >>>>>
> >>>>> Implement that functionality in the sunxi-ng's common part making use of
> >>>>> the CCF rate liming capabilities, so that it is available for all clock
> >>>>> types.
> >>>>>
> >>>>> Suggested-by: Maxime Ripard <mripard@kernel.org>
> >>>>> Signed-off-by: Frank Oltmanns <frank@oltmanns.dev>
> >>>>> Cc: stable@vger.kernel.org
> >>>>> ---
> >>>>> drivers/clk/sunxi-ng/ccu_common.c | 19 +++++++++++++++++++
> >>>>> drivers/clk/sunxi-ng/ccu_common.h |? 3 +++
> >>>>> 2 files changed, 22 insertions(+)
> >>>>
> >>>> This just landed in 6.6 stable, and it broke HDMI output on an A20 based
> >>>> device, the clocks ending up all wrong as seen in this diff of
> >>>> /sys/kernel/debug/clk/clk_summary:
> > [...]
> > 
> >>>> Reverting this commit makes it work again.
> >>> Thank you for your detailed report!
> > [...]
> > It turns out HDMI output is broken in v6.9 for a different reason.
> > However, this commit (b914ec33b391 clk: sunxi-ng: common: Support
> > minimum and maximum rate) requires two others as well in order not
> > to break things on the A20:
> > 
> > cedb7dd193f6 drm/sun4i: hdmi: Convert encoder to atomic
> > 9ca6bc246035 drm/sun4i: hdmi: Move mode_set into enable
> > 
> > With those two (the second depends on the first) cherry-picked on top of
> > v6.6.31, the HDMI output is working again.  Likewise on v6.8.10.
> 
> They from what I can see are not yet in 6.6.y or on their way there (6.8
> is EOL now). Did anyone ask Greg to pick this up? If not: M?nsm could
> you maybe do that? CCing him on a reply and asking is likely enough if
> both changes apply cleanly.

Both now queued up, thanks.

greg k-h