[PATCH 0/3] ARM: imx: Make DRM_MXSFB and FB_MXS coexist

[PATCH 0/3] ARM: imx: Make DRM_MXSFB and FB_MXS coexist

[Leonard Crestez]

Some imx boards have new drm-style bindings for lcdif devices but using
them requires rebuilding the kernel with FB_MXS=n DRM_MXSFB=y.

It is relatively easy to allow both drivers to coexist by renaming
drm/mxsfb to "mxsfb-drm" and making the old fbdev driver return -ENODEV
instead of -ENOENT when it fails to find the display node.

This makes display on imx6sx-sdb "just work" with both styles of
bindings. In order to test the old bindings I locally reverted commit
7caa59e0d40c ("ARM: dts: imx6sx-sdb: Convert from fbdev to drm bindings")

Leonard Crestez (3):
  drm: mxsfb: Change driver.name to mxsfb-drm
  fbdev: mxsfb: Return ENODEV on missing display node
  ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB

 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 drivers/gpu/drm/mxsfb/mxsfb_drv.c    | 2 +-
 drivers/video/fbdev/mxsfb.c          | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH 0/3] ARM: imx: Make DRM_MXSFB and FB_MXS coexist

[Leonard Crestez]

Some imx boards have new drm-style bindings for lcdif devices but using
them requires rebuilding the kernel with FB_MXS=n DRM_MXSFB=y.

It is relatively easy to allow both drivers to coexist by renaming
drm/mxsfb to "mxsfb-drm" and making the old fbdev driver return -ENODEV
instead of -ENOENT when it fails to find the display node.

This makes display on imx6sx-sdb "just work" with both styles of
bindings. In order to test the old bindings I locally reverted commit
7caa59e0d40c ("ARM: dts: imx6sx-sdb: Convert from fbdev to drm bindings")

Leonard Crestez (3):
  drm: mxsfb: Change driver.name to mxsfb-drm
  fbdev: mxsfb: Return ENODEV on missing display node
  ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB

 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 drivers/gpu/drm/mxsfb/mxsfb_drv.c    | 2 +-
 drivers/video/fbdev/mxsfb.c          | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH 0/3] ARM: imx: Make DRM_MXSFB and FB_MXS coexist

[Leonard Crestez]

Some imx boards have new drm-style bindings for lcdif devices but using
them requires rebuilding the kernel with FB_MXS=n DRM_MXSFB=y.

It is relatively easy to allow both drivers to coexist by renaming
drm/mxsfb to "mxsfb-drm" and making the old fbdev driver return -ENODEV
instead of -ENOENT when it fails to find the display node.

This makes display on imx6sx-sdb "just work" with both styles of
bindings. In order to test the old bindings I locally reverted commit
7caa59e0d40c ("ARM: dts: imx6sx-sdb: Convert from fbdev to drm bindings")

Leonard Crestez (3):
  drm: mxsfb: Change driver.name to mxsfb-drm
  fbdev: mxsfb: Return ENODEV on missing display node
  ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB

 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 drivers/gpu/drm/mxsfb/mxsfb_drv.c    | 2 +-
 drivers/video/fbdev/mxsfb.c          | 2 +-
 3 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.17.1

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

The FBDEV driver uses the same name and both can't be registered at the
same time. Fix this by renaming the drm driver to mxsfb-drm

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 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 ffe5137ccaf8..dd1dd58e4956 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -417,11 +417,11 @@ static int mxsfb_remove(struct platform_device *pdev)
 static struct platform_driver mxsfb_platform_driver = {
 	.probe		= mxsfb_probe,
 	.remove		= mxsfb_remove,
 	.id_table	= mxsfb_devtype,
 	.driver	= {
-		.name		= "mxsfb",
+		.name		= "mxsfb-drm",
 		.of_match_table	= mxsfb_dt_ids,
 	},
 };
 
 module_platform_driver(mxsfb_platform_driver);
-- 
2.17.1

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

The FBDEV driver uses the same name and both can't be registered at the
same time. Fix this by renaming the drm driver to mxsfb-drm

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 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 ffe5137ccaf8..dd1dd58e4956 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -417,11 +417,11 @@ static int mxsfb_remove(struct platform_device *pdev)
 static struct platform_driver mxsfb_platform_driver = {
 	.probe		= mxsfb_probe,
 	.remove		= mxsfb_remove,
 	.id_table	= mxsfb_devtype,
 	.driver	= {
-		.name		= "mxsfb",
+		.name		= "mxsfb-drm",
 		.of_match_table	= mxsfb_dt_ids,
 	},
 };
 
 module_platform_driver(mxsfb_platform_driver);
-- 
2.17.1

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

The FBDEV driver uses the same name and both can't be registered at the
same time. Fix this by renaming the drm driver to mxsfb-drm

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 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 ffe5137ccaf8..dd1dd58e4956 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -417,11 +417,11 @@ static int mxsfb_remove(struct platform_device *pdev)
 static struct platform_driver mxsfb_platform_driver = {
 	.probe		= mxsfb_probe,
 	.remove		= mxsfb_remove,
 	.id_table	= mxsfb_devtype,
 	.driver	= {
-		.name		= "mxsfb",
+		.name		= "mxsfb-drm",
 		.of_match_table	= mxsfb_dt_ids,
 	},
 };
 
 module_platform_driver(mxsfb_platform_driver);
-- 
2.17.1

[PATCH 2/3] fbdev: mxsfb: Return ENODEV on missing display node

[Leonard Crestez]

When this driver encounters drm-style bindings it returns -ENOENT and
this reports a probe error. Make it return -ENODEV to signal an explicit
rejection instead.

This allows peaceful coexistence between the DRM_MXSFB and FB_MXS config
options.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/video/fbdev/mxsfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index 12c8bd1d24d5..9ec8882d7b3d 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -736,11 +736,11 @@ static int mxsfb_init_fbinfo_dt(struct fb_info *fb_info,
 	int ret;
 
 	display_np = of_parse_phandle(np, "display", 0);
 	if (!display_np) {
 		dev_err(dev, "failed to find display phandle\n");
-		return -ENOENT;
+		return -ENODEV;
 	}
 
 	ret = of_property_read_u32(display_np, "bus-width", &width);
 	if (ret < 0) {
 		dev_err(dev, "failed to get property bus-width\n");
-- 
2.17.1

[PATCH 2/3] fbdev: mxsfb: Return ENODEV on missing display node

[Leonard Crestez]

When this driver encounters drm-style bindings it returns -ENOENT and
this reports a probe error. Make it return -ENODEV to signal an explicit
rejection instead.

This allows peaceful coexistence between the DRM_MXSFB and FB_MXS config
options.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/video/fbdev/mxsfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index 12c8bd1d24d5..9ec8882d7b3d 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -736,11 +736,11 @@ static int mxsfb_init_fbinfo_dt(struct fb_info *fb_info,
 	int ret;
 
 	display_np = of_parse_phandle(np, "display", 0);
 	if (!display_np) {
 		dev_err(dev, "failed to find display phandle\n");
-		return -ENOENT;
+		return -ENODEV;
 	}
 
 	ret = of_property_read_u32(display_np, "bus-width", &width);
 	if (ret < 0) {
 		dev_err(dev, "failed to get property bus-width\n");
-- 
2.17.1

[PATCH 2/3] fbdev: mxsfb: Return ENODEV on missing display node

[Leonard Crestez]

When this driver encounters drm-style bindings it returns -ENOENT and
this reports a probe error. Make it return -ENODEV to signal an explicit
rejection instead.

This allows peaceful coexistence between the DRM_MXSFB and FB_MXS config
options.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 drivers/video/fbdev/mxsfb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/mxsfb.c b/drivers/video/fbdev/mxsfb.c
index 12c8bd1d24d5..9ec8882d7b3d 100644
--- a/drivers/video/fbdev/mxsfb.c
+++ b/drivers/video/fbdev/mxsfb.c
@@ -736,11 +736,11 @@ static int mxsfb_init_fbinfo_dt(struct fb_info *fb_info,
 	int ret;
 
 	display_np = of_parse_phandle(np, "display", 0);
 	if (!display_np) {
 		dev_err(dev, "failed to find display phandle\n");
-		return -ENOENT;
+		return -ENODEV;
 	}
 
 	ret = of_property_read_u32(display_np, "bus-width", &width);
 	if (ret < 0) {
 		dev_err(dev, "failed to get property bus-width\n");
-- 
2.17.1

[PATCH 3/3] ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB

[Leonard Crestez]

Multiple boards have drm-style bindings on imx lcdif nodes, enable the
driver so that they work by default.

Also enable DRM_PANEL_SEIKO_43WVF1G, it is one of the supported display
attachments for imx development boards.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507ab91ee..dd0f64da2243 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -256,18 +256,20 @@ CONFIG_VIDEO_ADV7180=m
 CONFIG_VIDEO_OV5640=m
 CONFIG_IMX_IPUV3_CORE=y
 CONFIG_DRM=y
 CONFIG_DRM_PANEL_LVDS=y
 CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_PANEL_SEIKO_43WVF1G=y
 CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
 CONFIG_DRM_DW_HDMI_CEC=y
 CONFIG_DRM_IMX=y
 CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
 CONFIG_DRM_IMX_TVE=y
 CONFIG_DRM_IMX_LDB=y
 CONFIG_DRM_IMX_HDMI=y
 CONFIG_DRM_ETNAVIV=y
+CONFIG_DRM_MXSFB=y
 CONFIG_FB_MXS=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_L4F00242T03=y
 CONFIG_LCD_PLATFORM=y
 CONFIG_BACKLIGHT_PWM=y
-- 
2.17.1

[PATCH 3/3] ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB

[Leonard Crestez]

Multiple boards have drm-style bindings on imx lcdif nodes, enable the
driver so that they work by default.

Also enable DRM_PANEL_SEIKO_43WVF1G, it is one of the supported display
attachments for imx development boards.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507ab91ee..dd0f64da2243 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -256,18 +256,20 @@ CONFIG_VIDEO_ADV7180=m
 CONFIG_VIDEO_OV5640=m
 CONFIG_IMX_IPUV3_CORE=y
 CONFIG_DRM=y
 CONFIG_DRM_PANEL_LVDS=y
 CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_PANEL_SEIKO_43WVF1G=y
 CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
 CONFIG_DRM_DW_HDMI_CEC=y
 CONFIG_DRM_IMX=y
 CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
 CONFIG_DRM_IMX_TVE=y
 CONFIG_DRM_IMX_LDB=y
 CONFIG_DRM_IMX_HDMI=y
 CONFIG_DRM_ETNAVIV=y
+CONFIG_DRM_MXSFB=y
 CONFIG_FB_MXS=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_L4F00242T03=y
 CONFIG_LCD_PLATFORM=y
 CONFIG_BACKLIGHT_PWM=y
-- 
2.17.1

[PATCH 3/3] ARM: imx_v6_v7_defconfig: Enable DRM_MXSFB

[Leonard Crestez]

Multiple boards have drm-style bindings on imx lcdif nodes, enable the
driver so that they work by default.

Also enable DRM_PANEL_SEIKO_43WVF1G, it is one of the supported display
attachments for imx development boards.

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index f70507ab91ee..dd0f64da2243 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -256,18 +256,20 @@ CONFIG_VIDEO_ADV7180=m
 CONFIG_VIDEO_OV5640=m
 CONFIG_IMX_IPUV3_CORE=y
 CONFIG_DRM=y
 CONFIG_DRM_PANEL_LVDS=y
 CONFIG_DRM_PANEL_SIMPLE=y
+CONFIG_DRM_PANEL_SEIKO_43WVF1G=y
 CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
 CONFIG_DRM_DW_HDMI_CEC=y
 CONFIG_DRM_IMX=y
 CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
 CONFIG_DRM_IMX_TVE=y
 CONFIG_DRM_IMX_LDB=y
 CONFIG_DRM_IMX_HDMI=y
 CONFIG_DRM_ETNAVIV=y
+CONFIG_DRM_MXSFB=y
 CONFIG_FB_MXS=y
 CONFIG_LCD_CLASS_DEVICE=y
 CONFIG_LCD_L4F00242T03=y
 CONFIG_LCD_PLATFORM=y
 CONFIG_BACKLIGHT_PWM=y
-- 
2.17.1

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

Hi Leonard,

On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> The FBDEV driver uses the same name and both can't be registered at the
> same time. Fix this by renaming the drm driver to mxsfb-drm
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

Stefan sent the same patch a few days ago:
https://www.spinics.net/lists/dri-devel/msg179489.html

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

Hi Leonard,

On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> The FBDEV driver uses the same name and both can't be registered at the
> same time. Fix this by renaming the drm driver to mxsfb-drm
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

Stefan sent the same patch a few days ago:
https://www.spinics.net/lists/dri-devel/msg179489.html
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

Hi Leonard,

On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> The FBDEV driver uses the same name and both can't be registered at the
> same time. Fix this by renaming the drm driver to mxsfb-drm
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

Stefan sent the same patch a few days ago:
https://www.spinics.net/lists/dri-devel/msg179489.html

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

Hi Leonard,

On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:
> The FBDEV driver uses the same name and both can't be registered at the
> same time. Fix this by renaming the drm driver to mxsfb-drm
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>

Stefan sent the same patch a few days ago:
https://www.spinics.net/lists/dri-devel/msg179489.html

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:

> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> <leonard.crestez@nxp.com> wrote:
> > The FBDEV driver uses the same name and both can't be registered at the
> > same time. Fix this by renaming the drm driver to mxsfb-drm
> > 
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> Stefan sent the same patch a few days ago:
> http://www.spinics.net/lists/dri-devel/msg179489.html

In that thread there is a proposal for removing the old fbdev/mxsfb
driver entirely.

That would break old DTBs, isn't this generally considered bad? Also,
are we sure the removal of fbdev/mxsfb wouldn't lose any features?

What my series does is make both drivers work with the same kernel
image and turns the choice into a board-level dtb decision. Supporting
everything at once seems desirable to me and it allows for a very
smooth upgrade path.

The old driver could be removed later, after all users are converted.

--
Regards,
Leonard

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:

> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> <leonard.crestez@nxp.com> wrote:
> > The FBDEV driver uses the same name and both can't be registered at the
> > same time. Fix this by renaming the drm driver to mxsfb-drm
> > 
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> Stefan sent the same patch a few days ago:
> http://www.spinics.net/lists/dri-devel/msg179489.html

In that thread there is a proposal for removing the old fbdev/mxsfb
driver entirely.

That would break old DTBs, isn't this generally considered bad? Also,
are we sure the removal of fbdev/mxsfb wouldn't lose any features?

What my series does is make both drivers work with the same kernel
image and turns the choice into a board-level dtb decision. Supporting
everything at once seems desirable to me and it allows for a very
smooth upgrade path.

The old driver could be removed later, after all users are converted.

--
Regards,
Leonard

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

T24gRnJpLCAyMDE4LTA2LTE1IGF0IDE2OjQ3IC0wMzAwLCBGYWJpbyBFc3RldmFtIHdyb3RlOg0K
DQo+IE9uIEZyaSwgSnVuIDE1LCAyMDE4IGF0IDQ6NDMgUE0sIExlb25hcmQgQ3Jlc3Rleg0KPiA8
bGVvbmFyZC5jcmVzdGV6QG54cC5jb20+IHdyb3RlOg0KPiA+IFRoZSBGQkRFViBkcml2ZXIgdXNl
cyB0aGUgc2FtZSBuYW1lIGFuZCBib3RoIGNhbid0IGJlIHJlZ2lzdGVyZWQgYXQgdGhlDQo+ID4g
c2FtZSB0aW1lLiBGaXggdGhpcyBieSByZW5hbWluZyB0aGUgZHJtIGRyaXZlciB0byBteHNmYi1k
cm0NCj4gPiANCj4gPiBTaWduZWQtb2ZmLWJ5OiBMZW9uYXJkIENyZXN0ZXogPGxlb25hcmQuY3Jl
c3RlekBueHAuY29tPg0KPiANCj4gU3RlZmFuIHNlbnQgdGhlIHNhbWUgcGF0Y2ggYSBmZXcgZGF5
cyBhZ286DQo+IGh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvZHJpLWRldmVsL21zZzE3OTQ4
OS5odG1sDQoNCkluIHRoYXQgdGhyZWFkIHRoZXJlIGlzIGEgcHJvcG9zYWwgZm9yIHJlbW92aW5n
IHRoZSBvbGQgZmJkZXYvbXhzZmINCmRyaXZlciBlbnRpcmVseS4NCg0KVGhhdCB3b3VsZCBicmVh
ayBvbGQgRFRCcywgaXNuJ3QgdGhpcyBnZW5lcmFsbHkgY29uc2lkZXJlZCBiYWQ/IEFsc28sDQph
cmUgd2Ugc3VyZSB0aGUgcmVtb3ZhbCBvZiBmYmRldi9teHNmYiB3b3VsZG4ndCBsb3NlIGFueSBm
ZWF0dXJlcz8NCg0KV2hhdCBteSBzZXJpZXMgZG9lcyBpcyBtYWtlIGJvdGggZHJpdmVycyB3b3Jr
IHdpdGggdGhlIHNhbWUga2VybmVsDQppbWFnZSBhbmQgdHVybnMgdGhlIGNob2ljZSBpbnRvIGEg
Ym9hcmQtbGV2ZWwgZHRiIGRlY2lzaW9uLiBTdXBwb3J0aW5nDQpldmVyeXRoaW5nIGF0IG9uY2Ug
c2VlbXMgZGVzaXJhYmxlIHRvIG1lIGFuZCBpdCBhbGxvd3MgZm9yIGEgdmVyeQ0Kc21vb3RoIHVw
Z3JhZGUgcGF0aC4NCg0KVGhlIG9sZCBkcml2ZXIgY291bGQgYmUgcmVtb3ZlZCBsYXRlciwgYWZ0
ZXIgYWxsIHVzZXJzIGFyZSBjb252ZXJ0ZWQuDQoNCi0tDQpSZWdhcmRzLA0KTGVvbmFyZA=

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:

> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> <leonard.crestez@nxp.com> wrote:
> > The FBDEV driver uses the same name and both can't be registered at the
> > same time. Fix this by renaming the drm driver to mxsfb-drm
> > 
> > Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> 
> Stefan sent the same patch a few days ago:
> http://www.spinics.net/lists/dri-devel/msg179489.html

In that thread there is a proposal for removing the old fbdev/mxsfb
driver entirely.

That would break old DTBs, isn't this generally considered bad? Also,
are we sure the removal of fbdev/mxsfb wouldn't lose any features?

What my series does is make both drivers work with the same kernel
image and turns the choice into a board-level dtb decision. Supporting
everything at once seems desirable to me and it allows for a very
smooth upgrade path.

The old driver could be removed later, after all users are converted.

--
Regards,
Leonard

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 5:58 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:

> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
>
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?

Yes, I also think we should not break old dtb's.

> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.
>
> The old driver could be removed later, after all users are converted.

Agreed.

Maybe the mxs fbdev driver needs to warn users saying that that the
driver is deprecated and the bindings need to be updated to the DRM
bindings style.

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 5:58 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:

> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
>
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?

Yes, I also think we should not break old dtb's.

> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.
>
> The old driver could be removed later, after all users are converted.

Agreed.

Maybe the mxs fbdev driver needs to warn users saying that that the
driver is deprecated and the bindings need to be updated to the DRM
bindings style.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 5:58 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:

> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
>
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?

Yes, I also think we should not break old dtb's.

> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.
>
> The old driver could be removed later, after all users are converted.

Agreed.

Maybe the mxs fbdev driver needs to warn users saying that that the
driver is deprecated and the bindings need to be updated to the DRM
bindings style.

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 5:58 PM, Leonard Crestez
<leonard.crestez@nxp.com> wrote:

> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
>
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?

Yes, I also think we should not break old dtb's.

> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.
>
> The old driver could be removed later, after all users are converted.

Agreed.

Maybe the mxs fbdev driver needs to warn users saying that that the
driver is deprecated and the bindings need to be updated to the DRM
bindings style.

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> 
>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> <leonard.crestez@nxp.com> wrote:
>>> The FBDEV driver uses the same name and both can't be registered at the
>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>
>> Stefan sent the same patch a few days ago:
>> http://www.spinics.net/lists/dri-devel/msg179489.html
> 
> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
> 
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> 
> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.

Having two drivers in the kernel with different set of bugs is always bad.

> The old driver could be removed later, after all users are converted.

Both drivers were in for long enough already. And let's be realistic,
how many MX23/MX28 users of old DTs with new kernels are there who
cannot update the DT as well ?

IMO keeping the old FBDEV driver in is just an excuse to postpone the
long overdue DT update and I dislike that. Update any remaining DTs and
nuke the FBDEV driver already.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> 
>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> <leonard.crestez@nxp.com> wrote:
>>> The FBDEV driver uses the same name and both can't be registered at the
>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>
>> Stefan sent the same patch a few days ago:
>> http://www.spinics.net/lists/dri-devel/msg179489.html
> 
> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
> 
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> 
> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.

Having two drivers in the kernel with different set of bugs is always bad.

> The old driver could be removed later, after all users are converted.

Both drivers were in for long enough already. And let's be realistic,
how many MX23/MX28 users of old DTs with new kernels are there who
cannot update the DT as well ?

IMO keeping the old FBDEV driver in is just an excuse to postpone the
long overdue DT update and I dislike that. Update any remaining DTs and
nuke the FBDEV driver already.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> 
>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> <leonard.crestez@nxp.com> wrote:
>>> The FBDEV driver uses the same name and both can't be registered at the
>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>
>> Stefan sent the same patch a few days ago:
>> http://www.spinics.net/lists/dri-devel/msg179489.html
> 
> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
> 
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> 
> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.

Having two drivers in the kernel with different set of bugs is always bad.

> The old driver could be removed later, after all users are converted.

Both drivers were in for long enough already. And let's be realistic,
how many MX23/MX28 users of old DTs with new kernels are there who
cannot update the DT as well ?

IMO keeping the old FBDEV driver in is just an excuse to postpone the
long overdue DT update and I dislike that. Update any remaining DTs and
nuke the FBDEV driver already.

-- 
Best regards,
Marek Vasut

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> 
>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> <leonard.crestez@nxp.com> wrote:
>>> The FBDEV driver uses the same name and both can't be registered at the
>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>
>> Stefan sent the same patch a few days ago:
>> http://www.spinics.net/lists/dri-devel/msg179489.html
> 
> In that thread there is a proposal for removing the old fbdev/mxsfb
> driver entirely.
> 
> That would break old DTBs, isn't this generally considered bad? Also,
> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> 
> What my series does is make both drivers work with the same kernel
> image and turns the choice into a board-level dtb decision. Supporting
> everything at once seems desirable to me and it allows for a very
> smooth upgrade path.

Having two drivers in the kernel with different set of bugs is always bad.

> The old driver could be removed later, after all users are converted.

Both drivers were in for long enough already. And let's be realistic,
how many MX23/MX28 users of old DTs with new kernels are there who
cannot update the DT as well ?

IMO keeping the old FBDEV driver in is just an excuse to postpone the
long overdue DT update and I dislike that. Update any remaining DTs and
nuke the FBDEV driver already.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:

> Having two drivers in the kernel with different set of bugs is always bad.

Sure, but breaking dtb's is also bad.

Can the mxsfb driver be modified to handle the old style bindings?

The IPU drm driver is capable of handling both the old style where the
display timing is passed in dts and the new drm style.

For example:

arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
the display timings in dts

Both formats are accepted by the ipu drm driver.

Can't mxsfb drm driver support both? Then we don't need to worry about
breaking dtb's and could safely remove the mxs fbdev driver.

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:

> Having two drivers in the kernel with different set of bugs is always bad.

Sure, but breaking dtb's is also bad.

Can the mxsfb driver be modified to handle the old style bindings?

The IPU drm driver is capable of handling both the old style where the
display timing is passed in dts and the new drm style.

For example:

arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
the display timings in dts

Both formats are accepted by the ipu drm driver.

Can't mxsfb drm driver support both? Then we don't need to worry about
breaking dtb's and could safely remove the mxs fbdev driver.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:

> Having two drivers in the kernel with different set of bugs is always bad.

Sure, but breaking dtb's is also bad.

Can the mxsfb driver be modified to handle the old style bindings?

The IPU drm driver is capable of handling both the old style where the
display timing is passed in dts and the new drm style.

For example:

arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
the display timings in dts

Both formats are accepted by the ipu drm driver.

Can't mxsfb drm driver support both? Then we don't need to worry about
breaking dtb's and could safely remove the mxs fbdev driver.

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Fabio Estevam]

On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:

> Having two drivers in the kernel with different set of bugs is always bad.

Sure, but breaking dtb's is also bad.

Can the mxsfb driver be modified to handle the old style bindings?

The IPU drm driver is capable of handling both the old style where the
display timing is passed in dts and the new drm style.

For example:

arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
the display timings in dts

Both formats are accepted by the ipu drm driver.

Can't mxsfb drm driver support both? Then we don't need to worry about
breaking dtb's and could safely remove the mxs fbdev driver.

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> > > On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> > > <leonard.crestez@nxp.com> wrote:

> > > > The FBDEV driver uses the same name and both can't be registered at the
> > > > same time. Fix this by renaming the drm driver to mxsfb-drm
> > > 
> > > Stefan sent the same patch a few days ago:
> > 
> > In that thread there is a proposal for removing the old fbdev/mxsfb
> > driver entirely.
> > 
> > That would break old DTBs, isn't this generally considered bad? Also,
> > are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> > 
> > What my series does is make both drivers work with the same kernel
> > image and turns the choice into a board-level dtb decision. Supporting
> > everything at once seems desirable to me and it allows for a very
> > smooth upgrade path.
> 
> Having two drivers in the kernel with different set of bugs is always bad.
> 
> > The old driver could be removed later, after all users are converted.
> 
> Both drivers were in for long enough already. And let's be realistic,
> how many MX23/MX28 users of old DTs with new kernels are there who
> cannot update the DT as well ?

Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
bindings are also used by 3rd-party boards for imx6/7:
 * imx6sx-nitrogen6sx
 * imx6ul-geam
 * imx6ul-isiot
 * imx6ul-opos6uldev
 * imx6ul-pico-hobbit
 * imx6ul-tx6ul
 * imx7d-nitrogen7

Converting everything might be quite a bit of work, and explicitly
supporting old bindings is also work.

It is very confusing that there is a whole set of displays for imx6/7
which are supported by upstream but only with a non-default config.
While it is extremely common in the embedded field to have custom
configs the default one in the kernel should try to "just work".

Couldn't this patch series be considered a bugfix? It was also
surprisingly small.

--
Regards,
Leonard

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> > > On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> > > <leonard.crestez@nxp.com> wrote:

> > > > The FBDEV driver uses the same name and both can't be registered at the
> > > > same time. Fix this by renaming the drm driver to mxsfb-drm
> > > 
> > > Stefan sent the same patch a few days ago:
> > 
> > In that thread there is a proposal for removing the old fbdev/mxsfb
> > driver entirely.
> > 
> > That would break old DTBs, isn't this generally considered bad? Also,
> > are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> > 
> > What my series does is make both drivers work with the same kernel
> > image and turns the choice into a board-level dtb decision. Supporting
> > everything at once seems desirable to me and it allows for a very
> > smooth upgrade path.
> 
> Having two drivers in the kernel with different set of bugs is always bad.
> 
> > The old driver could be removed later, after all users are converted.
> 
> Both drivers were in for long enough already. And let's be realistic,
> how many MX23/MX28 users of old DTs with new kernels are there who
> cannot update the DT as well ?

Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
bindings are also used by 3rd-party boards for imx6/7:
 * imx6sx-nitrogen6sx
 * imx6ul-geam
 * imx6ul-isiot
 * imx6ul-opos6uldev
 * imx6ul-pico-hobbit
 * imx6ul-tx6ul
 * imx7d-nitrogen7

Converting everything might be quite a bit of work, and explicitly
supporting old bindings is also work.

It is very confusing that there is a whole set of displays for imx6/7
which are supported by upstream but only with a non-default config.
While it is extremely common in the embedded field to have custom
configs the default one in the kernel should try to "just work".

Couldn't this patch series be considered a bugfix? It was also
surprisingly small.

--
Regards,
Leonard

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

T24gRnJpLCAyMDE4LTA2LTE1IGF0IDIzOjM2ICswMjAwLCBNYXJlayBWYXN1dCB3cm90ZToNCj4g
T24gMDYvMTUvMjAxOCAxMDo1OCBQTSwgTGVvbmFyZCBDcmVzdGV6IHdyb3RlOg0KPiA+IE9uIEZy
aSwgMjAxOC0wNi0xNSBhdCAxNjo0NyAtMDMwMCwgRmFiaW8gRXN0ZXZhbSB3cm90ZToNCj4gPiA+
IE9uIEZyaSwgSnVuIDE1LCAyMDE4IGF0IDQ6NDMgUE0sIExlb25hcmQgQ3Jlc3Rleg0KPiA+ID4g
PGxlb25hcmQuY3Jlc3RlekBueHAuY29tPiB3cm90ZToNCg0KPiA+ID4gPiBUaGUgRkJERVYgZHJp
dmVyIHVzZXMgdGhlIHNhbWUgbmFtZSBhbmQgYm90aCBjYW4ndCBiZSByZWdpc3RlcmVkIGF0IHRo
ZQ0KPiA+ID4gPiBzYW1lIHRpbWUuIEZpeCB0aGlzIGJ5IHJlbmFtaW5nIHRoZSBkcm0gZHJpdmVy
IHRvIG14c2ZiLWRybQ0KPiA+ID4gDQo+ID4gPiBTdGVmYW4gc2VudCB0aGUgc2FtZSBwYXRjaCBh
IGZldyBkYXlzIGFnbzoNCj4gPiANCj4gPiBJbiB0aGF0IHRocmVhZCB0aGVyZSBpcyBhIHByb3Bv
c2FsIGZvciByZW1vdmluZyB0aGUgb2xkIGZiZGV2L214c2ZiDQo+ID4gZHJpdmVyIGVudGlyZWx5
Lg0KPiA+IA0KPiA+IFRoYXQgd291bGQgYnJlYWsgb2xkIERUQnMsIGlzbid0IHRoaXMgZ2VuZXJh
bGx5IGNvbnNpZGVyZWQgYmFkPyBBbHNvLA0KPiA+IGFyZSB3ZSBzdXJlIHRoZSByZW1vdmFsIG9m
IGZiZGV2L214c2ZiIHdvdWxkbid0IGxvc2UgYW55IGZlYXR1cmVzPw0KPiA+IA0KPiA+IFdoYXQg
bXkgc2VyaWVzIGRvZXMgaXMgbWFrZSBib3RoIGRyaXZlcnMgd29yayB3aXRoIHRoZSBzYW1lIGtl
cm5lbA0KPiA+IGltYWdlIGFuZCB0dXJucyB0aGUgY2hvaWNlIGludG8gYSBib2FyZC1sZXZlbCBk
dGIgZGVjaXNpb24uIFN1cHBvcnRpbmcNCj4gPiBldmVyeXRoaW5nIGF0IG9uY2Ugc2VlbXMgZGVz
aXJhYmxlIHRvIG1lIGFuZCBpdCBhbGxvd3MgZm9yIGEgdmVyeQ0KPiA+IHNtb290aCB1cGdyYWRl
IHBhdGguDQo+IA0KPiBIYXZpbmcgdHdvIGRyaXZlcnMgaW4gdGhlIGtlcm5lbCB3aXRoIGRpZmZl
cmVudCBzZXQgb2YgYnVncyBpcyBhbHdheXMgYmFkLg0KPiANCj4gPiBUaGUgb2xkIGRyaXZlciBj
b3VsZCBiZSByZW1vdmVkIGxhdGVyLCBhZnRlciBhbGwgdXNlcnMgYXJlIGNvbnZlcnRlZC4NCj4g
DQo+IEJvdGggZHJpdmVycyB3ZXJlIGluIGZvciBsb25nIGVub3VnaCBhbHJlYWR5LiBBbmQgbGV0
J3MgYmUgcmVhbGlzdGljLA0KPiBob3cgbWFueSBNWDIzL01YMjggdXNlcnMgb2Ygb2xkIERUcyB3
aXRoIG5ldyBrZXJuZWxzIGFyZSB0aGVyZSB3aG8NCj4gY2Fubm90IHVwZGF0ZSB0aGUgRFQgYXMg
d2VsbCA/DQoNCkdyZXBwaW5nIGZvciAiZGlzcGxheSA9IiBpbiBhcmNoL2FybS9ib290L2R0cy9p
bXgqIEkgc2VlIHRoYXQgb2xkDQpiaW5kaW5ncyBhcmUgYWxzbyB1c2VkIGJ5IDNyZC1wYXJ0eSBi
b2FyZHMgZm9yIGlteDYvNzoNCiAqIGlteDZzeC1uaXRyb2dlbjZzeA0KICogaW14NnVsLWdlYW0N
CiAqIGlteDZ1bC1pc2lvdA0KICogaW14NnVsLW9wb3M2dWxkZXYNCiAqIGlteDZ1bC1waWNvLWhv
YmJpdA0KICogaW14NnVsLXR4NnVsDQogKiBpbXg3ZC1uaXRyb2dlbjcNCg0KQ29udmVydGluZyBl
dmVyeXRoaW5nIG1pZ2h0IGJlIHF1aXRlIGEgYml0IG9mIHdvcmssIGFuZCBleHBsaWNpdGx5DQpz
dXBwb3J0aW5nIG9sZCBiaW5kaW5ncyBpcyBhbHNvIHdvcmsuDQoNCkl0IGlzIHZlcnkgY29uZnVz
aW5nIHRoYXQgdGhlcmUgaXMgYSB3aG9sZSBzZXQgb2YgZGlzcGxheXMgZm9yIGlteDYvNw0Kd2hp
Y2ggYXJlIHN1cHBvcnRlZCBieSB1cHN0cmVhbSBidXQgb25seSB3aXRoIGEgbm9uLWRlZmF1bHQg
Y29uZmlnLg0KV2hpbGUgaXQgaXMgZXh0cmVtZWx5IGNvbW1vbiBpbiB0aGUgZW1iZWRkZWQgZmll
bGQgdG8gaGF2ZSBjdXN0b20NCmNvbmZpZ3MgdGhlIGRlZmF1bHQgb25lIGluIHRoZSBrZXJuZWwg
c2hvdWxkIHRyeSB0byAianVzdCB3b3JrIi4NCg0KQ291bGRuJ3QgdGhpcyBwYXRjaCBzZXJpZXMg
YmUgY29uc2lkZXJlZCBhIGJ1Z2ZpeD8gSXQgd2FzIGFsc28NCnN1cnByaXNpbmdseSBzbWFsbC4N
Cg0KLS0NClJlZ2FyZHMsDQpMZW9uYXJk

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> > > On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> > > <leonard.crestez@nxp.com> wrote:

> > > > The FBDEV driver uses the same name and both can't be registered at the
> > > > same time. Fix this by renaming the drm driver to mxsfb-drm
> > > 
> > > Stefan sent the same patch a few days ago:
> > 
> > In that thread there is a proposal for removing the old fbdev/mxsfb
> > driver entirely.
> > 
> > That would break old DTBs, isn't this generally considered bad? Also,
> > are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> > 
> > What my series does is make both drivers work with the same kernel
> > image and turns the choice into a board-level dtb decision. Supporting
> > everything at once seems desirable to me and it allows for a very
> > smooth upgrade path.
> 
> Having two drivers in the kernel with different set of bugs is always bad.
> 
> > The old driver could be removed later, after all users are converted.
> 
> Both drivers were in for long enough already. And let's be realistic,
> how many MX23/MX28 users of old DTs with new kernels are there who
> cannot update the DT as well ?

Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
bindings are also used by 3rd-party boards for imx6/7:
 * imx6sx-nitrogen6sx
 * imx6ul-geam
 * imx6ul-isiot
 * imx6ul-opos6uldev
 * imx6ul-pico-hobbit
 * imx6ul-tx6ul
 * imx7d-nitrogen7

Converting everything might be quite a bit of work, and explicitly
supporting old bindings is also work.

It is very confusing that there is a whole set of displays for imx6/7
which are supported by upstream but only with a non-default config.
While it is extremely common in the embedded field to have custom
configs the default one in the kernel should try to "just work".

Couldn't this patch series be considered a bugfix? It was also
surprisingly small.

--
Regards,
Leonard

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:22 AM, Fabio Estevam wrote:
> On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:
> 
>> Having two drivers in the kernel with different set of bugs is always bad.
> 
> Sure, but breaking dtb's is also bad.

You picked only the first part of my argument, the less important one ;-)

> Can the mxsfb driver be modified to handle the old style bindings?

Maybe, but do we care ? Cfr my comment about the amount of users who
will be affected by this.

> The IPU drm driver is capable of handling both the old style where the
> display timing is passed in dts and the new drm style.
> 
> For example:
> 
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
> the display timings in dts
> 
> Both formats are accepted by the ipu drm driver.
> 
> Can't mxsfb drm driver support both? Then we don't need to worry about
> breaking dtb's and could safely remove the mxs fbdev driver.

This might be a way forward, but again, does it justify the effort ?
We will be adding compatibility code which we will have to maintain for
maybe a handful of users I think.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:22 AM, Fabio Estevam wrote:
> On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:
> 
>> Having two drivers in the kernel with different set of bugs is always bad.
> 
> Sure, but breaking dtb's is also bad.

You picked only the first part of my argument, the less important one ;-)

> Can the mxsfb driver be modified to handle the old style bindings?

Maybe, but do we care ? Cfr my comment about the amount of users who
will be affected by this.

> The IPU drm driver is capable of handling both the old style where the
> display timing is passed in dts and the new drm style.
> 
> For example:
> 
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
> the display timings in dts
> 
> Both formats are accepted by the ipu drm driver.
> 
> Can't mxsfb drm driver support both? Then we don't need to worry about
> breaking dtb's and could safely remove the mxs fbdev driver.

This might be a way forward, but again, does it justify the effort ?
We will be adding compatibility code which we will have to maintain for
maybe a handful of users I think.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:22 AM, Fabio Estevam wrote:
> On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:
> 
>> Having two drivers in the kernel with different set of bugs is always bad.
> 
> Sure, but breaking dtb's is also bad.

You picked only the first part of my argument, the less important one ;-)

> Can the mxsfb driver be modified to handle the old style bindings?

Maybe, but do we care ? Cfr my comment about the amount of users who
will be affected by this.

> The IPU drm driver is capable of handling both the old style where the
> display timing is passed in dts and the new drm style.
> 
> For example:
> 
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
> the display timings in dts
> 
> Both formats are accepted by the ipu drm driver.
> 
> Can't mxsfb drm driver support both? Then we don't need to worry about
> breaking dtb's and could safely remove the mxs fbdev driver.

This might be a way forward, but again, does it justify the effort ?
We will be adding compatibility code which we will have to maintain for
maybe a handful of users I think.

-- 
Best regards,
Marek Vasut

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:22 AM, Fabio Estevam wrote:
> On Fri, Jun 15, 2018 at 6:36 PM, Marek Vasut <marex@denx.de> wrote:
> 
>> Having two drivers in the kernel with different set of bugs is always bad.
> 
> Sure, but breaking dtb's is also bad.

You picked only the first part of my argument, the less important one ;-)

> Can the mxsfb driver be modified to handle the old style bindings?

Maybe, but do we care ? Cfr my comment about the amount of users who
will be affected by this.

> The IPU drm driver is capable of handling both the old style where the
> display timing is passed in dts and the new drm style.
> 
> For example:
> 
> arch/arm/boot/dts/imx6qdl-sabresd.dtsi uses the drm style binding
> arch/arm/boot/dts/imx6qdl-sabreauto.dtsi uses the old style of passing
> the display timings in dts
> 
> Both formats are accepted by the ipu drm driver.
> 
> Can't mxsfb drm driver support both? Then we don't need to worry about
> breaking dtb's and could safely remove the mxs fbdev driver.

This might be a way forward, but again, does it justify the effort ?
We will be adding compatibility code which we will have to maintain for
maybe a handful of users I think.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>> <leonard.crestez@nxp.com> wrote:
> 
>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>
>>>> Stefan sent the same patch a few days ago:
>>>
>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>> driver entirely.
>>>
>>> That would break old DTBs, isn't this generally considered bad? Also,
>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>
>>> What my series does is make both drivers work with the same kernel
>>> image and turns the choice into a board-level dtb decision. Supporting
>>> everything at once seems desirable to me and it allows for a very
>>> smooth upgrade path.
>>
>> Having two drivers in the kernel with different set of bugs is always bad.
>>
>>> The old driver could be removed later, after all users are converted.
>>
>> Both drivers were in for long enough already. And let's be realistic,
>> how many MX23/MX28 users of old DTs with new kernels are there who
>> cannot update the DT as well ?
> 
> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> bindings are also used by 3rd-party boards for imx6/7:
>  * imx6sx-nitrogen6sx
>  * imx6ul-geam
>  * imx6ul-isiot
>  * imx6ul-opos6uldev
>  * imx6ul-pico-hobbit
>  * imx6ul-tx6ul
>  * imx7d-nitrogen7

Er, yes, a handful of boards which could be updated :)

> Converting everything might be quite a bit of work, and explicitly
> supporting old bindings is also work.

Does adding support for old bindings justify the effort invested ? I
doubt so, it only adds more code to maintain.

> It is very confusing that there is a whole set of displays for imx6/7
> which are supported by upstream but only with a non-default config.
> While it is extremely common in the embedded field to have custom
> configs the default one in the kernel should try to "just work".
> 
> Couldn't this patch series be considered a bugfix? It was also
> surprisingly small.

I think it's just a workaround which allows you to postpone the real
fix, and I don't like that.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>> <leonard.crestez@nxp.com> wrote:
> 
>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>
>>>> Stefan sent the same patch a few days ago:
>>>
>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>> driver entirely.
>>>
>>> That would break old DTBs, isn't this generally considered bad? Also,
>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>
>>> What my series does is make both drivers work with the same kernel
>>> image and turns the choice into a board-level dtb decision. Supporting
>>> everything at once seems desirable to me and it allows for a very
>>> smooth upgrade path.
>>
>> Having two drivers in the kernel with different set of bugs is always bad.
>>
>>> The old driver could be removed later, after all users are converted.
>>
>> Both drivers were in for long enough already. And let's be realistic,
>> how many MX23/MX28 users of old DTs with new kernels are there who
>> cannot update the DT as well ?
> 
> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> bindings are also used by 3rd-party boards for imx6/7:
>  * imx6sx-nitrogen6sx
>  * imx6ul-geam
>  * imx6ul-isiot
>  * imx6ul-opos6uldev
>  * imx6ul-pico-hobbit
>  * imx6ul-tx6ul
>  * imx7d-nitrogen7

Er, yes, a handful of boards which could be updated :)

> Converting everything might be quite a bit of work, and explicitly
> supporting old bindings is also work.

Does adding support for old bindings justify the effort invested ? I
doubt so, it only adds more code to maintain.

> It is very confusing that there is a whole set of displays for imx6/7
> which are supported by upstream but only with a non-default config.
> While it is extremely common in the embedded field to have custom
> configs the default one in the kernel should try to "just work".
> 
> Couldn't this patch series be considered a bugfix? It was also
> surprisingly small.

I think it's just a workaround which allows you to postpone the real
fix, and I don't like that.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>> <leonard.crestez@nxp.com> wrote:
> 
>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>
>>>> Stefan sent the same patch a few days ago:
>>>
>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>> driver entirely.
>>>
>>> That would break old DTBs, isn't this generally considered bad? Also,
>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>
>>> What my series does is make both drivers work with the same kernel
>>> image and turns the choice into a board-level dtb decision. Supporting
>>> everything at once seems desirable to me and it allows for a very
>>> smooth upgrade path.
>>
>> Having two drivers in the kernel with different set of bugs is always bad.
>>
>>> The old driver could be removed later, after all users are converted.
>>
>> Both drivers were in for long enough already. And let's be realistic,
>> how many MX23/MX28 users of old DTs with new kernels are there who
>> cannot update the DT as well ?
> 
> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> bindings are also used by 3rd-party boards for imx6/7:
>  * imx6sx-nitrogen6sx
>  * imx6ul-geam
>  * imx6ul-isiot
>  * imx6ul-opos6uldev
>  * imx6ul-pico-hobbit
>  * imx6ul-tx6ul
>  * imx7d-nitrogen7

Er, yes, a handful of boards which could be updated :)

> Converting everything might be quite a bit of work, and explicitly
> supporting old bindings is also work.

Does adding support for old bindings justify the effort invested ? I
doubt so, it only adds more code to maintain.

> It is very confusing that there is a whole set of displays for imx6/7
> which are supported by upstream but only with a non-default config.
> While it is extremely common in the embedded field to have custom
> configs the default one in the kernel should try to "just work".
> 
> Couldn't this patch series be considered a bugfix? It was also
> surprisingly small.

I think it's just a workaround which allows you to postpone the real
fix, and I don't like that.

-- 
Best regards,
Marek Vasut

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>> <leonard.crestez@nxp.com> wrote:
> 
>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>
>>>> Stefan sent the same patch a few days ago:
>>>
>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>> driver entirely.
>>>
>>> That would break old DTBs, isn't this generally considered bad? Also,
>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>
>>> What my series does is make both drivers work with the same kernel
>>> image and turns the choice into a board-level dtb decision. Supporting
>>> everything at once seems desirable to me and it allows for a very
>>> smooth upgrade path.
>>
>> Having two drivers in the kernel with different set of bugs is always bad.
>>
>>> The old driver could be removed later, after all users are converted.
>>
>> Both drivers were in for long enough already. And let's be realistic,
>> how many MX23/MX28 users of old DTs with new kernels are there who
>> cannot update the DT as well ?
> 
> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> bindings are also used by 3rd-party boards for imx6/7:
>  * imx6sx-nitrogen6sx
>  * imx6ul-geam
>  * imx6ul-isiot
>  * imx6ul-opos6uldev
>  * imx6ul-pico-hobbit
>  * imx6ul-tx6ul
>  * imx7d-nitrogen7

Er, yes, a handful of boards which could be updated :)

> Converting everything might be quite a bit of work, and explicitly
> supporting old bindings is also work.

Does adding support for old bindings justify the effort invested ? I
doubt so, it only adds more code to maintain.

> It is very confusing that there is a whole set of displays for imx6/7
> which are supported by upstream but only with a non-default config.
> While it is extremely common in the embedded field to have custom
> configs the default one in the kernel should try to "just work".
> 
> Couldn't this patch series be considered a bugfix? It was also
> surprisingly small.

I think it's just a workaround which allows you to postpone the real
fix, and I don't like that.

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> >>>> <leonard.crestez@nxp.com> wrote:
> > 
> >>>>> The FBDEV driver uses the same name and both can't be registered at the
> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
> >>>>
> >>>> Stefan sent the same patch a few days ago:
> >>>
> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
> >>> driver entirely.
> >>>
> >>> That would break old DTBs, isn't this generally considered bad? Also,
> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> >>>
> >>> What my series does is make both drivers work with the same kernel
> >>> image and turns the choice into a board-level dtb decision. Supporting
> >>> everything at once seems desirable to me and it allows for a very
> >>> smooth upgrade path.
> >>
> >> Having two drivers in the kernel with different set of bugs is always bad.
> >>
> >>> The old driver could be removed later, after all users are converted.
> >>
> >> Both drivers were in for long enough already. And let's be realistic,
> >> how many MX23/MX28 users of old DTs with new kernels are there who
> >> cannot update the DT as well ?
> > 
> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> > bindings are also used by 3rd-party boards for imx6/7:
> >  * imx6sx-nitrogen6sx
> >  * imx6ul-geam
> >  * imx6ul-isiot
> >  * imx6ul-opos6uldev
> >  * imx6ul-pico-hobbit
> >  * imx6ul-tx6ul
> >  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
> > Converting everything might be quite a bit of work, and explicitly
> > supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
> > It is very confusing that there is a whole set of displays for imx6/7
> > which are supported by upstream but only with a non-default config.
> > While it is extremely common in the embedded field to have custom
> > configs the default one in the kernel should try to "just work".
> > 
> > Couldn't this patch series be considered a bugfix? It was also
> > surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

Yeah agreed, imo the proper fix here would be to either update the dts for
the affected boards and/or make mxsfb accept the old dt bindings for
backwards compat. Artificially extending the life of the fbdev drivers
seems silly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> >>>> <leonard.crestez@nxp.com> wrote:
> > 
> >>>>> The FBDEV driver uses the same name and both can't be registered at the
> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
> >>>>
> >>>> Stefan sent the same patch a few days ago:
> >>>
> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
> >>> driver entirely.
> >>>
> >>> That would break old DTBs, isn't this generally considered bad? Also,
> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> >>>
> >>> What my series does is make both drivers work with the same kernel
> >>> image and turns the choice into a board-level dtb decision. Supporting
> >>> everything at once seems desirable to me and it allows for a very
> >>> smooth upgrade path.
> >>
> >> Having two drivers in the kernel with different set of bugs is always bad.
> >>
> >>> The old driver could be removed later, after all users are converted.
> >>
> >> Both drivers were in for long enough already. And let's be realistic,
> >> how many MX23/MX28 users of old DTs with new kernels are there who
> >> cannot update the DT as well ?
> > 
> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> > bindings are also used by 3rd-party boards for imx6/7:
> >  * imx6sx-nitrogen6sx
> >  * imx6ul-geam
> >  * imx6ul-isiot
> >  * imx6ul-opos6uldev
> >  * imx6ul-pico-hobbit
> >  * imx6ul-tx6ul
> >  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
> > Converting everything might be quite a bit of work, and explicitly
> > supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
> > It is very confusing that there is a whole set of displays for imx6/7
> > which are supported by upstream but only with a non-default config.
> > While it is extremely common in the embedded field to have custom
> > configs the default one in the kernel should try to "just work".
> > 
> > Couldn't this patch series be considered a bugfix? It was also
> > surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

Yeah agreed, imo the proper fix here would be to either update the dts for
the affected boards and/or make mxsfb accept the old dt bindings for
backwards compat. Artificially extending the life of the fbdev drivers
seems silly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> >>>> <leonard.crestez@nxp.com> wrote:
> > 
> >>>>> The FBDEV driver uses the same name and both can't be registered at the
> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
> >>>>
> >>>> Stefan sent the same patch a few days ago:
> >>>
> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
> >>> driver entirely.
> >>>
> >>> That would break old DTBs, isn't this generally considered bad? Also,
> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> >>>
> >>> What my series does is make both drivers work with the same kernel
> >>> image and turns the choice into a board-level dtb decision. Supporting
> >>> everything at once seems desirable to me and it allows for a very
> >>> smooth upgrade path.
> >>
> >> Having two drivers in the kernel with different set of bugs is always bad.
> >>
> >>> The old driver could be removed later, after all users are converted.
> >>
> >> Both drivers were in for long enough already. And let's be realistic,
> >> how many MX23/MX28 users of old DTs with new kernels are there who
> >> cannot update the DT as well ?
> > 
> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> > bindings are also used by 3rd-party boards for imx6/7:
> >  * imx6sx-nitrogen6sx
> >  * imx6ul-geam
> >  * imx6ul-isiot
> >  * imx6ul-opos6uldev
> >  * imx6ul-pico-hobbit
> >  * imx6ul-tx6ul
> >  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
> > Converting everything might be quite a bit of work, and explicitly
> > supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
> > It is very confusing that there is a whole set of displays for imx6/7
> > which are supported by upstream but only with a non-default config.
> > While it is extremely common in the embedded field to have custom
> > configs the default one in the kernel should try to "just work".
> > 
> > Couldn't this patch series be considered a bugfix? It was also
> > surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

Yeah agreed, imo the proper fix here would be to either update the dts for
the affected boards and/or make mxsfb accept the old dt bindings for
backwards compat. Artificially extending the life of the fbdev drivers
seems silly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
> >>>> <leonard.crestez@nxp.com> wrote:
> > 
> >>>>> The FBDEV driver uses the same name and both can't be registered at the
> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
> >>>>
> >>>> Stefan sent the same patch a few days ago:
> >>>
> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
> >>> driver entirely.
> >>>
> >>> That would break old DTBs, isn't this generally considered bad? Also,
> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
> >>>
> >>> What my series does is make both drivers work with the same kernel
> >>> image and turns the choice into a board-level dtb decision. Supporting
> >>> everything at once seems desirable to me and it allows for a very
> >>> smooth upgrade path.
> >>
> >> Having two drivers in the kernel with different set of bugs is always bad.
> >>
> >>> The old driver could be removed later, after all users are converted.
> >>
> >> Both drivers were in for long enough already. And let's be realistic,
> >> how many MX23/MX28 users of old DTs with new kernels are there who
> >> cannot update the DT as well ?
> > 
> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
> > bindings are also used by 3rd-party boards for imx6/7:
> >  * imx6sx-nitrogen6sx
> >  * imx6ul-geam
> >  * imx6ul-isiot
> >  * imx6ul-opos6uldev
> >  * imx6ul-pico-hobbit
> >  * imx6ul-tx6ul
> >  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
> > Converting everything might be quite a bit of work, and explicitly
> > supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
> > It is very confusing that there is a whole set of displays for imx6/7
> > which are supported by upstream but only with a non-default config.
> > While it is extremely common in the embedded field to have custom
> > configs the default one in the kernel should try to "just work".
> > 
> > Couldn't this patch series be considered a bugfix? It was also
> > surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

Yeah agreed, imo the proper fix here would be to either update the dts for
the affected boards and/or make mxsfb accept the old dt bindings for
backwards compat. Artificially extending the life of the fbdev drivers
seems silly.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 18.06.2018 09:43, Daniel Vetter wrote:
> On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> >>>> <leonard.crestez@nxp.com> wrote:
>> >
>> >>>>> The FBDEV driver uses the same name and both can't be registered at the
>> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>> >>>>
>> >>>> Stefan sent the same patch a few days ago:
>> >>>
>> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
>> >>> driver entirely.
>> >>>
>> >>> That would break old DTBs, isn't this generally considered bad? Also,
>> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>> >>>
>> >>> What my series does is make both drivers work with the same kernel
>> >>> image and turns the choice into a board-level dtb decision. Supporting
>> >>> everything at once seems desirable to me and it allows for a very
>> >>> smooth upgrade path.
>> >>
>> >> Having two drivers in the kernel with different set of bugs is always bad.
>> >>
>> >>> The old driver could be removed later, after all users are converted.
>> >>
>> >> Both drivers were in for long enough already. And let's be realistic,
>> >> how many MX23/MX28 users of old DTs with new kernels are there who
>> >> cannot update the DT as well ?
>> >
>> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> > bindings are also used by 3rd-party boards for imx6/7:
>> >  * imx6sx-nitrogen6sx
>> >  * imx6ul-geam
>> >  * imx6ul-isiot
>> >  * imx6ul-opos6uldev
>> >  * imx6ul-pico-hobbit
>> >  * imx6ul-tx6ul
>> >  * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>> > Converting everything might be quite a bit of work, and explicitly
>> > supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>> > It is very confusing that there is a whole set of displays for imx6/7
>> > which are supported by upstream but only with a non-default config.
>> > While it is extremely common in the embedded field to have custom
>> > configs the default one in the kernel should try to "just work".
>> >
>> > Couldn't this patch series be considered a bugfix? It was also
>> > surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
> 
> Yeah agreed, imo the proper fix here would be to either update the dts for
> the affected boards and/or make mxsfb accept the old dt bindings for
> backwards compat. Artificially extending the life of the fbdev drivers
> seems silly.

We shouldn't have merged a DRM driver with a driver name which conflicts
with an existing driver... If anything, this is artificially shortening
the lifetime of the fbdev driver :-)

Again, I am ok with removing the driver. I just think it is silly to do
it just because of the conflicting driver name.

Maybe Sascha, original author of the mxs fbdev driver has an opinion on
this?

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 18.06.2018 09:43, Daniel Vetter wrote:
> On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> >>>> <leonard.crestez@nxp.com> wrote:
>> >
>> >>>>> The FBDEV driver uses the same name and both can't be registered at the
>> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>> >>>>
>> >>>> Stefan sent the same patch a few days ago:
>> >>>
>> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
>> >>> driver entirely.
>> >>>
>> >>> That would break old DTBs, isn't this generally considered bad? Also,
>> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>> >>>
>> >>> What my series does is make both drivers work with the same kernel
>> >>> image and turns the choice into a board-level dtb decision. Supporting
>> >>> everything at once seems desirable to me and it allows for a very
>> >>> smooth upgrade path.
>> >>
>> >> Having two drivers in the kernel with different set of bugs is always bad.
>> >>
>> >>> The old driver could be removed later, after all users are converted.
>> >>
>> >> Both drivers were in for long enough already. And let's be realistic,
>> >> how many MX23/MX28 users of old DTs with new kernels are there who
>> >> cannot update the DT as well ?
>> >
>> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> > bindings are also used by 3rd-party boards for imx6/7:
>> >  * imx6sx-nitrogen6sx
>> >  * imx6ul-geam
>> >  * imx6ul-isiot
>> >  * imx6ul-opos6uldev
>> >  * imx6ul-pico-hobbit
>> >  * imx6ul-tx6ul
>> >  * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>> > Converting everything might be quite a bit of work, and explicitly
>> > supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>> > It is very confusing that there is a whole set of displays for imx6/7
>> > which are supported by upstream but only with a non-default config.
>> > While it is extremely common in the embedded field to have custom
>> > configs the default one in the kernel should try to "just work".
>> >
>> > Couldn't this patch series be considered a bugfix? It was also
>> > surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
> 
> Yeah agreed, imo the proper fix here would be to either update the dts for
> the affected boards and/or make mxsfb accept the old dt bindings for
> backwards compat. Artificially extending the life of the fbdev drivers
> seems silly.

We shouldn't have merged a DRM driver with a driver name which conflicts
with an existing driver... If anything, this is artificially shortening
the lifetime of the fbdev driver :-)

Again, I am ok with removing the driver. I just think it is silly to do
it just because of the conflicting driver name.

Maybe Sascha, original author of the mxs fbdev driver has an opinion on
this?

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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 18.06.2018 09:43, Daniel Vetter wrote:
> On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> >>>> <leonard.crestez@nxp.com> wrote:
>> >
>> >>>>> The FBDEV driver uses the same name and both can't be registered at the
>> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>> >>>>
>> >>>> Stefan sent the same patch a few days ago:
>> >>>
>> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
>> >>> driver entirely.
>> >>>
>> >>> That would break old DTBs, isn't this generally considered bad? Also,
>> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>> >>>
>> >>> What my series does is make both drivers work with the same kernel
>> >>> image and turns the choice into a board-level dtb decision. Supporting
>> >>> everything at once seems desirable to me and it allows for a very
>> >>> smooth upgrade path.
>> >>
>> >> Having two drivers in the kernel with different set of bugs is always bad.
>> >>
>> >>> The old driver could be removed later, after all users are converted.
>> >>
>> >> Both drivers were in for long enough already. And let's be realistic,
>> >> how many MX23/MX28 users of old DTs with new kernels are there who
>> >> cannot update the DT as well ?
>> >
>> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> > bindings are also used by 3rd-party boards for imx6/7:
>> >  * imx6sx-nitrogen6sx
>> >  * imx6ul-geam
>> >  * imx6ul-isiot
>> >  * imx6ul-opos6uldev
>> >  * imx6ul-pico-hobbit
>> >  * imx6ul-tx6ul
>> >  * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>> > Converting everything might be quite a bit of work, and explicitly
>> > supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>> > It is very confusing that there is a whole set of displays for imx6/7
>> > which are supported by upstream but only with a non-default config.
>> > While it is extremely common in the embedded field to have custom
>> > configs the default one in the kernel should try to "just work".
>> >
>> > Couldn't this patch series be considered a bugfix? It was also
>> > surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
> 
> Yeah agreed, imo the proper fix here would be to either update the dts for
> the affected boards and/or make mxsfb accept the old dt bindings for
> backwards compat. Artificially extending the life of the fbdev drivers
> seems silly.

We shouldn't have merged a DRM driver with a driver name which conflicts
with an existing driver... If anything, this is artificially shortening
the lifetime of the fbdev driver :-)

Again, I am ok with removing the driver. I just think it is silly to do
it just because of the conflicting driver name.

Maybe Sascha, original author of the mxs fbdev driver has an opinion on
this?

--
Stefan

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 18.06.2018 09:43, Daniel Vetter wrote:
> On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> > On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>> >> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>> >>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>> >>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>> >>>> <leonard.crestez@nxp.com> wrote:
>> >
>> >>>>> The FBDEV driver uses the same name and both can't be registered at the
>> >>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>> >>>>
>> >>>> Stefan sent the same patch a few days ago:
>> >>>
>> >>> In that thread there is a proposal for removing the old fbdev/mxsfb
>> >>> driver entirely.
>> >>>
>> >>> That would break old DTBs, isn't this generally considered bad? Also,
>> >>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>> >>>
>> >>> What my series does is make both drivers work with the same kernel
>> >>> image and turns the choice into a board-level dtb decision. Supporting
>> >>> everything at once seems desirable to me and it allows for a very
>> >>> smooth upgrade path.
>> >>
>> >> Having two drivers in the kernel with different set of bugs is always bad.
>> >>
>> >>> The old driver could be removed later, after all users are converted.
>> >>
>> >> Both drivers were in for long enough already. And let's be realistic,
>> >> how many MX23/MX28 users of old DTs with new kernels are there who
>> >> cannot update the DT as well ?
>> >
>> > Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> > bindings are also used by 3rd-party boards for imx6/7:
>> >  * imx6sx-nitrogen6sx
>> >  * imx6ul-geam
>> >  * imx6ul-isiot
>> >  * imx6ul-opos6uldev
>> >  * imx6ul-pico-hobbit
>> >  * imx6ul-tx6ul
>> >  * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>> > Converting everything might be quite a bit of work, and explicitly
>> > supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>> > It is very confusing that there is a whole set of displays for imx6/7
>> > which are supported by upstream but only with a non-default config.
>> > While it is extremely common in the embedded field to have custom
>> > configs the default one in the kernel should try to "just work".
>> >
>> > Couldn't this patch series be considered a bugfix? It was also
>> > surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
> 
> Yeah agreed, imo the proper fix here would be to either update the dts for
> the affected boards and/or make mxsfb accept the old dt bindings for
> backwards compat. Artificially extending the life of the fbdev drivers
> seems silly.

We shouldn't have merged a DRM driver with a driver name which conflicts
with an existing driver... If anything, this is artificially shortening
the lifetime of the fbdev driver :-)

Again, I am ok with removing the driver. I just think it is silly to do
it just because of the conflicting driver name.

Maybe Sascha, original author of the mxs fbdev driver has an opinion on
this?

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 16.06.2018 01:32, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>> <leonard.crestez@nxp.com> wrote:
>>
>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>
>>>>> Stefan sent the same patch a few days ago:
>>>>
>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>> driver entirely.
>>>>
>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>
>>>> What my series does is make both drivers work with the same kernel
>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>> everything at once seems desirable to me and it allows for a very
>>>> smooth upgrade path.
>>>
>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>
>>>> The old driver could be removed later, after all users are converted.
>>>
>>> Both drivers were in for long enough already. And let's be realistic,
>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>> cannot update the DT as well ?
>>
>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> bindings are also used by 3rd-party boards for imx6/7:
>>  * imx6sx-nitrogen6sx
>>  * imx6ul-geam
>>  * imx6ul-isiot
>>  * imx6ul-opos6uldev
>>  * imx6ul-pico-hobbit
>>  * imx6ul-tx6ul
>>  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
>> Converting everything might be quite a bit of work, and explicitly
>> supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
>> It is very confusing that there is a whole set of displays for imx6/7
>> which are supported by upstream but only with a non-default config.
>> While it is extremely common in the embedded field to have custom
>> configs the default one in the kernel should try to "just work".
>>
>> Couldn't this patch series be considered a bugfix? It was also
>> surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

This is one of the situation where states quo is kinda the worst
situation.

Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
CONFIG_FB_MXS.

I understand that you'd rather prefer to move forward. I suggest we do
it in steps.

In 4.19:

- Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
- Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
only enable CONFIG_DRM_MXSFB=y
- Add (deprecated) to CONFIG_FB_MXS

In 4.19/4.20:
- Fix the above device trees

In 4.20/4.21:
- Remove FB_MXS

Does that sound reasonable? If yes, I can send the patch set to do step
1.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 16.06.2018 01:32, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>> <leonard.crestez@nxp.com> wrote:
>>
>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>
>>>>> Stefan sent the same patch a few days ago:
>>>>
>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>> driver entirely.
>>>>
>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>
>>>> What my series does is make both drivers work with the same kernel
>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>> everything at once seems desirable to me and it allows for a very
>>>> smooth upgrade path.
>>>
>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>
>>>> The old driver could be removed later, after all users are converted.
>>>
>>> Both drivers were in for long enough already. And let's be realistic,
>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>> cannot update the DT as well ?
>>
>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> bindings are also used by 3rd-party boards for imx6/7:
>>  * imx6sx-nitrogen6sx
>>  * imx6ul-geam
>>  * imx6ul-isiot
>>  * imx6ul-opos6uldev
>>  * imx6ul-pico-hobbit
>>  * imx6ul-tx6ul
>>  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
>> Converting everything might be quite a bit of work, and explicitly
>> supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
>> It is very confusing that there is a whole set of displays for imx6/7
>> which are supported by upstream but only with a non-default config.
>> While it is extremely common in the embedded field to have custom
>> configs the default one in the kernel should try to "just work".
>>
>> Couldn't this patch series be considered a bugfix? It was also
>> surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

This is one of the situation where states quo is kinda the worst
situation.

Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
CONFIG_FB_MXS.

I understand that you'd rather prefer to move forward. I suggest we do
it in steps.

In 4.19:

- Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
- Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
only enable CONFIG_DRM_MXSFB=y
- Add (deprecated) to CONFIG_FB_MXS

In 4.19/4.20:
- Fix the above device trees

In 4.20/4.21:
- Remove FB_MXS

Does that sound reasonable? If yes, I can send the patch set to do step
1.

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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 16.06.2018 01:32, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>> <leonard.crestez@nxp.com> wrote:
>>
>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>
>>>>> Stefan sent the same patch a few days ago:
>>>>
>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>> driver entirely.
>>>>
>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>
>>>> What my series does is make both drivers work with the same kernel
>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>> everything at once seems desirable to me and it allows for a very
>>>> smooth upgrade path.
>>>
>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>
>>>> The old driver could be removed later, after all users are converted.
>>>
>>> Both drivers were in for long enough already. And let's be realistic,
>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>> cannot update the DT as well ?
>>
>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> bindings are also used by 3rd-party boards for imx6/7:
>>  * imx6sx-nitrogen6sx
>>  * imx6ul-geam
>>  * imx6ul-isiot
>>  * imx6ul-opos6uldev
>>  * imx6ul-pico-hobbit
>>  * imx6ul-tx6ul
>>  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
>> Converting everything might be quite a bit of work, and explicitly
>> supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
>> It is very confusing that there is a whole set of displays for imx6/7
>> which are supported by upstream but only with a non-default config.
>> While it is extremely common in the embedded field to have custom
>> configs the default one in the kernel should try to "just work".
>>
>> Couldn't this patch series be considered a bugfix? It was also
>> surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

This is one of the situation where states quo is kinda the worst
situation.

Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
CONFIG_FB_MXS.

I understand that you'd rather prefer to move forward. I suggest we do
it in steps.

In 4.19:

- Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
- Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
only enable CONFIG_DRM_MXSFB=y
- Add (deprecated) to CONFIG_FB_MXS

In 4.19/4.20:
- Fix the above device trees

In 4.20/4.21:
- Remove FB_MXS

Does that sound reasonable? If yes, I can send the patch set to do step
1.

--
Stefan

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 16.06.2018 01:32, Marek Vasut wrote:
> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>> <leonard.crestez@nxp.com> wrote:
>>
>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>
>>>>> Stefan sent the same patch a few days ago:
>>>>
>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>> driver entirely.
>>>>
>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>
>>>> What my series does is make both drivers work with the same kernel
>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>> everything at once seems desirable to me and it allows for a very
>>>> smooth upgrade path.
>>>
>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>
>>>> The old driver could be removed later, after all users are converted.
>>>
>>> Both drivers were in for long enough already. And let's be realistic,
>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>> cannot update the DT as well ?
>>
>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>> bindings are also used by 3rd-party boards for imx6/7:
>>  * imx6sx-nitrogen6sx
>>  * imx6ul-geam
>>  * imx6ul-isiot
>>  * imx6ul-opos6uldev
>>  * imx6ul-pico-hobbit
>>  * imx6ul-tx6ul
>>  * imx7d-nitrogen7
> 
> Er, yes, a handful of boards which could be updated :)
> 
>> Converting everything might be quite a bit of work, and explicitly
>> supporting old bindings is also work.
> 
> Does adding support for old bindings justify the effort invested ? I
> doubt so, it only adds more code to maintain.
> 
>> It is very confusing that there is a whole set of displays for imx6/7
>> which are supported by upstream but only with a non-default config.
>> While it is extremely common in the embedded field to have custom
>> configs the default one in the kernel should try to "just work".
>>
>> Couldn't this patch series be considered a bugfix? It was also
>> surprisingly small.
> 
> I think it's just a workaround which allows you to postpone the real
> fix, and I don't like that.

This is one of the situation where states quo is kinda the worst
situation.

Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
CONFIG_FB_MXS.

I understand that you'd rather prefer to move forward. I suggest we do
it in steps.

In 4.19:

- Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
- Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
only enable CONFIG_DRM_MXSFB=y
- Add (deprecated) to CONFIG_FB_MXS

In 4.19/4.20:
- Fix the above device trees

In 4.20/4.21:
- Remove FB_MXS

Does that sound reasonable? If yes, I can send the patch set to do step
1.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/10/2018 11:06 AM, Stefan Agner wrote:
> On 16.06.2018 01:32, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>> <leonard.crestez@nxp.com> wrote:
>>>
>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>
>>>>>> Stefan sent the same patch a few days ago:
>>>>>
>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>> driver entirely.
>>>>>
>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>
>>>>> What my series does is make both drivers work with the same kernel
>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>> everything at once seems desirable to me and it allows for a very
>>>>> smooth upgrade path.
>>>>
>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>
>>>>> The old driver could be removed later, after all users are converted.
>>>>
>>>> Both drivers were in for long enough already. And let's be realistic,
>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>> cannot update the DT as well ?
>>>
>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>> bindings are also used by 3rd-party boards for imx6/7:
>>>  * imx6sx-nitrogen6sx
>>>  * imx6ul-geam
>>>  * imx6ul-isiot
>>>  * imx6ul-opos6uldev
>>>  * imx6ul-pico-hobbit
>>>  * imx6ul-tx6ul
>>>  * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>>> Converting everything might be quite a bit of work, and explicitly
>>> supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>>> It is very confusing that there is a whole set of displays for imx6/7
>>> which are supported by upstream but only with a non-default config.
>>> While it is extremely common in the embedded field to have custom
>>> configs the default one in the kernel should try to "just work".
>>>
>>> Couldn't this patch series be considered a bugfix? It was also
>>> surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
> 
> This is one of the situation where states quo is kinda the worst
> situation.
> 
> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> CONFIG_FB_MXS.
> 
> I understand that you'd rather prefer to move forward. I suggest we do
> it in steps.
> 
> In 4.19:
> 
> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now

But this will break mesa if it depends on mxsfb name for ie. etnaviv
binding.

> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> only enable CONFIG_DRM_MXSFB=y
> - Add (deprecated) to CONFIG_FB_MXS
> 
> In 4.19/4.20:
> - Fix the above device trees
> 
> In 4.20/4.21:
> - Remove FB_MXS
> 
> Does that sound reasonable? If yes, I can send the patch set to do step
> 1.

Can you fix the DTs for 4.19 too ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/10/2018 11:06 AM, Stefan Agner wrote:
> On 16.06.2018 01:32, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>> <leonard.crestez@nxp.com> wrote:
>>>
>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>
>>>>>> Stefan sent the same patch a few days ago:
>>>>>
>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>> driver entirely.
>>>>>
>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>
>>>>> What my series does is make both drivers work with the same kernel
>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>> everything at once seems desirable to me and it allows for a very
>>>>> smooth upgrade path.
>>>>
>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>
>>>>> The old driver could be removed later, after all users are converted.
>>>>
>>>> Both drivers were in for long enough already. And let's be realistic,
>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>> cannot update the DT as well ?
>>>
>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>> bindings are also used by 3rd-party boards for imx6/7:
>>>  * imx6sx-nitrogen6sx
>>>  * imx6ul-geam
>>>  * imx6ul-isiot
>>>  * imx6ul-opos6uldev
>>>  * imx6ul-pico-hobbit
>>>  * imx6ul-tx6ul
>>>  * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>>> Converting everything might be quite a bit of work, and explicitly
>>> supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>>> It is very confusing that there is a whole set of displays for imx6/7
>>> which are supported by upstream but only with a non-default config.
>>> While it is extremely common in the embedded field to have custom
>>> configs the default one in the kernel should try to "just work".
>>>
>>> Couldn't this patch series be considered a bugfix? It was also
>>> surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
> 
> This is one of the situation where states quo is kinda the worst
> situation.
> 
> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> CONFIG_FB_MXS.
> 
> I understand that you'd rather prefer to move forward. I suggest we do
> it in steps.
> 
> In 4.19:
> 
> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now

But this will break mesa if it depends on mxsfb name for ie. etnaviv
binding.

> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> only enable CONFIG_DRM_MXSFB=y
> - Add (deprecated) to CONFIG_FB_MXS
> 
> In 4.19/4.20:
> - Fix the above device trees
> 
> In 4.20/4.21:
> - Remove FB_MXS
> 
> Does that sound reasonable? If yes, I can send the patch set to do step
> 1.

Can you fix the DTs for 4.19 too ?

-- 
Best regards,
Marek Vasut

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/10/2018 11:06 AM, Stefan Agner wrote:
> On 16.06.2018 01:32, Marek Vasut wrote:
>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>> <leonard.crestez@nxp.com> wrote:
>>>
>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>
>>>>>> Stefan sent the same patch a few days ago:
>>>>>
>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>> driver entirely.
>>>>>
>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>
>>>>> What my series does is make both drivers work with the same kernel
>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>> everything at once seems desirable to me and it allows for a very
>>>>> smooth upgrade path.
>>>>
>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>
>>>>> The old driver could be removed later, after all users are converted.
>>>>
>>>> Both drivers were in for long enough already. And let's be realistic,
>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>> cannot update the DT as well ?
>>>
>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>> bindings are also used by 3rd-party boards for imx6/7:
>>>  * imx6sx-nitrogen6sx
>>>  * imx6ul-geam
>>>  * imx6ul-isiot
>>>  * imx6ul-opos6uldev
>>>  * imx6ul-pico-hobbit
>>>  * imx6ul-tx6ul
>>>  * imx7d-nitrogen7
>>
>> Er, yes, a handful of boards which could be updated :)
>>
>>> Converting everything might be quite a bit of work, and explicitly
>>> supporting old bindings is also work.
>>
>> Does adding support for old bindings justify the effort invested ? I
>> doubt so, it only adds more code to maintain.
>>
>>> It is very confusing that there is a whole set of displays for imx6/7
>>> which are supported by upstream but only with a non-default config.
>>> While it is extremely common in the embedded field to have custom
>>> configs the default one in the kernel should try to "just work".
>>>
>>> Couldn't this patch series be considered a bugfix? It was also
>>> surprisingly small.
>>
>> I think it's just a workaround which allows you to postpone the real
>> fix, and I don't like that.
> 
> This is one of the situation where states quo is kinda the worst
> situation.
> 
> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> CONFIG_FB_MXS.
> 
> I understand that you'd rather prefer to move forward. I suggest we do
> it in steps.
> 
> In 4.19:
> 
> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now

But this will break mesa if it depends on mxsfb name for ie. etnaviv
binding.

> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> only enable CONFIG_DRM_MXSFB=y
> - Add (deprecated) to CONFIG_FB_MXS
> 
> In 4.19/4.20:
> - Fix the above device trees
> 
> In 4.20/4.21:
> - Remove FB_MXS
> 
> Does that sound reasonable? If yes, I can send the patch set to do step
> 1.

Can you fix the DTs for 4.19 too ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 

Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.

There is also .name in struct drm_driver, which is already set to
mxsfb-drm... Is that the one exposed to user space?

>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Getting tight, but will try.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 

Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.

There is also .name in struct drm_driver, which is already set to
mxsfb-drm... Is that the one exposed to user space?

>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Getting tight, but will try.

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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 

Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.

There is also .name in struct drm_driver, which is already set to
mxsfb-drm... Is that the one exposed to user space?

>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Getting tight, but will try.

--
Stefan

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 

Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.

There is also .name in struct drm_driver, which is already set to
mxsfb-drm... Is that the one exposed to user space?

>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Getting tight, but will try.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

[adding Authors of the problematic device trees]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Unfortunately updating the device trees turned out to be a non trivial
task especially as an outsider. The display needs to be supported in
drivers/gpu/drm/panel/panel-simple.c. Some displays might be already in
place, but if not, the display need to be added. Since for panel
bindings vendor and product information are needed, it is not possible
as an outsiders to make the conversion.

Jagan, Sebastien, Fabio, Lothar and Gary, could you maybe update the
respective device trees?

A conversion to the new bindings similar to commit a027d49fc193 ("ARM:
dts: imx7-colibri: use OF graph to describe the display") is what we are
looking for.

This will make sure that the boards keep working using the new MXSFB DRM
driver.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

[adding Authors of the problematic device trees]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Unfortunately updating the device trees turned out to be a non trivial
task especially as an outsider. The display needs to be supported in
drivers/gpu/drm/panel/panel-simple.c. Some displays might be already in
place, but if not, the display need to be added. Since for panel
bindings vendor and product information are needed, it is not possible
as an outsiders to make the conversion.

Jagan, Sebastien, Fabio, Lothar and Gary, could you maybe update the
respective device trees?

A conversion to the new bindings similar to commit a027d49fc193 ("ARM:
dts: imx7-colibri: use OF graph to describe the display") is what we are
looking for.

This will make sure that the boards keep working using the new MXSFB DRM
driver.

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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

[adding Authors of the problematic device trees]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Unfortunately updating the device trees turned out to be a non trivial
task especially as an outsider. The display needs to be supported in
drivers/gpu/drm/panel/panel-simple.c. Some displays might be already in
place, but if not, the display need to be added. Since for panel
bindings vendor and product information are needed, it is not possible
as an outsiders to make the conversion.

Jagan, Sebastien, Fabio, Lothar and Gary, could you maybe update the
respective device trees?

A conversion to the new bindings similar to commit a027d49fc193 ("ARM:
dts: imx7-colibri: use OF graph to describe the display") is what we are
looking for.

This will make sure that the boards keep working using the new MXSFB DRM
driver.

--
Stefan

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

[adding Authors of the problematic device trees]

On 10.07.2018 11:11, Marek Vasut wrote:
> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> On 16.06.2018 01:32, Marek Vasut wrote:
>>> On 06/16/2018 12:42 AM, Leonard Crestez wrote:
>>>> On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:
>>>>> On 06/15/2018 10:58 PM, Leonard Crestez wrote:
>>>>>> On Fri, 2018-06-15 at 16:47 -0300, Fabio Estevam wrote:
>>>>>>> On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
>>>>>>> <leonard.crestez@nxp.com> wrote:
>>>>
>>>>>>>> The FBDEV driver uses the same name and both can't be registered at the
>>>>>>>> same time. Fix this by renaming the drm driver to mxsfb-drm
>>>>>>>
>>>>>>> Stefan sent the same patch a few days ago:
>>>>>>
>>>>>> In that thread there is a proposal for removing the old fbdev/mxsfb
>>>>>> driver entirely.
>>>>>>
>>>>>> That would break old DTBs, isn't this generally considered bad? Also,
>>>>>> are we sure the removal of fbdev/mxsfb wouldn't lose any features?
>>>>>>
>>>>>> What my series does is make both drivers work with the same kernel
>>>>>> image and turns the choice into a board-level dtb decision. Supporting
>>>>>> everything at once seems desirable to me and it allows for a very
>>>>>> smooth upgrade path.
>>>>>
>>>>> Having two drivers in the kernel with different set of bugs is always bad.
>>>>>
>>>>>> The old driver could be removed later, after all users are converted.
>>>>>
>>>>> Both drivers were in for long enough already. And let's be realistic,
>>>>> how many MX23/MX28 users of old DTs with new kernels are there who
>>>>> cannot update the DT as well ?
>>>>
>>>> Grepping for "display =" in arch/arm/boot/dts/imx* I see that old
>>>> bindings are also used by 3rd-party boards for imx6/7:
>>>>  * imx6sx-nitrogen6sx
>>>>  * imx6ul-geam
>>>>  * imx6ul-isiot
>>>>  * imx6ul-opos6uldev
>>>>  * imx6ul-pico-hobbit
>>>>  * imx6ul-tx6ul
>>>>  * imx7d-nitrogen7
>>>
>>> Er, yes, a handful of boards which could be updated :)
>>>
>>>> Converting everything might be quite a bit of work, and explicitly
>>>> supporting old bindings is also work.
>>>
>>> Does adding support for old bindings justify the effort invested ? I
>>> doubt so, it only adds more code to maintain.
>>>
>>>> It is very confusing that there is a whole set of displays for imx6/7
>>>> which are supported by upstream but only with a non-default config.
>>>> While it is extremely common in the embedded field to have custom
>>>> configs the default one in the kernel should try to "just work".
>>>>
>>>> Couldn't this patch series be considered a bugfix? It was also
>>>> surprisingly small.
>>>
>>> I think it's just a workaround which allows you to postpone the real
>>> fix, and I don't like that.
>>
>> This is one of the situation where states quo is kinda the worst
>> situation.
>>
>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> CONFIG_FB_MXS.
>>
>> I understand that you'd rather prefer to move forward. I suggest we do
>> it in steps.
>>
>> In 4.19:
>>
>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> 
> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> binding.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
>> - Add (deprecated) to CONFIG_FB_MXS
>>
>> In 4.19/4.20:
>> - Fix the above device trees
>>
>> In 4.20/4.21:
>> - Remove FB_MXS
>>
>> Does that sound reasonable? If yes, I can send the patch set to do step
>> 1.
> 
> Can you fix the DTs for 4.19 too ?

Unfortunately updating the device trees turned out to be a non trivial
task especially as an outsider. The display needs to be supported in
drivers/gpu/drm/panel/panel-simple.c. Some displays might be already in
place, but if not, the display need to be added. Since for panel
bindings vendor and product information are needed, it is not possible
as an outsiders to make the conversion.

Jagan, Sebastien, Fabio, Lothar and Gary, could you maybe update the
respective device trees?

A conversion to the new bindings similar to commit a027d49fc193 ("ARM:
dts: imx7-colibri: use OF graph to describe the display") is what we are
looking for.

This will make sure that the boards keep working using the new MXSFB DRM
driver.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> On 10.07.2018 11:11, Marek Vasut wrote:
> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
> > > This is one of the situation where states quo is kinda the worst
> > > situation.
> > > 
> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> > > CONFIG_FB_MXS.
> > > 
> > > I understand that you'd rather prefer to move forward. I suggest we do
> > > it in steps.
> > > 
> > > In 4.19:
> > > 
> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> > 
> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
> > binding.
> 
> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> 
> There is also .name in struct drm_driver, which is already set to
> mxsfb-drm... Is that the one exposed to user space?

Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
sdb.

Tools like modetest already need -M mxsfb-drm, the drm_driver.name
seems to be what matters.

> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> only enable CONFIG_DRM_MXSFB=y

If one of the drivers is renamed then they can coexist: since the
bindings are distinct one driver will return a probe error and the
other will bind successfully. This can even be adjusted so that it
doesn't even print ugly scary errors.

This can last until somebody implements support for old bindings in the
drm driver and then FB_MXS can just be deleted.

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> On 10.07.2018 11:11, Marek Vasut wrote:
> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
> > > This is one of the situation where states quo is kinda the worst
> > > situation.
> > > 
> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> > > CONFIG_FB_MXS.
> > > 
> > > I understand that you'd rather prefer to move forward. I suggest we do
> > > it in steps.
> > > 
> > > In 4.19:
> > > 
> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> > 
> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
> > binding.
> 
> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> 
> There is also .name in struct drm_driver, which is already set to
> mxsfb-drm... Is that the one exposed to user space?

Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
sdb.

Tools like modetest already need -M mxsfb-drm, the drm_driver.name
seems to be what matters.

> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> only enable CONFIG_DRM_MXSFB=y

If one of the drivers is renamed then they can coexist: since the
bindings are distinct one driver will return a probe error and the
other will bind successfully. This can even be adjusted so that it
doesn't even print ugly scary errors.

This can last until somebody implements support for old bindings in the
drm driver and then FB_MXS can just be deleted.

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

T24gVGh1LCAyMDE4LTA3LTEyIGF0IDExOjIxICswMjAwLCBTdGVmYW4gQWduZXIgd3JvdGU6DQo+
IE9uIDEwLjA3LjIwMTggMTE6MTEsIE1hcmVrIFZhc3V0IHdyb3RlOg0KPiA+IE9uIDA3LzEwLzIw
MTggMTE6MDYgQU0sIFN0ZWZhbiBBZ25lciB3cm90ZToNCj4gPiA+IFRoaXMgaXMgb25lIG9mIHRo
ZSBzaXR1YXRpb24gd2hlcmUgc3RhdGVzIHF1byBpcyBraW5kYSB0aGUgd29yc3QNCj4gPiA+IHNp
dHVhdGlvbi4NCj4gPiA+IA0KPiA+ID4gQ3VycmVudGx5IGlteF92Nl92N19kZWZjb25maWcgYW5k
IG14c19kZWZjb25maWcgYWN0dWFsbHkgc3RpbGwgdXNlcw0KPiA+ID4gQ09ORklHX0ZCX01YUy4N
Cj4gPiA+IA0KPiA+ID4gSSB1bmRlcnN0YW5kIHRoYXQgeW91J2QgcmF0aGVyIHByZWZlciB0byBt
b3ZlIGZvcndhcmQuIEkgc3VnZ2VzdCB3ZSBkbw0KPiA+ID4gaXQgaW4gc3RlcHMuDQo+ID4gPiAN
Cj4gPiA+IEluIDQuMTk6DQo+ID4gPiANCj4gPiA+IC0gQ2hhbmdlIERSTSBkcml2ZXIubmFtZSB0
byBteHNmYi1kcm0gc28gd2UgYXZvaWQgY29uZmxpY3RzIGZvciBub3cNCj4gPiANCj4gPiBCdXQg
dGhpcyB3aWxsIGJyZWFrIG1lc2EgaWYgaXQgZGVwZW5kcyBvbiBteHNmYiBuYW1lIGZvciBpZS4g
ZXRuYXZpdg0KPiA+IGJpbmRpbmcuDQo+IA0KPiBEb2VzIGl0PyBncmVwIC1yIC1lIG14c2ZiIGlu
IGxpYmRybSBhbmQgbWVzYSBtYXN0ZXIgcmV0dXJucyBub3RoaW5nLg0KPiANCj4gVGhlcmUgaXMg
YWxzbyAubmFtZSBpbiBzdHJ1Y3QgZHJtX2RyaXZlciwgd2hpY2ggaXMgYWxyZWFkeSBzZXQgdG8N
Cj4gbXhzZmItZHJtLi4uIElzIHRoYXQgdGhlIG9uZSBleHBvc2VkIHRvIHVzZXIgc3BhY2U/DQoN
ClJ1bm5pbmcgZXRuYXZpdit4MTEgd2l0aCBhIHJlbmFtZWQgbXhzZmIgZHJpdmVyIHdvcmtzIGZp
bmUgb24gaW14NnN4LQ0Kc2RiLg0KDQpUb29scyBsaWtlIG1vZGV0ZXN0IGFscmVhZHkgbmVlZCAt
TSBteHNmYi1kcm0sIHRoZSBkcm1fZHJpdmVyLm5hbWUNCnNlZW1zIHRvIGJlIHdoYXQgbWF0dGVy
cy4NCg0KPiAtIFJlbW92ZSBDT05GSUdfRkJfTVhTIGZyb20gaW14X3Y2X3Y3X2RlZmNvbmZpZy9t
eHNfZGVmY29uZmlnIG5vdywgYW5kDQo+IG9ubHkgZW5hYmxlIENPTkZJR19EUk1fTVhTRkI9eQ0K
DQpJZiBvbmUgb2YgdGhlIGRyaXZlcnMgaXMgcmVuYW1lZCB0aGVuIHRoZXkgY2FuIGNvZXhpc3Q6
IHNpbmNlIHRoZQ0KYmluZGluZ3MgYXJlIGRpc3RpbmN0IG9uZSBkcml2ZXIgd2lsbCByZXR1cm4g
YSBwcm9iZSBlcnJvciBhbmQgdGhlDQpvdGhlciB3aWxsIGJpbmQgc3VjY2Vzc2Z1bGx5LiBUaGlz
IGNhbiBldmVuIGJlIGFkanVzdGVkIHNvIHRoYXQgaXQNCmRvZXNuJ3QgZXZlbiBwcmludCB1Z2x5
IHNjYXJ5IGVycm9ycy4NCg0KVGhpcyBjYW4gbGFzdCB1bnRpbCBzb21lYm9keSBpbXBsZW1lbnRz
IHN1cHBvcnQgZm9yIG9sZCBiaW5kaW5ncyBpbiB0aGUNCmRybSBkcml2ZXIgYW5kIHRoZW4gRkJf
TVhTIGNhbiBqdXN0IGJlIGRlbGV0ZWQu

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> On 10.07.2018 11:11, Marek Vasut wrote:
> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
> > > This is one of the situation where states quo is kinda the worst
> > > situation.
> > > 
> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> > > CONFIG_FB_MXS.
> > > 
> > > I understand that you'd rather prefer to move forward. I suggest we do
> > > it in steps.
> > > 
> > > In 4.19:
> > > 
> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> > 
> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
> > binding.
> 
> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> 
> There is also .name in struct drm_driver, which is already set to
> mxsfb-drm... Is that the one exposed to user space?

Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
sdb.

Tools like modetest already need -M mxsfb-drm, the drm_driver.name
seems to be what matters.

> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> only enable CONFIG_DRM_MXSFB=y

If one of the drivers is renamed then they can coexist: since the
bindings are distinct one driver will return a probe error and the
other will bind successfully. This can even be adjusted so that it
doesn't even print ugly scary errors.

This can last until somebody implements support for old bindings in the
drm driver and then FB_MXS can just be deleted.

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>>>> This is one of the situation where states quo is kinda the worst
>>>> situation.
>>>>
>>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>>>> CONFIG_FB_MXS.
>>>>
>>>> I understand that you'd rather prefer to move forward. I suggest we do
>>>> it in steps.
>>>>
>>>> In 4.19:
>>>>
>>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>>>
>>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
>>> binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

So why don't we just convert the DT bindings on boards supported
upstream and zap the old driver ? What is the problem with that?

Realistically, how many MXS boards in the field use old DT and new kernel ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>>>> This is one of the situation where states quo is kinda the worst
>>>> situation.
>>>>
>>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>>>> CONFIG_FB_MXS.
>>>>
>>>> I understand that you'd rather prefer to move forward. I suggest we do
>>>> it in steps.
>>>>
>>>> In 4.19:
>>>>
>>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>>>
>>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
>>> binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

So why don't we just convert the DT bindings on boards supported
upstream and zap the old driver ? What is the problem with that?

Realistically, how many MXS boards in the field use old DT and new kernel ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>>>> This is one of the situation where states quo is kinda the worst
>>>> situation.
>>>>
>>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>>>> CONFIG_FB_MXS.
>>>>
>>>> I understand that you'd rather prefer to move forward. I suggest we do
>>>> it in steps.
>>>>
>>>> In 4.19:
>>>>
>>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>>>
>>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
>>> binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

So why don't we just convert the DT bindings on boards supported
upstream and zap the old driver ? What is the problem with that?

Realistically, how many MXS boards in the field use old DT and new kernel ?

-- 
Best regards,
Marek Vasut

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>>>> This is one of the situation where states quo is kinda the worst
>>>> situation.
>>>>
>>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>>>> CONFIG_FB_MXS.
>>>>
>>>> I understand that you'd rather prefer to move forward. I suggest we do
>>>> it in steps.
>>>>
>>>> In 4.19:
>>>>
>>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>>>
>>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
>>> binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

So why don't we just convert the DT bindings on boards supported
upstream and zap the old driver ? What is the problem with that?

Realistically, how many MXS boards in the field use old DT and new kernel ?

-- 
Best regards,
Marek Vasut

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 12.07.2018 15:03, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> > > This is one of the situation where states quo is kinda the worst
>> > > situation.
>> > >
>> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> > > CONFIG_FB_MXS.
>> > >
>> > > I understand that you'd rather prefer to move forward. I suggest we do
>> > > it in steps.
>> > >
>> > > In 4.19:
>> > >
>> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>> >
>> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
>> > binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.

Ok, almost thought so, thanks for the confirmation! So we should be
good.

> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

Yeah I guess that is what Marek don't want because it promotes using
FB_MXS for longer than needed.

I don't care as much since we anyway use the MXSFB DRM driver. However,
what I really dislike is that a kernel compiled with both drivers
currently leads to MXSFB DRM being unusable (because fbdev gets probed
first). I feel removing the MXS_FB is rather harsh, so I *really* would
love to see the MXSFB DRM driver renamed.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 12.07.2018 15:03, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> > > This is one of the situation where states quo is kinda the worst
>> > > situation.
>> > >
>> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> > > CONFIG_FB_MXS.
>> > >
>> > > I understand that you'd rather prefer to move forward. I suggest we do
>> > > it in steps.
>> > >
>> > > In 4.19:
>> > >
>> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>> >
>> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
>> > binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.

Ok, almost thought so, thanks for the confirmation! So we should be
good.

> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

Yeah I guess that is what Marek don't want because it promotes using
FB_MXS for longer than needed.

I don't care as much since we anyway use the MXSFB DRM driver. However,
what I really dislike is that a kernel compiled with both drivers
currently leads to MXSFB DRM being unusable (because fbdev gets probed
first). I feel removing the MXS_FB is rather harsh, so I *really* would
love to see the MXSFB DRM driver renamed.

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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 12.07.2018 15:03, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> > > This is one of the situation where states quo is kinda the worst
>> > > situation.
>> > >
>> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> > > CONFIG_FB_MXS.
>> > >
>> > > I understand that you'd rather prefer to move forward. I suggest we do
>> > > it in steps.
>> > >
>> > > In 4.19:
>> > >
>> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>> >
>> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
>> > binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.

Ok, almost thought so, thanks for the confirmation! So we should be
good.

> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

Yeah I guess that is what Marek don't want because it promotes using
FB_MXS for longer than needed.

I don't care as much since we anyway use the MXSFB DRM driver. However,
what I really dislike is that a kernel compiled with both drivers
currently leads to MXSFB DRM being unusable (because fbdev gets probed
first). I feel removing the MXS_FB is rather harsh, so I *really* would
love to see the MXSFB DRM driver renamed.

--
Stefan

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Stefan Agner]

On 12.07.2018 15:03, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> > > This is one of the situation where states quo is kinda the worst
>> > > situation.
>> > >
>> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>> > > CONFIG_FB_MXS.
>> > >
>> > > I understand that you'd rather prefer to move forward. I suggest we do
>> > > it in steps.
>> > >
>> > > In 4.19:
>> > >
>> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>> >
>> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
>> > binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.

Ok, almost thought so, thanks for the confirmation! So we should be
good.

> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

Yeah I guess that is what Marek don't want because it promotes using
FB_MXS for longer than needed.

I don't care as much since we anyway use the MXSFB DRM driver. However,
what I really dislike is that a kernel compiled with both drivers
currently leads to MXSFB DRM being unusable (because fbdev gets probed
first). I feel removing the MXS_FB is rather harsh, so I *really* would
love to see the MXSFB DRM driver renamed.

--
Stefan

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Thu, Jul 12, 2018 at 03:14:57PM +0200, Marek Vasut wrote:
> On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> > On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> >> On 10.07.2018 11:11, Marek Vasut wrote:
> >>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
> >>>> This is one of the situation where states quo is kinda the worst
> >>>> situation.
> >>>>
> >>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> >>>> CONFIG_FB_MXS.
> >>>>
> >>>> I understand that you'd rather prefer to move forward. I suggest we do
> >>>> it in steps.
> >>>>
> >>>> In 4.19:
> >>>>
> >>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> >>>
> >>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> >>> binding.
> >>
> >> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> >>
> >> There is also .name in struct drm_driver, which is already set to
> >> mxsfb-drm... Is that the one exposed to user space?
> > 
> > Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> > sdb.
> > 
> > Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> > seems to be what matters.
> > 
> >> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> >> only enable CONFIG_DRM_MXSFB=y
> > 
> > If one of the drivers is renamed then they can coexist: since the
> > bindings are distinct one driver will return a probe error and the
> > other will bind successfully. This can even be adjusted so that it
> > doesn't even print ugly scary errors.
> > 
> > This can last until somebody implements support for old bindings in the
> > drm driver and then FB_MXS can just be deleted.
> 
> So why don't we just convert the DT bindings on boards supported
> upstream and zap the old driver ? What is the problem with that?

+1 on zapping drivers :-)

> Realistically, how many MXS boards in the field use old DT and new kernel ?

Yeah I think occasionally that entire "DT is API, can't ever change it"
song is overblown. The rule with regressions isn't that you're never
allowed to break anything, but that you're only allowed to break stuff no
one will notice and report.

If there's realistically no users, go ahead and break (instead of huge and
drawn-out compat plan).

If there's a solid (and automatic enough) fallback like the drm driver,
go ahead and break.

We're doing this all the time in graphics with userspace ABI, I don't
think DT is any different. Every once in a while there's a bit of regrets
and a revert because we missed something, but overal it's much less effort
than always trying to do a perfect job with backwards compat.

Is it really a regression if no one reports it? No.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Thu, Jul 12, 2018 at 03:14:57PM +0200, Marek Vasut wrote:
> On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> > On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> >> On 10.07.2018 11:11, Marek Vasut wrote:
> >>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
> >>>> This is one of the situation where states quo is kinda the worst
> >>>> situation.
> >>>>
> >>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> >>>> CONFIG_FB_MXS.
> >>>>
> >>>> I understand that you'd rather prefer to move forward. I suggest we do
> >>>> it in steps.
> >>>>
> >>>> In 4.19:
> >>>>
> >>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> >>>
> >>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> >>> binding.
> >>
> >> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> >>
> >> There is also .name in struct drm_driver, which is already set to
> >> mxsfb-drm... Is that the one exposed to user space?
> > 
> > Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> > sdb.
> > 
> > Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> > seems to be what matters.
> > 
> >> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> >> only enable CONFIG_DRM_MXSFB=y
> > 
> > If one of the drivers is renamed then they can coexist: since the
> > bindings are distinct one driver will return a probe error and the
> > other will bind successfully. This can even be adjusted so that it
> > doesn't even print ugly scary errors.
> > 
> > This can last until somebody implements support for old bindings in the
> > drm driver and then FB_MXS can just be deleted.
> 
> So why don't we just convert the DT bindings on boards supported
> upstream and zap the old driver ? What is the problem with that?

+1 on zapping drivers :-)

> Realistically, how many MXS boards in the field use old DT and new kernel ?

Yeah I think occasionally that entire "DT is API, can't ever change it"
song is overblown. The rule with regressions isn't that you're never
allowed to break anything, but that you're only allowed to break stuff no
one will notice and report.

If there's realistically no users, go ahead and break (instead of huge and
drawn-out compat plan).

If there's a solid (and automatic enough) fallback like the drm driver,
go ahead and break.

We're doing this all the time in graphics with userspace ABI, I don't
think DT is any different. Every once in a while there's a bit of regrets
and a revert because we missed something, but overal it's much less effort
than always trying to do a perfect job with backwards compat.

Is it really a regression if no one reports it? No.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Thu, Jul 12, 2018 at 03:14:57PM +0200, Marek Vasut wrote:
> On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> > On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> >> On 10.07.2018 11:11, Marek Vasut wrote:
> >>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
> >>>> This is one of the situation where states quo is kinda the worst
> >>>> situation.
> >>>>
> >>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> >>>> CONFIG_FB_MXS.
> >>>>
> >>>> I understand that you'd rather prefer to move forward. I suggest we do
> >>>> it in steps.
> >>>>
> >>>> In 4.19:
> >>>>
> >>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> >>>
> >>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> >>> binding.
> >>
> >> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> >>
> >> There is also .name in struct drm_driver, which is already set to
> >> mxsfb-drm... Is that the one exposed to user space?
> > 
> > Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> > sdb.
> > 
> > Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> > seems to be what matters.
> > 
> >> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> >> only enable CONFIG_DRM_MXSFB=y
> > 
> > If one of the drivers is renamed then they can coexist: since the
> > bindings are distinct one driver will return a probe error and the
> > other will bind successfully. This can even be adjusted so that it
> > doesn't even print ugly scary errors.
> > 
> > This can last until somebody implements support for old bindings in the
> > drm driver and then FB_MXS can just be deleted.
> 
> So why don't we just convert the DT bindings on boards supported
> upstream and zap the old driver ? What is the problem with that?

+1 on zapping drivers :-)

> Realistically, how many MXS boards in the field use old DT and new kernel ?

Yeah I think occasionally that entire "DT is API, can't ever change it"
song is overblown. The rule with regressions isn't that you're never
allowed to break anything, but that you're only allowed to break stuff no
one will notice and report.

If there's realistically no users, go ahead and break (instead of huge and
drawn-out compat plan).

If there's a solid (and automatic enough) fallback like the drm driver,
go ahead and break.

We're doing this all the time in graphics with userspace ABI, I don't
think DT is any different. Every once in a while there's a bit of regrets
and a revert because we missed something, but overal it's much less effort
than always trying to do a perfect job with backwards compat.

Is it really a regression if no one reports it? No.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Thu, Jul 12, 2018 at 03:14:57PM +0200, Marek Vasut wrote:
> On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> > On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> >> On 10.07.2018 11:11, Marek Vasut wrote:
> >>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
> >>>> This is one of the situation where states quo is kinda the worst
> >>>> situation.
> >>>>
> >>>> Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> >>>> CONFIG_FB_MXS.
> >>>>
> >>>> I understand that you'd rather prefer to move forward. I suggest we do
> >>>> it in steps.
> >>>>
> >>>> In 4.19:
> >>>>
> >>>> - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> >>>
> >>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> >>> binding.
> >>
> >> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> >>
> >> There is also .name in struct drm_driver, which is already set to
> >> mxsfb-drm... Is that the one exposed to user space?
> > 
> > Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> > sdb.
> > 
> > Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> > seems to be what matters.
> > 
> >> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> >> only enable CONFIG_DRM_MXSFB=y
> > 
> > If one of the drivers is renamed then they can coexist: since the
> > bindings are distinct one driver will return a probe error and the
> > other will bind successfully. This can even be adjusted so that it
> > doesn't even print ugly scary errors.
> > 
> > This can last until somebody implements support for old bindings in the
> > drm driver and then FB_MXS can just be deleted.
> 
> So why don't we just convert the DT bindings on boards supported
> upstream and zap the old driver ? What is the problem with that?

+1 on zapping drivers :-)

> Realistically, how many MXS boards in the field use old DT and new kernel ?

Yeah I think occasionally that entire "DT is API, can't ever change it"
song is overblown. The rule with regressions isn't that you're never
allowed to break anything, but that you're only allowed to break stuff no
one will notice and report.

If there's realistically no users, go ahead and break (instead of huge and
drawn-out compat plan).

If there's a solid (and automatic enough) fallback like the drm driver,
go ahead and break.

We're doing this all the time in graphics with userspace ABI, I don't
think DT is any different. Every once in a while there's a bit of regrets
and a revert because we missed something, but overal it's much less effort
than always trying to do a perfect job with backwards compat.

Is it really a regression if no one reports it? No.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch