Hi Daniel, Em Wed, 5 Aug 2020 13:04:18 +0200 Daniel Vetter <daniel@xxxxxxxx> escreveu: > > > > I've been working to get upstream support for the DRM driver on HiKey 970. > > > > > > > > While the patches are not ready yet for upstream merge, I'm placing > > > > what I've sone so far on this repository: > > > > > > > > https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1 I already started the process of submitting the pending drivers which are required for the DRM driver to work (regulators and IOMMU). I'm now planning what to do with the DRM KMS driver. This driver is somewhat similar to the Kirin 6220 driver, but the display engine uses a different set of registers which are chipset specific. My port should work with either Kirin 960 or 970, although, so far, I tested only the Kirin 970 part. Besides its size, the driver is pretty much a standard KMS driver that uses emulation framebuffer. Yet, as I said before, it currently has some bugs that are hard to debug and fix, as the downstream version also has them. John has a different port, which works only for Kirin 960, adding some functionality on the existing Kirin 6220 driver. Based on the history on his WIP tree, it sounds to me that the same bugs I'm facing are also present on his port. The known bugs are: - EDID reads via adv7135 don't work properly. Adding a delay on some part of adv7135 code may help, but that sounds to me more like a hack than a final solution; - There are some underflows on a something called LDI. This is the worse bug, as, once it happens, the hardware stops changing the displayed image. At John's tree for Kirin 960, there were several attempts (and several reverts), trying to address it. Based on a comment at the downstream version, at least for Kirin 970 I suspect that this could be due to a too low clock frequency, but increasing it alone breaks the driver. I suspect that other clock frequencies would need to be adjusted, but I don't know how to adjust the other clocks for it to work with a higher frequency; - There's currently a hack at the valid modesetting logic; only modes that are known to work return MODE_OK. I'm planning to test my port on Kirin 960 soon, and ensure that the DRM driver will work for both chipsets. In the future, I'm planning to try merging support for all 3 Kirin variants at the same driver, probably using part of John's approach for Kirin 960. In any case, considering the existing bugs, plus the eventual future work in order to support multiple Kirin variants at the same driver, I would prefer merging this driver first at staging. Would that be acceptable? Thanks, Mauro _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
