On Fri, 21 Aug 2020 at 19:24, Paul Cercueil <paul@xxxxxxxxxxxxxxx> wrote: > > > > Le sam. 22 août 2020 à 0:11, Paul Boddie <paul@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
