First of all sorry for the huge absence of updates. I've been updating my small steps mostly via twitter, then took a longer break from the project from Feb to May as I've been a bit burned out.

So what happened since the last update? I tested the new revision, unfortunately no change, the issues still persisted. While the pinout was corrected the Display was still staying black, I was successfully communicating over the AUX channel again but it was failing at the link training stage.

Then followed a long stage of debugging, diving deep into the Linux Device Tree setup of the Jetson Nano. Which was very educational for me but unfortunately did not bring me closer to get the Display working. I was suspecting that the default device tree was assuming some bit rate settings that are suitable for desktop monitors but not actually accepting the request from the display for a lower bitrate mode. Eventually I got it to advertise the lower bitrate but this did not change anything.

After that I was a bit burned out and had really no good idea why it wasn't working so I took a bit of a break, then COVID happened and my general motivation to do electronics plummeted.

I got back to it a few weeks ago and did another sprint to get it working.

The first thing I wanted to try was to make an adapter that would allow me to connect my desktop GPU to one of the panels to see if I experience the same issue there.
I milled this on my Bantam Mill. Turns out standard DisplayPort cables don't carry the 3.3v line so I had to bodge an LDO on there.

With this setup I had the same issue with my desktop GPU.
One hunch that remained was that it might have to do with the fact that the displays I was trying to get working were all 2 lane displays. DisplayPort defines that for embedded devices it is ok to use only 1 or 2 lanes instead of the full 4 data lanes to save cost and complexity for less high resolution displays.

This turned out to be indeed the culprit. I found that one display sample that I hadn't really touched before because I assumed I accidentally ordered an LVDS panel turned out to be 4 lane eDP panel. So I milled an adapter for that going from my pinout to the displays 40 pin pinout to test my theory that the Jetson is not able to adapt to displays with less than 4 data lanes.

And guess what. It worked! FFS.
I also quickly found a hint for the culprit in the driver, while display is requesting that the amount of lanes be lowered, the driver never actually does. This happens a few times until the driver determines there are no more lower lane counts to check albeit it never actually doing that. The driver defines a struct with the the three different lane counts to check but it seems it never actually uses it other than to check for how many times it has to lower the lane count.
static int lane_fallback_table[] = {1, 2, 4};
So it keeps on iterating over this struct but because it never actually does anything to satisfy the displays request, it eventually gives up after spamming the kernel log with vague and unrelated error messages that had sent me down the wrong rabbit hole. Until quitting with saying that it tried all lane count options (which is a lie as we now know).

[    6.272838] dp lt: new config: lane 0: vs level: 2, pe level: 1, pc2 level: 0
[    6.279969] dp lt: new config: lane 1: vs level: 1, pe level: 0, pc2 level: 0
[    6.287099] dp lt: new config: lane 2: vs level: 0, pe level: 0, pc2 level: 0
[    6.294227] dp lt: new config: lane 3: vs level: 0, pe level: 0, pc2 level: 0
[    6.301362] dp lt: config: lane 0: vs level: 2, pe level: 1, pc2 level: 0
[    6.308150] dp lt: config: lane 1: vs level: 1, pe level: 0, pc2 level: 0
[    6.314936] dp lt: config: lane 2: vs level: 0, pe level: 0, pc2 level: 0
[    6.321724] dp lt: config: lane 3: vs level: 0, pe level: 0, pc2 level: 0
[    6.328508] dp lt: tx_pu: 0x60
[    6.332014] dp lt: CE retry
[    6.334810] dp lt: switching from state 3 (channel equalization) to state 3 (channel equalization)
[    6.343761] dp lt: state 3 (channel equalization), pending_lt_evt 0
[    6.350965] get_clock_recovery_status: cnt=0, data_ptr=0x71
[    6.356964] get_clock_recovery_status: cnt=1, data_ptr=0x77
[    6.362962] dp lt: CE not done
[    6.366009] dp lt: CE retry limit 5 reached
[    6.370192] dp lt: switching from state 3 (channel equalization) to state 7 (reduce lane count)
[    6.378883] dp lt: state 7 (reduce lane count), pending_lt_evt 0
[    6.384887] dp lt: lane count already lowest

I have not debugged this further to fix the issue as I like the 4 lane display that I now tested and it has better availability even than my other 2 lane displays so I will continue working with this panel for now. Its a 10.1" panel with 2560x1440 resolution.
Nvidia has acknowledged the bug though and hopefully fixes it in an upcoming release.