On 16.06.2018 01:32, Marek Vasut wrote:

On 06/16/2018 12:42 AM, Leonard Crestez wrote:

quoted

On Fri, 2018-06-15 at 23:36 +0200, Marek Vasut wrote:

quoted

On 06/15/2018 10:58 PM, Leonard Crestez wrote:

quoted

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

quoted

On Fri, Jun 15, 2018 at 4:43 PM, Leonard Crestez
[off-list ref] wrote:

quoted

quoted

quoted

quoted

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.

quoted

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

quoted

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.

quoted

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