There are two drivers for the LCDIF/MXSFB peripheral. If the DRM and fbdev are compiled in, the registration of the second driver fails: mxs-dma 33000000.dma-apbh: initialized mxsfb 30730000.lcdif: 30730000.lcdif supply lcd not found, using dummy regulator mxsfb 30730000.lcdif: initialized Error: Driver 'mxsfb' is already registered, aborting...
Avoid driver name conflict with MXS fbdev driver by renaming the more recently added DRM driver.
Signed-off-by: Stefan Agner stefan@agner.ch --- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c b/drivers/gpu/drm/mxsfb/mxsfb_drv.c index 5cae8db9dcd4..db2935797428 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c @@ -424,7 +424,7 @@ static struct platform_driver mxsfb_platform_driver = { .remove = mxsfb_remove, .id_table = mxsfb_devtype, .driver = { - .name = "mxsfb", + .name = "mxsfb-drm", .of_match_table = mxsfb_dt_ids, }, };
On Tue, Jun 12, 2018 at 11:35 AM, Stefan Agner stefan@agner.ch wrote:
There are two drivers for the LCDIF/MXSFB peripheral. If the DRM and fbdev are compiled in, the registration of the second driver fails: mxs-dma 33000000.dma-apbh: initialized mxsfb 30730000.lcdif: 30730000.lcdif supply lcd not found, using dummy regulator mxsfb 30730000.lcdif: initialized Error: Driver 'mxsfb' is already registered, aborting...
Avoid driver name conflict with MXS fbdev driver by renaming the more recently added DRM driver.
Signed-off-by: Stefan Agner stefan@agner.ch
Yes, this driver name collision is annoying:
Reviewed-by: Fabio Estevam fabio.estevam@nxp.com
On 06/12/2018 06:01 PM, Fabio Estevam wrote:
On Tue, Jun 12, 2018 at 11:35 AM, Stefan Agner stefan@agner.ch wrote:
There are two drivers for the LCDIF/MXSFB peripheral. If the DRM and fbdev are compiled in, the registration of the second driver fails: mxs-dma 33000000.dma-apbh: initialized mxsfb 30730000.lcdif: 30730000.lcdif supply lcd not found, using dummy regulator mxsfb 30730000.lcdif: initialized Error: Driver 'mxsfb' is already registered, aborting...
Avoid driver name conflict with MXS fbdev driver by renaming the more recently added DRM driver.
Signed-off-by: Stefan Agner stefan@agner.ch
Yes, this driver name collision is annoying:
Reviewed-by: Fabio Estevam fabio.estevam@nxp.com
Why dont we just kill the old fbdev driver instead ?
On 13.06.2018 01:08, Marek Vasut wrote:
On 06/12/2018 06:01 PM, Fabio Estevam wrote:
On Tue, Jun 12, 2018 at 11:35 AM, Stefan Agner stefan@agner.ch wrote:
There are two drivers for the LCDIF/MXSFB peripheral. If the DRM and fbdev are compiled in, the registration of the second driver fails: mxs-dma 33000000.dma-apbh: initialized mxsfb 30730000.lcdif: 30730000.lcdif supply lcd not found, using dummy regulator mxsfb 30730000.lcdif: initialized Error: Driver 'mxsfb' is already registered, aborting...
Avoid driver name conflict with MXS fbdev driver by renaming the more recently added DRM driver.
Signed-off-by: Stefan Agner stefan@agner.ch
Yes, this driver name collision is annoying:
Reviewed-by: Fabio Estevam fabio.estevam@nxp.com
Why dont we just kill the old fbdev driver instead ?
The config is outside of my direct control, it's a distro kernel...
Or what do you mean exactly? Send a patch to remove the fbdev driver?
-- Stefan
On 06/13/2018 09:16 AM, Stefan Agner wrote:
On 13.06.2018 01:08, Marek Vasut wrote:
On 06/12/2018 06:01 PM, Fabio Estevam wrote:
On Tue, Jun 12, 2018 at 11:35 AM, Stefan Agner stefan@agner.ch wrote:
There are two drivers for the LCDIF/MXSFB peripheral. If the DRM and fbdev are compiled in, the registration of the second driver fails: mxs-dma 33000000.dma-apbh: initialized mxsfb 30730000.lcdif: 30730000.lcdif supply lcd not found, using dummy regulator mxsfb 30730000.lcdif: initialized Error: Driver 'mxsfb' is already registered, aborting...
Avoid driver name conflict with MXS fbdev driver by renaming the more recently added DRM driver.
Signed-off-by: Stefan Agner stefan@agner.ch
Yes, this driver name collision is annoying:
Reviewed-by: Fabio Estevam fabio.estevam@nxp.com
Why dont we just kill the old fbdev driver instead ?
The config is outside of my direct control, it's a distro kernel...
Or what do you mean exactly? Send a patch to remove the fbdev driver?
Yes, remove the fbdev driver.
[adding Sascha and Bartlomiej]
On 13.06.2018 09:17, Marek Vasut wrote:
On 06/13/2018 09:16 AM, Stefan Agner wrote:
On 13.06.2018 01:08, Marek Vasut wrote:
On 06/12/2018 06:01 PM, Fabio Estevam wrote:
On Tue, Jun 12, 2018 at 11:35 AM, Stefan Agner stefan@agner.ch wrote:
There are two drivers for the LCDIF/MXSFB peripheral. If the DRM and fbdev are compiled in, the registration of the second driver fails: mxs-dma 33000000.dma-apbh: initialized mxsfb 30730000.lcdif: 30730000.lcdif supply lcd not found, using dummy regulator mxsfb 30730000.lcdif: initialized Error: Driver 'mxsfb' is already registered, aborting...
Avoid driver name conflict with MXS fbdev driver by renaming the more recently added DRM driver.
Signed-off-by: Stefan Agner stefan@agner.ch
Yes, this driver name collision is annoying:
Reviewed-by: Fabio Estevam fabio.estevam@nxp.com
Why dont we just kill the old fbdev driver instead ?
The config is outside of my direct control, it's a distro kernel...
Or what do you mean exactly? Send a patch to remove the fbdev driver?
Yes, remove the fbdev driver.
Hm, forcing people to use the DRM driver with fbdev emulation is probably fine for most use cases. Currently you cannot use the fbdev ioctrl to change modes/settings to the framebuffer which is probably the only restriction...
It seems to me a rather extreme measure though, given we could fix the situation rather easily.
But I am ok to remove the fbdev driver, if that is what we want.
-- Stefan
On Wed, Jun 13, 2018 at 9:38 AM, Stefan Agner stefan@agner.ch wrote:
It seems to me a rather extreme measure though, given we could fix the situation rather easily.
There are dtb's using the fbdev mxsfb driver like for example: arch/arm/boot/dts/imx28-evk.dts
If we kill the fbdev mxsfb driver then the display will stop working for some users and I don't think they will be happy.
Last time I tried it was not possible to use the original fbdev mxsfb bindings with the new drm driver.
Of course we can convert to the drm mxsfb driver, but IMHO we should avoid functional breakage all of a sudden.
In the meantime Stefan's patch seems to be a good approach.
On 06/13/2018 03:52 PM, Fabio Estevam wrote:
On Wed, Jun 13, 2018 at 9:38 AM, Stefan Agner stefan@agner.ch wrote:
It seems to me a rather extreme measure though, given we could fix the situation rather easily.
There are dtb's using the fbdev mxsfb driver like for example: arch/arm/boot/dts/imx28-evk.dts
If we kill the fbdev mxsfb driver then the display will stop working for some users and I don't think they will be happy.
Maybe it's time to fix them ?
Having two drivers for the same hardware in the kernel is a bad idea and the new driver was in the kernel for long enough for the user of the old deprecated bindings migrated over I think.
Last time I tried it was not possible to use the original fbdev mxsfb bindings with the new drm driver.
Of course we can convert to the drm mxsfb driver, but IMHO we should avoid functional breakage all of a sudden.
The driver was in the kernel for over a year now though, so it's not new and sudden anymore.
In the meantime Stefan's patch seems to be a good approach.
dri-devel@lists.freedesktop.org
-
Fabio Estevam -
Marek Vasut -
Stefan Agner