All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Tomi Valkeinen <tomba@kernel.org>
Cc: 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,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	kernel@collabora.com
Subject: omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive)
Date: Tue, 12 Jan 2021 17:24:54 +0100	[thread overview]
Message-ID: <20210112162454.hfzj5bxy7e6zlccl@earth.universe> (raw)
In-Reply-To: <4b39c036-fb70-4a5b-ddda-08ce2f0a6db5@kernel.org>

[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]

[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 :)

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

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Sebastian Reichel <sebastian.reichel@collabora.com>
To: Tomi Valkeinen <tomba@kernel.org>
Cc: 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,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	kernel@collabora.com, Sam Ravnborg <sam@ravnborg.org>
Subject: omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive)
Date: Tue, 12 Jan 2021 17:24:54 +0100	[thread overview]
Message-ID: <20210112162454.hfzj5bxy7e6zlccl@earth.universe> (raw)
In-Reply-To: <4b39c036-fb70-4a5b-ddda-08ce2f0a6db5@kernel.org>


[-- Attachment #1.1: Type: text/plain, Size: 2367 bytes --]

[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 :)

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

-- Sebastian

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2021-01-12 16:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  0:55 linux-next: build failure after merge of the drm tree Stephen Rothwell
2021-01-08  0:55 ` Stephen Rothwell
2021-01-08  1:25 ` Stephen Rothwell
2021-01-08  1:25   ` [Intel-gfx] " Stephen Rothwell
2021-01-08  1:25   ` Stephen Rothwell
2021-01-08 11:24   ` [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive Sebastian Reichel
2021-01-08 11:24     ` Sebastian Reichel
2021-01-08 19:58     ` Sam Ravnborg
2021-01-08 19:58       ` Sam Ravnborg
2021-01-12 12:02       ` Sebastian Reichel
2021-01-12 12:02         ` Sebastian Reichel
2021-01-12 13:10         ` Tomi Valkeinen
2021-01-12 13:10           ` Tomi Valkeinen
2021-01-12 16:24           ` Sebastian Reichel [this message]
2021-01-12 16:24             ` omapfb removal (was: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive) Sebastian Reichel
2021-01-12 16:29             ` Laurent Pinchart
2021-01-12 16:29               ` Laurent Pinchart
2021-01-10 23:56   ` linux-next: build failure after merge of the drm tree Stephen Rothwell
2021-01-10 23:56     ` [Intel-gfx] " Stephen Rothwell
2021-01-10 23:56     ` Stephen Rothwell
2021-01-18  0:59     ` Stephen Rothwell
2021-01-18  0:59       ` [Intel-gfx] " Stephen Rothwell
2021-01-18  0:59       ` Stephen Rothwell
2021-01-18  1:06       ` Dave Airlie
2021-01-18  1:06         ` [Intel-gfx] " Dave Airlie
2021-01-18  1:06         ` Dave Airlie
2021-01-20 12:12         ` Daniel Vetter
2021-01-20 12:12           ` [Intel-gfx] " Daniel Vetter
2021-01-20 12:12           ` Daniel Vetter
2021-01-20 20:44           ` Stephen Rothwell
2021-01-20 20:44             ` [Intel-gfx] " Stephen Rothwell
2021-01-20 20:44             ` Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210112162454.hfzj5bxy7e6zlccl@earth.universe \
    --to=sebastian.reichel@collabora.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kernel@collabora.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=tomba@kernel.org \
    --cc=tomi.valkeinen@ideasonboard.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.