Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 17 Feb 2020 22:08:52 +0100
From:   Boris Brezillon <boris.brezillon@collabora.com>
To:     Dominik Brodowski <linux@dominikbrodowski.net>
Cc:     narmstrong@baylibre.com, laurent.pinchart@ideasonboard.com,
        jernej.skrabec@siol.net, jonas@kwiboo.se,
        linux-kernel@vger.kernel.org
Subject: Re: drm/bridge and lockup on boot
Message-ID: <20200217220852.55cbac43@collabora.com>
In-Reply-To: <20200217200942.GA2433@light.dominikbrodowski.net>
References: <20200217200942.GA2433@light.dominikbrodowski.net>
Organization: Collabora
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 17 Feb 2020 21:09:42 +0100
Dominik Brodowski <linux@dominikbrodowski.net> wrote:

> On my old Dell XPS 13 laptop with
> 
> 00:00.0 Host bridge: Intel Corporation Broadwell-U Host Bridge -OPI (rev 09)
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller])
> 
> booting 5.6-rc1 and -rc2 fails after the dmesg line
> 
> 	fb0: switching to inteldrmfb from simple
> 
> while the next lines should be something like (v5.5):
> 
> 	Console: switching to colour dummy device 80x25
> 	i915 0000:00:02.0: vgaarb: deactivate vga console
> 	[drm] ACPI BIOS requests an excessive sleep of 25000 ms, using 1500 ms instead
> 	[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> 	[drm] Driver supports precise vblank timestamp query.
> 	i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem
> 
> A git bisect lead to
> 
> 	commit b86d895524ab ("drm/bridge: Add an ->atomic_check() hook")

This commit has been reverted: you should ignore any failures between
b86d895524ab ("drm/bridge: Add an ->atomic_check() hook") and
099126352303 ("Revert "drm/bridge: Add a drm_bridge_state object").

> 
> as the first bad commit, as unlikely as that sounds. f7619a58ef92 is good,
> as is bf046007641a, and 3cacb2086e41 is definitely broken on my setup.
> Any ideas?
> 
> Oh, and this might be the same issue as reported here:
> 
> 	https://lore.kernel.org/lkml/99fb887f-4a1b-6c15-64a6-9d089773cdd4@4net.rs/
> 
> though I do not see such a warning, but nothing new once the line "fb0: switching
> to inteldrmfb from simple" is printed.
> 
> Thanks,
> 	Dominik