drm/bridge: Synopsys DW-HDMI bridge driver for the Ingenic JZ4780 (was Re: Specialising the Synopsys DW-HDMI bridge driver for the Ingenic JZ4780)

[Paul Boddie]

On Friday, 21 August 2020 15:32:46 CEST Ezequiel Garcia wrote:
> On Thu, 20 Aug 2020 at 19:49, Paul Boddie <paul at 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