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.cres...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
