Re: [git pull] drm for 5.14-rc1

From: Michael Stapelberg <michael@stapelberg.ch>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Maxime Ripard <maxime@cerno.tech>, Emma Anholt <emma@anholt.net>,
	 Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	 Felix Kuehling <felix.kuehling@amd.com>,
	Dave Airlie <airlied@gmail.com>
Subject: Re: [git pull] drm for 5.14-rc1
Date: Sat, 18 Sep 2021 22:13:27 +0200	[thread overview]
Message-ID: <CANnVG6mOWLeLHtFrAA9zWzZRtZ6+E1EYYW5+ekwC-=rAEcB71w@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjuN8afLz-QnefNgt2qKAOY7cez_63oAkdDmTu4Wscv_g@mail.gmail.com>

On Sat, 18 Sept 2021 at 21:24, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sat, Sep 18, 2021 at 2:18 AM Michael Stapelberg
> <michael@stapelberg.ch> wrote:
> >
> > torvalds at linux-foundation.org (Linus Torvalds) writes:
> > > Did I fix it up correctly? Who knows. The code makes more sense to me
> > > now and seems valid. But I really *really* want to stress how locking
> > > is important.
> >
> > As far as I can tell, this merge conflict resolution made my Raspberry
> > Pi 3 hang on boot.
>
> Ok, that's a different merge issue than the locking one (which is
> about the amd ttm code).

Ah, my apologies for getting these mixed up!

>
> But the VC4 driver did have changes close to each other in the hdmi
> detection and clock setting code.
>
> And it doesn't seem to be just RPi3, there was a report back a couple
> of weeks ago about RPi4 also having regressed (with an Ubuntu
> install). That one was an oops in vc4_hdmi_audio_prepare(). I don't
> know if that got resolved, I heard nothing about it after the report.
>
> So there's something seriously wrong in VC4 space.
>
> The main issue seems to be the runtime power management changes. As
> far as I can tell, the commits that didn't come in through that drm
> pull were these two
>
>   9984d6664ce9 ("drm/vc4: hdmi: Make sure the controller is powered in detect")
>   411efa18e4b0 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm")
>
> Michael - do things work if you revert those two (sadly, they don't
> revert cleanly exactly _because_ of the other changes in the same
> area)?

Reverting only 9984d6664ce9 is not sufficient, but reverting both
9984d6664ce9 and 411efa18e4b0 does indeed make my Raspberry Pi 3 boot
again!

Thanks for identifying the faulty commits. Please let me know if any
of y’all want me to test anything else in the process to get this
fixed for the next kernel release (or perhaps even a minor release)?

>
> Maxime?
>
>              Linus

-- 
Best regards,
Michael