On Wed, Aug 19, 2020 at 4:46 AM Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote: > Yet, I'm submitting it via staging due to the following reasons: > > - It depends on the LDO3 power supply, which is provided by > a regulator driver that it is currently on staging; > - Due to legal reasons, I need to preserve the authorship of > each one responsbile for each patch. So, I need to start from > the original patch from Kernel 4.4; > - There are still some problems I need to figure out how to solve: > - The adv7535 can't get EDID data. Maybe it is a timing issue, > but it requires more research to be sure about how to solve it; I've seen this on the HiKey960 as well. There is a patch to the adv7533 driver I have to add a mdelay that seems to consistently resolve the timing problem. At some point I mentioned it to one of the maintainers who seems open to having it added, but it seemed silly to submit it until there was a upstream driver that needed such a change. So I think that patch can be submitted as a follow on to this (hopefully cleaned up) series. > - The driver only accept resolutions on a defined list, as there's > a known bug that this driver may have troubles with random > resolutions. Probably due to a bug at the pixel clock settings; So, yes, the SoC clks can't generate proper signals for HDMI frequencies (apparently it's not an issue for panels). There is a fixed set that we can get "close enough" that most monitors will work, but its always a bit iffy (some monitors are strict in what they take). On the kirin driver, we were able to do a calculation to figure out if the generated frequency would be close enough: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c#n615 I suspect we could do something similar for the hikey960/70, but I've not really had time to dig in deeply there. Personally, I don't see the allow-list as a problematic short term solution, and again, not sure its worth pushing to staging for. > - Sometimes (at least with 1080p), it generates LDI underflow > errors, which in turn causes the DRM to stop working. That > happens for example when using gdm on Wayland and > gnome on X11; Interestingly, I've not seen this on HiKey960 (at least with Android/Surfaceflinger). The original HiKey board does have the trouble where at 1080p the screen sometimes comes up horizontally offset due to the LDI underflow, but the patches to address it have been worse then the problem, so we reverted those. > - Probably related to the previous issue, when the monitor > suspends due to DPMS, it doesn't return back to life. > I don't believe I see this on HiKey960. But if it's the LDI issue on the 970 that may explain it. > So, IMO, the best is to keep it on staging for a while, until those > remaining bugs gets solved. I'm not sure I see all of these as compelling for pushing it in via staging. And I suspect in the process of submitting the patches for review folks may find the cause of some of the problems you list here. > I added this series, together with the regulator driver and > a few other patches (including a hack to fix a Kernel 5.8 > regression at WiFi ) at: > > https://gitlab.freedesktop.org/mchehab_kernel/hikey-970/-/commits/master > > > Chen Feng (1): > staging: hikey9xx: Add hisilicon DRM driver for hikey960/970 > > John Stultz (1): > staging: hikey9xx/gpu: port it to work with Kernel v4.9 Nit: This is a display driver and has little to do with the GPU (other then it will eventually live in drivers/gpu/drm/...), so I might suggest using more conventional subject prefix, "drm: hisilicon:" thanks -john
