On 18.06.2018 09:43, Daniel Vetter wrote:

On Sat, Jun 16, 2018 at 01:32:44AM +0200, Marek Vasut wrote:

quoted

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.

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