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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <X/3Oe9HwKe9UFnS1@pendragon.ideasonboard.com>
Date:   Tue, 12 Jan 2021 18:29:47 +0200
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Sebastian Reichel <sebastian.reichel@...labora.com>
Cc:     Tomi Valkeinen <tomba@...nel.org>, Sam Ravnborg <sam@...nborg.org>,
        linux-fbdev@...r.kernel.org,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        kernel@...labora.com
Subject: Re: omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard
 and custom DSI command mode panel driver mutually exclusive)

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