On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote: > On Thu, 20 Aug 2020 at 19:49, Paul Boddie <p...@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. > > P.S. I noticed a few problems with the 5.9-rc1 branches such as powering > > down not actually removing the power and, in my own branch, networking > > not working reliably (or maybe even at all), with the tedious progress > > indicator never terminating in the boot sequence. So, once again, it is > > another case of half a step forwards and about three steps back. > > Life (and kernel) is like this: sometimes you need to take three steps > back to make a jump forward :-) Well, I wish I could be so optimistic. Objectively, the whole Linux kernel development process is just so poor when we consider that we started out in 2014 or earlier with software that actually worked with the hardware, but since it wasn't written quite to everybody's tastes and in line with the fashions of the day, the whole exercise of reworking it was thrown straight back at the developers. And since the developers were only being paid for as long as their employers were interested, which turned out not to last particularly long, we all ended up with yet another piece of equipment which risks becoming obsolete unnecessarily. Of course I would probably benefit from upstreamed support for the CI20, although I was actually fairly happy using the 3.18 kernel with a relatively recent Debian version, and we might not yet be at the point where new Debian releases don't work with such an old kernel. But for the most part I don't really care personally about fixing up Linux support for such hardware because my own interests lie elsewhere. I suppose the most I get out of it is looking at how the hardware works and being in a stronger position to reimplement the driver support for L4Re. Indeed, I got the RTC support working in L4Re in order to troubleshoot the Linux drivers, although they still seem to be pathologically unable to handle the "lost clock" condition that is hardly unlikely on the CI20. Yet at the same time, I always manage to feel guilty asking for cooperation to get improvements made to Linux, spending quite a bit of my own personal time working with the underdocumented frameworks involved, building, deploying, testing, and so on. And this is just my own way of offering help to others who might not be in quite the same position, technically, to improve a situation that might be far more important to them. Whatever little satisfaction I might get from helping out tends to get completely overwhelmed by the amount of effort, frustration and time involved. Anyway, sorry for the rant. I'm sure other people find their own activities of this nature to be sufficiently fulfilling and enjoyable. Life does present us all with setbacks, but I generally don't appreciate getting served up with more of them just so that some people in the Valley or wherever can "have fun" or whatever the mantra is these days. Paul _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
