[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ec0204d-ca4c-afd9-33d6-1ebaaaf6b144@baylibre.com>
Date: Tue, 6 Dec 2022 14:00:51 +0100
From: Carlo Caione <ccaione@...libre.com>
To: Thomas Zimmermann <tzimmermann@...e.de>, neil.armstrong@...aro.org,
Daniel Vetter <daniel@...ll.ch>,
Jerome Brunet <jbrunet@...libre.com>,
David Airlie <airlied@...il.com>,
Kamlesh Gurudasani <kamlesh.gurudasani@...il.com>,
Mark Brown <broonie@...nel.org>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
Kevin Hilman <khilman@...libre.com>
Cc: linux-amlogic@...ts.infradead.org, dri-devel@...ts.freedesktop.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] drm/tiny: ili9486: remove conflicting framebuffers
On 06/12/2022 10:52, Thomas Zimmermann wrote:
>> Conflicting framebuffer on the SPI display ? How is that possible ?
>
> Calling drm_aperture_remove_framebuffers() is only required if the
> graphics card may have been pre-initialized by the system, such as a
> VGA-compatible card on a PC.
>
> Could the SPI display have been initialized by the firmware? If not, the
> call should be left out.
What's happening on this board is that the builtin simpledrm driver is
creating fb0 backed by the framebuffer prepared by u-boot / grub, and
this the framebuffer being used by fbcon at early boot.
When the ILI9486 DRM driver is probed later during boot a second
framebuffer is created (fb1) and when fb0 is destroyed, fbcon still
remains attached to a non-existent framebuffer, so the user is left in
the dark.
What this patch is doing is that when the ILI driver is probed, fb0 is
destroyed and a new DRM-backed fb0 is created by the ILI DRM driver that
can be used by fbcon, so the user can correctly see the console on the
SPI display.
Cheers,
--
Carlo Caione
Powered by blists - more mailing lists