On Tue, Feb 10, 2026 at 5:34 PM Luca Leonardo Scorcia <[email protected]> wrote: > > If a device has a framebuffer available it might be already used as > display by simple-framebuffer or simpledrm when mediatek-drm is probed. > This is actually helpful when porting to a new device as > framebuffers are simple to setup in device trees and fbcon can be > used to monitor the kernel boot process. > > When drm-mediatek loads a new fb device is initialized, however > fbcon remains attached to the initial framebuffer which is no longer > connected to the actual display - the early fb is never removed. > > We can gracefully transition from framebuffer handling to drm-managed > display by calling aperture_remove_all_conflicting_devices as we probe > mediatek-drm. This takes care of unloading other fb devices/drivers > and disconnects fbcon which then automatically reconnects to > mediatekdrmfb as soon as it's available. > > Signed-off-by: Luca Leonardo Scorcia <[email protected]> > --- > This patch has been tested on Xiaomi Mi Smart Clock, however > I'd like to get some feedback from more knowledgeable people, > especially about those points: > 1. Is aperture support on mtk-drm desired at all? > 2. mtk-drm does not know about the fb address therefore as far > as I can see we can't use the more specific function > aperture_remove_conflicting_devices. This means that all generic > aperture drivers will be unloaded. It might not be a real world issue > as I can't see why one might want to load mtk-drm while keeping > other aperture device drivers active, but my experience is very limited.
This is pretty much what all other platform drivers do. So that's fine. > Thanks! > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > index a94c51a83261..17e45b93fe49 100644 > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c > @@ -4,6 +4,7 @@ > * Author: YT SHEN <[email protected]> > */ > > +#include <linux/aperture.h> > #include <linux/component.h> > #include <linux/module.h> > #include <linux/of.h> > @@ -1116,6 +1117,11 @@ static int mtk_drm_probe(struct platform_device *pdev) > if (!private->all_drm_private) > return -ENOMEM; > > + /* Remove framebuffer owners, this will release fbcon if active */ > + ret = aperture_remove_all_conflicting_devices(DRIVER_NAME); > + if (ret < 0) > + dev_err(dev, "Failed to remove conflicting aperture devices > (%d)", ret); > + I believe this could be in mtk_drm_bind() just before drm_dev_register(). The idea is you want to kick out the existing framebuffer as late as possible to reduce the time the screen is unresponsive. ChenYu > /* Bringup ovl_adaptor */ > if (mtk_drm_find_mmsys_comp(private, DDP_COMPONENT_DRM_OVL_ADAPTOR)) { > ovl_adaptor = platform_device_register_data(dev, > "mediatek-disp-ovl-adaptor", > -- > 2.43.0 > >
