Re: omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive)

From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: Tomi Valkeinen <tomba@kernel.org>,
	Sam Ravnborg <sam@ravnborg.org>,
	linux-fbdev@vger.kernel.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	kernel@collabora.com
Subject: Re: omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive)
Date: Tue, 12 Jan 2021 18:29:47 +0200	[thread overview]
Message-ID: <X/3Oe9HwKe9UFnS1@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20210112162454.hfzj5bxy7e6zlccl@earth.universe>

Hi Sebastian,

On Tue, Jan 12, 2021 at 05:24:54PM +0100, Sebastian Reichel wrote:
> [dropped linux-next from Cc]
> 
> Hi,
> 
> On Tue, Jan 12, 2021 at 03:10:56PM +0200, Tomi Valkeinen wrote:
> > >> But why is it it we need omapfb at all when we have omapdrm?
> > > 
> > > I think there are two reasons omapfb has not been killed yet. One
> > > reason was missing support for manually updated DSI panels, which
> > > have been working since 1 or 2 kernel releases now. The other reason
> > > is some people using it in combination with an out-of-tree PowerVR
> > > kernel driver. There is currently work going on to use a more recent
> > > PowerVR driver based on omapdrm driven by Maemo Leste people.
> > 
> > omapfb also has a custom sysfs API, so applications that depend on it
> > would not work anymore. I don't know if there are such applications, though.
> > 
> > >> Can we sunset all or some parts of omap support in video/?
> > >> If not, what is missing to do so.
> > > 
> > > IDK the exact status of the PowerVR work and have not been using
> > > omapfb myself for years. I don't think there is a reason to rush
> > > this, so my suggestion is removing it in 3 steps giving people
> > > the chance to complain:
> > > 
> > > 1. Add 'depends on EXPERT' to 'FB_OMAP2' and add deprecation notice
> > >    referencing omapdrm in help text in 5.12
> > > 2. Add 'depends on BROKEN' in 5.13
> > > 3. Drop drivers/video/fbdev/omap2 afterwards
> > 
> > I'd love to remove omapfb, but I also fear that there are still people
> > using it. We can try the above sequence, but it's probably better to go
> > slower, as people may not be using the latest kernels.
> 
> I thought about this again and I think the best option is to rename
> CONFIG_FB_OMAP2 to something like CONFIG_FB_OMAP2_DEPRECATED and
> update the help text. That way anyone with CONFIG_FB_OMAP2 in
> their .config will definitely notice the change when upgrading to
> a newer kernel, but can easily fix it temporarily. Help text could
> be
> 
> "This driver will be removed in 2022, please switch to omapdrm."
> 
> and no other intermediate steps are required that way :)

The plan looks good to me.

> But while looking through CONFIG_FB_OMAP2 references I noticed there
> is also a V4L2 driver (CONFIG_VIDEO_OMAP2_VOUT), which seems to
> only work with omapfb. IIUIC that driver provides display overlays
> to V4L. I guess on omapdrm V4L can use DRM planes instead and no
> driver is needed (i.e. this driver could just go away with omapfb)?

One feature that the omapfb2 and the omap-vout drivers provide is
rotation support with VRFB on OMAP3. I haven't moved to omapdrm on an
old project for this reason. It should be possible to implement rotation
support in omapdrm, but I'm not aware of any effort in that direction.

-- 
Regards,

Laurent Pinchart