Display is finally working

A project log for DLT one - A Damn Linux Tablet!

Modular Open Source Hardware Tablet that is easy to hack and can run a standard Desktop Linux Distribution (or Android)

Prof. FartsparkleProf. Fartsparkle 07/05/2020 at 15:115 Comments

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 safe 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.
I have not debugged this further 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.


deʃhipu wrote 07/05/2020 at 19:06 point

It's great to see you back working on this!

  Are you sure? yes | no

Prof. Fartsparkle wrote 07/05/2020 at 20:49 point

I never fully stopped except for those 2-3 months, I kinda forgot to update my logs :)

  Are you sure? yes | no

Bharbour wrote 07/05/2020 at 18:31 point

Congratulations on finding that problem. It sounds like a real nightmare issue.

  Are you sure? yes | no

Prof. Fartsparkle wrote 07/05/2020 at 20:48 point


  Are you sure? yes | no

Prof. Fartsparkle wrote 07/05/2020 at 20:50 point

and yea it really sucked, certainly took a lot of motivation out of me. Now the next big hurdle is battery management but I got some cool people to help me with that!

  Are you sure? yes | no