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
Can you fix the DTs for 4.19 too ?
Getting tight, but will try.
-- Stefan