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 Cercueil]

Le sam. 22 août 2020 à 0:11, Paul Boddie <paul at 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 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.

If you send clean patches, there's no reason for me not to merge them.

>>  > 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 :-)

That's pretty much expected for a -rc1 release. Wait until -rc3 or -rc4 
to have something more or less stable.

Cheers,
-Paul

> 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
> 
>