On Fri, 21 Aug 2020 at 19:24, Paul Cercueil paul@crapouillou.net wrote:
Le sam. 22 août 2020 à 0:11, Paul Boddie paul@boddie.org.uk a écrit :
On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
On Thu, 20 Aug 2020 at 19:49, Paul Boddie paul@boddie.org.uk wrote:
It still doesn't work for me. I still get "Input not supported"
from my
monitor. It is a DVI monitor connected via a HDMI adapter, but
EDID
probing works and, as I noted previously, the HDMI/LCDC can be made to
work (and
obviously did work in the 3.18 kernel).
This means the dw_hdmi encoder driver is still not good enough to support your adapter. I haven't yet compared v3.18 vendor with our version, but I'm afraid that the dw_hdmi stack has probably changed quite a bit, so a comparison will be difficult.
I would have to look at this again to check, but although I may have referred to the 3.18 HDMI driver (drivers/gpu/drm/jz4780/dwc_hdmi.c), I'm fairly sure I used the more recent driver (drivers/gpu/drm/bridge/synopsys/dw_hdmi.c) as my primary reference when making the hardware work with the L4 Runtime Environment. But the actual functionality with regard to setting registers in the HDMI peripheral is mostly identical between both forms of the driver.
(This makes sense because few people are likely to have access to the proprietary documentation. In fact, few people are likely to have even tried to deduce what is doing on. One of the register value tables suggests that one of the values would really need to be different, if you consider the patterns involved, which means that either the documentation mentions this special case or that a mistake has been made that has not yet been exposed through real world use.)
The natural debug path for me would be to checkout v3.18, connect your DVI monitor and make a dump of all the dw_hdmi registers, then make the same dump for our mainline kernel -- making sure we are comparing the same mode.
It is possible that something does not get initialised in the same way, and Nikolaus and I have been working with register dumps, although I haven't been generating them myself within Linux. So it is possible that I am missing some misconfiguration in the driver that causes an incompatibility with my monitor.
It should be noted that the initialisation is simpler with the DVI mode, thankfully. The "AVI infoframe" stuff (going from memory) is completely skipped, as are a range of other things, which made my reimplementation effort somewhat quicker. I also didn't bother with the audio functionality, but then I don't think DVI has any audio channels, either.
One reason for implementing drivers for L4Re was to determine what is actually needed to initialise the hardware correctly, doing so in an environment that has been quicker to test than Linux has been (given some very old development hardware I have been using until recently). Another reason is that I actually want to get the CI20 hardware working with L4Re, which it was originally supposed to do, but in fact that effort was never actually finished.
I downloaded it from here:
https://gitlab.collabora.com/linux/0day/-/tree/jz4780-drm-hdmi-v5.9-rc1
(I was going to clone the repository late last night, but it was
taking a
long time and I also didn't want to clone everything yet again.)
If you want to avoid cloning the same things over and over you can use git-clone --reference. And if you want to checkout just a single branch, git now has --single-branch.
For instance, (assuming a torvalds/ local repo):
git clone -b letux/jz4780-hdmi-v4 --single-branch git://git.goldelico.com/letux-kernel.git --reference torvalds/ letux
Thanks for the tip! I guess I will spare everyone my thoughts about git's never-ending usability deficit.
[...]
It would be nice to reconcile the JZ4780 support with the evolving upstream support, accommodating the extended descriptors and the
extra
register usage.
I think that's already done in the patches I've cleaned up. The only thing left to check is plane offset and overlay enablement.
There are some things that are done in different places, like various registers being set in particular "atomic" methods and not during probing. Also, the upstream driver has specific plane descriptors whereas my own modifications introduced dual descriptors in a slightly different way. Plus, the upstream driver doesn't support extended descriptors, as far as I am aware.
So, unless Paul Cercueil is fine with what you have done, I don't think we are close to integrating anything. Then again, I am not really a Linux kernel developer, so perhaps I won't comment in depth about what the requirements might be.
If you send clean patches, there's no reason for me not to merge them.
I'd really like to see HDMI support on my CI20 being merged. Thank to recent ingenic-drm work and thanks for Paul Boddie and Nikolaus work, the patches are IMO quite clean.
Nikolaus, Paul: Do you have plans to submit these? If not, I'll be happy to get them out the door for review.
Cheers, Ezequiel