Message ID | 20221116-s905x_spi_ili9486-v3-3-59c6b58cbfe3@baylibre.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | Make ILI9486 driver working with 16-bits SPI controllers | expand |
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); >
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); >> >
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,
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.
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);
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(+)