For platforms using simplefb / efifb, call
drm_aperture_remove_framebuffers() to remove the conflicting
framebuffer.
Signed-off-by: Carlo Caione <[email protected]>
---
drivers/gpu/drm/tiny/ili9486.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 14a9e6ad2d15..6fd4d42437fd 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -14,6 +14,7 @@
#include <video/mipi_display.h>
+#include <drm/drm_aperture.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_drv.h>
#include <drm/drm_fb_helper.h>
@@ -238,6 +239,10 @@ static int ili9486_probe(struct spi_device *spi)
if (ret)
return ret;
+ ret = drm_aperture_remove_framebuffers(false, &ili9486_driver);
+ if (ret)
+ return ret;
+
drm_mode_config_reset(drm);
ret = drm_dev_register(drm, 0);
--
b4 0.10.1
Hi Carlo,
On 06/12/2022 09:34, Carlo Caione wrote:
> For platforms using simplefb / efifb, call
> drm_aperture_remove_framebuffers() to remove the conflicting
> framebuffer.
Conflicting framebuffer on the SPI display ? How is that possible ?
The meson_drm should already do this, no ?
Neil
>
> Signed-off-by: Carlo Caione <[email protected]>
> ---
> drivers/gpu/drm/tiny/ili9486.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
> index 14a9e6ad2d15..6fd4d42437fd 100644
> --- a/drivers/gpu/drm/tiny/ili9486.c
> +++ b/drivers/gpu/drm/tiny/ili9486.c
> @@ -14,6 +14,7 @@
>
> #include <video/mipi_display.h>
>
> +#include <drm/drm_aperture.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_drv.h>
> #include <drm/drm_fb_helper.h>
> @@ -238,6 +239,10 @@ static int ili9486_probe(struct spi_device *spi)
> if (ret)
> return ret;
>
> + ret = drm_aperture_remove_framebuffers(false, &ili9486_driver);
> + if (ret)
> + return ret;
> +
> drm_mode_config_reset(drm);
>
> ret = drm_dev_register(drm, 0);
>
Hi
Am 06.12.22 um 10:41 schrieb Neil Armstrong:
> Hi Carlo,
>
> On 06/12/2022 09:34, Carlo Caione wrote:
>> For platforms using simplefb / efifb, call
>> drm_aperture_remove_framebuffers() to remove the conflicting
>> framebuffer.
>
> 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.
Best regards
Thomas
>
> The meson_drm should already do this, no ?
>
> Neil
>
>>
>> Signed-off-by: Carlo Caione <[email protected]>
>> ---
>> drivers/gpu/drm/tiny/ili9486.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/tiny/ili9486.c
>> b/drivers/gpu/drm/tiny/ili9486.c
>> index 14a9e6ad2d15..6fd4d42437fd 100644
>> --- a/drivers/gpu/drm/tiny/ili9486.c
>> +++ b/drivers/gpu/drm/tiny/ili9486.c
>> @@ -14,6 +14,7 @@
>> #include <video/mipi_display.h>
>> +#include <drm/drm_aperture.h>
>> #include <drm/drm_atomic_helper.h>
>> #include <drm/drm_drv.h>
>> #include <drm/drm_fb_helper.h>
>> @@ -238,6 +239,10 @@ static int ili9486_probe(struct spi_device *spi)
>> if (ret)
>> return ret;
>> + ret = drm_aperture_remove_framebuffers(false, &ili9486_driver);
>> + if (ret)
>> + return ret;
>> +
>> drm_mode_config_reset(drm);
>> ret = drm_dev_register(drm, 0);
>>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
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
On 12/6/22 10:52, Thomas Zimmermann wrote:
> Hi
>
> Am 06.12.22 um 10:41 schrieb Neil Armstrong:
>> Hi Carlo,
>>
>> On 06/12/2022 09:34, Carlo Caione wrote:
>>> For platforms using simplefb / efifb, call
>>> drm_aperture_remove_framebuffers() to remove the conflicting
>>> framebuffer.
>>
>> 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.
>
Agree.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat