Re: [PATCH RFC] drm/vc4: hdmi: Fix connector detect logic

[Stefan Wahren <stefan.wahren@i2se.com>]

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@kernel.org>
>>>>>> Reported-by: Ojaswin Mujoo <ojaswin98@gmail.com>
>>>>>> Fixes: 6800234ceee0 ("drm/vc4: hdmi: Convert to gpiod")
>>>>>> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> I already sent this patch last week:
>>>>>
>>>>> https://lore.kernel.org/dri-devel/20210628124257.140453-3-maxime@cerno.tech/
>>>> 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

[1] - https://www.spinics.net/lists/arm-kernel/msg905208.html

>
> Maxime