DRM/KMS experimental drivers for HiKey 970

[Mauro Carvalho Chehab]

Hi Daniel,

Em Wed, 5 Aug 2020 13:04:18 +0200
Daniel Vetter <daniel at ffwll.ch> 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