Hi Stefan,
On Wed, Jul 07, 2021 at 08:01:50PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 07.07.21 um 15:11 schrieb Maxime Ripard:
> > On Tue, Jul 06, 2021 at 05:45:27PM +0200, Stefan Wahren wrote:
> >> Hi Maxime,
> >>
> >> Am 06.07.21 um 15:21 schrieb Maxime Ripard:
> >>> Hi Stefan,
> >>>
> >>> On Tue, Jul 06, 2021 at 12:48:05PM +0200, Stefan Wahren wrote:
> >>>> Am 06.07.21 um 11:58 schrieb Maxime Ripard:
> >>>>> Hi,
> >>>>>
> >>>>> On Mon, Jul 05, 2021 at 11:36:34PM +0200, Stefan Wahren wrote:
> >>>>>> Commit "drm/vc4: hdmi: Convert to gpiod" changes the behavior of
> >>>>>> vc4_hdmi_connector_detect() which results into CPU hangs in case there
> >>>>>> is no HDMI connected. Let's restore the old behavior.
> >>>>>>
> >>>>>> Reported-by: Nathan Chancellor <nathan@xxxxxxxxxx>
> >>>>>> Reported-by: Ojaswin Mujoo <ojaswin98@xxxxxxxxx>
> >>>>>> Fixes: 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod")
> >>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@xxxxxxxx>
> >>>>> I already sent this patch last week:
> >>>>>
> >>>>> https://lore.kernel.org/dri-devel/20210628124257.140453-3-maxime@xxxxxxxxxx/
> >>>> oops, i only looked in the July archive.
> >>>>
> >>>>> I'm not entirely sure how this could create a CPU hang though. Withouth
> >>>>> this patch, if the HPD GPIO is low, we would first try to retrieve the
> >>>>> EDID, and then if it doesn't we would read the hotplug register.
> >>>> Yes, the real issue has been revealed by the original change and this
> >>>> patch only "hides" it again.
> >>>>> The first is using a separate i2c controller (and even if it was in the
> >>>>> same power domain, we have the pm_runtime_resume call), and the register
> >>>>> read should be fine too?
> >>>> Sorry, i don't have a clue and time for further investigations.
> >>>>
> >>>> Does it mean, you are not able to reproduce this issue?
> >>> On next-20210706 at least it works fine for me without an HDMI monitor
> >>> connected, yes:
> >> which configuration do you use? Did you tried arm/multi_v7_defconfig?
> >>
> >> I tried yesterday mainline ("a180bd1d7e16173d965b263c5a536aa40afa2a2a")
> >> with multi_v7_defconfig and the issue was there.
> > I can't boot multi_v7_defconfig on my setup, but I just tested multi_v7
> > + a few options (UART, ethernet) built-in to be able to boot, and I
> > can't reproduce what you're seeing. It boots just fine without any
> > monitor attached.
>
> not sure how do you boot, but USB mass storage boot for Raspberry Pi 3 B
> Plus is broken since Linux 5.13 with multi_v7_defconfig [1]. But this is
> a completely different issue.
>
> To be more exact the hang in this case happens a few seconds after the
> UART console (ttyS1) becomes available.
>
> Here is my setup:
>
> Raspberry Pi 3 Plus
> DTS from mainline tree
> arm/multi_v7_defconfig
> Boot from SD card
> No U-Boot
> Rootfs: Raspberry Pi OS 32bit (May 7th 2021)
> VC4 firmware: 2021-04-30T13:47:07
>
> Maybe next week, i have a little bit more time
A bit of an update, there's other users that reported it on 5.10, and it
turns out it seems to be (partially at least) related to the options set
in config.txt.
The tracking issue is there:
https://github.com/raspberrypi/linux/issues/4457
It seems like the reason it was working for me all along is that I had
hdmi_force_hotplug set, and it looks like it makes the issue go away.
It's not clear at this point why.
Maxime
Attachment:
signature.asc
Description: PGP signature
