[v3,3/3] drm/tiny: ili9486: remove conflicting framebuffers

Message ID 20221116-s905x_spi_ili9486-v3-3-59c6b58cbfe3@baylibre.com
State New
Headers
Series Make ILI9486 driver working with 16-bits SPI controllers |

Commit Message

Carlo Caione Dec. 6, 2022, 8:34 a.m. UTC
  For platforms using simplefb / efifb, call
drm_aperture_remove_framebuffers() to remove the conflicting
framebuffer.

Signed-off-by: Carlo Caione <ccaione@baylibre.com>
---
 drivers/gpu/drm/tiny/ili9486.c | 5 +++++
 1 file changed, 5 insertions(+)
  

Comments

Neil Armstrong Dec. 6, 2022, 9:41 a.m. UTC | #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 <ccaione@baylibre.com>
> ---
>   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 Dec. 6, 2022, 9:52 a.m. UTC | #2
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 <ccaione@baylibre.com>
>> ---
>>   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
  
Carlo Caione Dec. 6, 2022, 1 p.m. UTC | #3
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,
  
Javier Martinez Canillas Dec. 6, 2022, 2:14 p.m. UTC | #4
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.
  

Patch

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);