linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomba@kernel.org>
To: Sebastian Reichel <sebastian.reichel@collabora.com>,
	Sam Ravnborg <sam@ravnborg.org>
Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
	kernel@collabora.com
Subject: Re: [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive
Date: Tue, 12 Jan 2021 15:10:56 +0200	[thread overview]
Message-ID: <4b39c036-fb70-4a5b-ddda-08ce2f0a6db5@kernel.org> (raw)
In-Reply-To: <20210112120246.ujhjyylrlgfrfvig@earth.universe>

Hi,

On 12/01/2021 14:02, Sebastian Reichel wrote:
> [replace Tomi's TI mail address with something working]
> 
> Hi,
> 
> On Fri, Jan 08, 2021 at 08:58:39PM +0100, Sam Ravnborg wrote:
>> Hi Sebastian,
>>
>> On Fri, Jan 08, 2021 at 12:24:41PM +0100, Sebastian Reichel wrote:
>>> Standard DRM panel driver for DSI command mode panel used by omapfb2 is also
>>> available now. Just like the other panels its module name clashes with the
>>> module from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated
>>> omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver
>>> is disabled, and the DRM panel drivers are useless in that case, make the
>>> omapfb2 panel depend on the standard DRM panels being disabled to fix
>>> the name clash.
>>>
>>> Fixes: cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
>>> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
>>> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
>>
>> For a backport this looks good:
>> Acked-by: Sam Ravnborg <sam@ravnborg.org>
> 
> Thanks.

Thanks. I'll push to drm-misc-next, as that's where the commit that
breaks this is.

>> 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 sysfw 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.

 Tomi

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

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210108122540.657501b2@canb.auug.org.au>
2021-01-08 11:24 ` [PATCHv1] video: omapfb2: Make standard and custom DSI command mode panel driver mutually exclusive Sebastian Reichel
2021-01-08 19:58   ` Sam Ravnborg
2021-01-12 12:02     ` Sebastian Reichel
2021-01-12 13:10       ` Tomi Valkeinen [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

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=4b39c036-fb70-4a5b-ddda-08ce2f0a6db5@kernel.org \
    --to=tomba@kernel.org \
    --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=linux-next@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sebastian.reichel@collabora.com \
    --cc=sfr@canb.auug.org.au \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).