Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
error: the following would cause module name conflict:
drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
drivers/gpu/drm/panel/panel-dsi-cm.ko
Maybe caused by commit
cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
I have used the drm tree from next-20210107 for today.
--
Cheers,
Stephen Rothwell
Hi all,
On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell <[email protected]> wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> error: the following would cause module name conflict:
> drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> drivers/gpu/drm/panel/panel-dsi-cm.ko
>
> Maybe caused by commit
>
> cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
>
> I have used the drm tree from next-20210107 for today.
This has affected the drm-misc tree as well (since it merged in the drm
tree).
I have used the drm-misc tree from next-20210107 for today.
--
Cheers,
Stephen Rothwell
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 <[email protected]>
Signed-off-by: Sebastian Reichel <[email protected]>
---
Laurent introduced and fixed the same issue for the other panels and
this simply replicates the same solution for DSI command mode panel.
---
drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
index 744416dc530e..384d74a126dc 100644
--- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
+++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
@@ -43,6 +43,7 @@ config FB_OMAP2_PANEL_DPI
config FB_OMAP2_PANEL_DSI_CM
tristate "Generic DSI Command Mode Panel"
depends on BACKLIGHT_CLASS_DEVICE
+ depends on DRM_PANEL_DSI_CM = n
help
Driver for generic DSI command mode panels.
--
2.29.2
Hi Sebatian,
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 <[email protected]>
> Signed-off-by: Sebastian Reichel <[email protected]>
For a backport this looks good:
Acked-by: Sam Ravnborg <[email protected]>
But why is it it we need omapfb at all when we have omapdrm?
Can we sunset all or some parts of omap support in video/?
If not, what is missing to do so.
Sam
> ---
> Laurent introduced and fixed the same issue for the other panels and
> this simply replicates the same solution for DSI command mode panel.
> ---
> drivers/video/fbdev/omap2/omapfb/displays/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> index 744416dc530e..384d74a126dc 100644
> --- a/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/displays/Kconfig
> @@ -43,6 +43,7 @@ config FB_OMAP2_PANEL_DPI
> config FB_OMAP2_PANEL_DSI_CM
> tristate "Generic DSI Command Mode Panel"
> depends on BACKLIGHT_CLASS_DEVICE
> + depends on DRM_PANEL_DSI_CM = n
> help
> Driver for generic DSI command mode panels.
>
> --
> 2.29.2
Hi all,
On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > error: the following would cause module name conflict:
> > drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> > drivers/gpu/drm/panel/panel-dsi-cm.ko
> >
> > Maybe caused by commit
> >
> > cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> >
> > I have used the drm tree from next-20210107 for today.
>
> This has affected the drm-misc tree as well (since it merged in the drm
> tree).
>
> I have used the drm-misc tree from next-20210107 for today.
And now the drm-intel tree.
I have used the drm-intel tree from next-20210108 for today.
--
Cheers,
Stephen Rothwell
[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 <[email protected]>
> > Signed-off-by: Sebastian Reichel <[email protected]>
>
> For a backport this looks good:
> Acked-by: Sam Ravnborg <[email protected]>
Thanks.
> 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.
> 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
-- Sebastian
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 <[email protected]>
>>> Signed-off-by: Sebastian Reichel <[email protected]>
>>
>> For a backport this looks good:
>> Acked-by: Sam Ravnborg <[email protected]>
>
> 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
[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
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
Hi all,
On Mon, 11 Jan 2021 10:56:54 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell <[email protected]> wrote:
> > >
> > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > >
> > > error: the following would cause module name conflict:
> > > drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> > > drivers/gpu/drm/panel/panel-dsi-cm.ko
> > >
> > > Maybe caused by commit
> > >
> > > cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> > >
> > > I have used the drm tree from next-20210107 for today.
> >
> > This has affected the drm-misc tree as well (since it merged in the drm
> > tree).
> >
> > I have used the drm-misc tree from next-20210107 for today.
>
> And now the drm-intel tree.
>
> I have used the drm-intel tree from next-20210108 for today.
This is still affecting the drm and drm-intel trees.
--
Cheers,
Stephen Rothwell
On Mon, 18 Jan 2021 at 10:59, Stephen Rothwell <[email protected]> wrote:
>
> Hi all,
>
> On Mon, 11 Jan 2021 10:56:54 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell <[email protected]> wrote:
> > >
> > > On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell <[email protected]> wrote:
> > > >
> > > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > > > failed like this:
> > > >
> > > > error: the following would cause module name conflict:
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> > > > drivers/gpu/drm/panel/panel-dsi-cm.ko
> > > >
> > > > Maybe caused by commit
> > > >
> > > > cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> > > >
> > > > I have used the drm tree from next-20210107 for today.
> > >
> > > This has affected the drm-misc tree as well (since it merged in the drm
> > > tree).
> > >
> > > I have used the drm-misc tree from next-20210107 for today.
> >
> > And now the drm-intel tree.
> >
> > I have used the drm-intel tree from next-20210108 for today.
>
> This is still affecting the drm and drm-intel trees.
I think the fix for this is in drm-misc-next, Maarten can you send me
a -next PR to fix this?
Dave.
On Mon, Jan 18, 2021 at 2:06 AM Dave Airlie <[email protected]> wrote:
>
> On Mon, 18 Jan 2021 at 10:59, Stephen Rothwell <[email protected]> wrote:
> >
> > Hi all,
> >
> > On Mon, 11 Jan 2021 10:56:54 +1100 Stephen Rothwell <[email protected]> wrote:
> > >
> > > On Fri, 8 Jan 2021 12:25:40 +1100 Stephen Rothwell <[email protected]> wrote:
> > > >
> > > > On Fri, 8 Jan 2021 11:55:18 +1100 Stephen Rothwell <[email protected]> wrote:
> > > > >
> > > > > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > > > > failed like this:
> > > > >
> > > > > error: the following would cause module name conflict:
> > > > > drivers/video/fbdev/omap2/omapfb/displays/panel-dsi-cm.ko
> > > > > drivers/gpu/drm/panel/panel-dsi-cm.ko
> > > > >
> > > > > Maybe caused by commit
> > > > >
> > > > > cf64148abcfd ("drm/panel: Move OMAP's DSI command mode panel driver")
> > > > >
> > > > > I have used the drm tree from next-20210107 for today.
> > > >
> > > > This has affected the drm-misc tree as well (since it merged in the drm
> > > > tree).
> > > >
> > > > I have used the drm-misc tree from next-20210107 for today.
> > >
> > > And now the drm-intel tree.
> > >
> > > I have used the drm-intel tree from next-20210108 for today.
> >
> > This is still affecting the drm and drm-intel trees.
>
> I think the fix for this is in drm-misc-next, Maarten can you send me
> a -next PR to fix this?
I've pulled drm-misc-next into drm-next now, so as long as all other
drm trees are merged after drm, this should be solved now.
drm-intel-next also has their msm build breakage fixed (I acked the
patch already), so hopefully we should be all clean again.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Hi Daniel,
On Wed, 20 Jan 2021 13:12:21 +0100 Daniel Vetter <[email protected]> wrote:
>
> I've pulled drm-misc-next into drm-next now, so as long as all other
> drm trees are merged after drm, this should be solved now.
> drm-intel-next also has their msm build breakage fixed (I acked the
> patch already), so hopefully we should be all clean again.
Thanks.
--
Cheers,
Stephen Rothwell