Display Port/Expansion on Jetson TK1

Autonomous Machines Jetson & Embedded Systems Jetson TK1
21

I’ve got one of those active DisplayPort → HDMI adapters now. It uses the ANX9830 chip, which might be possible to integrate on an adapter board without much of an issue.

22

I tried to connect iPad LCD(LP097QX1) to Embedded DisplayPort of my Jetson, but it displays nothing.
The screen is always black and only backlight is working.

This is a picture of my iPad LCD adapter.
This board is just for a test. I used two solderless breadboards so that I can change circuit.

1286×931 429 KB

I’m using L4T R19.3 and The Grinch 19.3.7.
I did “sudo get-edid” via ssh, but there is no EDID from any I2C bus.
When I connect a LCD to HDMI, get-edid print only EDID from bus 3.
get-edid scan 6 I2C busses.
And Jetson has 5 i2c busses.
http://elinux.org/Jetson/I2C
So, get-edid cannot get EDID from eDP?
Is I2C bus(AUX) of eDP disabled?

I connected +3.3V RUN (pin22 in J3A1) in Jetson to Vin of the LCD. There is 0.33A current when Jetson is running.
Voltage of Hot Plug detect(pin2) of LCD is 2.49V.
How can I check hot plug detection in Jetson?

It seems /sys/devices/platform/host1x/tegradc.1 and /sys/class/graphics/fb1 are correspondings to HDMI output.
Values of files in these directory was changed when I connect HDMI display.
So I thought /sys/devices/platform/host1x/tegradc.0 and /sys/class/graphics/fb0 are correspondings to eDP output.
I tried following commands, but nothing changed.

sudo echo 1 >  /sys/devices/platform/host1x/tegradc.0/enable
sudo echo 0 > /sys/class/graphics/fb0/blank

I think a driver for internel panel is not installed, or it is installed but disabled.

23

Your SI on those signals isn’t good enough to get display port sync.
If you can’t make a custom circuit board with properly spaced signals you shouldn’t bother with that kind of setup.

However the auxiliary channel is slower so you can get by running it at a lower rate. It comes up first so if you get can that channel pair running then you should be able to tell if the display port is turned on or not. (you can see the panel EDID and name reported in the OS with only auxiliary sync)

24

Bill, thank you for your advice.
I’m studying how to make a circuit board for eDP.

I read a L4T kernel source and it seems CONFIG_TEGRA_DP is a option to enable embedded Display port.
And it seems dp.c and dp.h in kernel/drivers/video/tegra/dc are source codes for eDP driver.
I checked /proc/config.gz and CONFIG_TEGRA_DP is enabled.
So, I think the driver for eDP is installed in my Jetson TK1.
But when I connect my LCD to Jetson TK1 using my board, I don’t see any new messages in dmesg.
Auxiliary channel in my custom circuit board might not working well, but I think hot plug detect is working.

25

Waiting for an update on this subject.

26

OK, since I never got any reply on my old thread, I’ll first make a breakout that provides displayport source plug connected to the 2x25 connector. If displayport output works, then I can look into trying to use the backlight GPIO/PWM/etc related stuff.

2060×595 86.7 KB

If it doesn’t work then its a waste of time trying to make a converter for some other LCD.

BTW - 3D step model for the Jetson board has 4 rows for extension connector, not 2x25 + 3x25 (5 rows total).

27

@dongie, that would be great!

@nvidia, if a DK1 64-bit board is in the works then please ship it with both HDMI and DP connectors.

28

Well, I made the adapter and I’m seeing same thing as the other guy, as in, nothing is working.
On boot the DP output doesn’t do anything, after boot with HDMI there’s no indication that DP output is doing anything. Looking at /sys/whatever/tegradc stuff, the .0 is for DSI output (probably not even connected anywhere).

Can one of the nvidia people start paying attention to this thread or I’m tossing this board into the garbage.

2688×1520 1.34 MB

EDIT: after some poking around L4T 19.whatever sources, I don’t think DP stuff works, code inside tegra/dc.c kinda makes use of it in some cases but not in others, so its probably limited functionality. There’s also a reference to some BUG in internal nvidia bug database about “hardware support for panel power” or something like that.

I’m downloading L4T 21 but I’m not holding my breath.

EDIT2: apparently flashing new L4T requires another lunix system, I don’t think I’m going to handle having TWO things failing on the same desk, so shelving this for now until someone from NV speaks up.

29

I’m really hoping that somebody solves this issue, my hdmi isn’t working anymore and this would be a lifesaver if worked.

30

Hi Dongie, I admire your adapter. (If you throw your TK1 out, please send it to me ;-) )
I’m currently making a much more basic adapter myself, with a multi-pin connector and a lot of soldering. I’ll let you know how it goes.
The only things I can think of at the moment are:

  • Which lanes did you use 0-3 or 1-4 ?
  • Did you remember to sort the lanes (including polarity) the correct way for DP-source ?
  • Older Tegra Dev-Boards required to add an option to nvflash to choose video-output config:
    –odmdata 0x3c200011 for hdmi
    –odmdata 0x3c300011 for crt
    –odmdata 0x3c000011 for hdmi
    I did not find any information about this for the JetsonTK1.
31

Sorry, got the lanes mixed up, LVDS->eDP on Jetson is: 0->2, 1->1, 2->0, 3->x, 4->3

32

Which lanes did you use 0-3 or 1-4 ?
The ones mentioned in schematic for lvds>dp mapping, under “LVDS to EDP mux”

Did you remember to sort the lanes (including polarity) the correct way for DP-source ?
yep, not my first displayport board.

like i said, from looking at dc.c and couple related files under tegradc, it isn’t going to work out of the box.

33

From a user land program, I’m attempting to access the Pinmux registers for
PU3 and PU4. The addresses I’m using are 0x70003190 & 0x70003194, respectively
(writing a 0x20 in order to hook these up to the outputs of PWM0 and PWM1, respectively).
However, when I attempt to write to that address, the user land program terminates.

Is that the right address? The TRM indicates this address, but I’m wondering if there is some
virtual/physical mapping going on? or anything else that needs to happen in order to write
to these regs from user space?

Similar question for the PWM[01] controls: 0x7000A000 & 0x7000A004

(painfully aware that no one else seems to be having any such problem)

34

While in u-boot loader you have physical addresses. After this it is remapped.

35

Any cool news on this other than some totally unrelated GPIO junk

36

The following should be considered when making the adapter board to avoid eDP signal integrity issue.

1329×649 109 KB

from https://developer.nvidia.com/rdp/assets/jetsontk1modulespecpdf

  1. 0.01uF (AC coupling) cap is required on each eDP lanes & AUX lane.
  2. 100Kohm pull up to +3.3V_LP0 is required on AUX_N
  3. 100Kohm pull down to GND is required on AUX_P
    Update : 1~3 are Not required if already exist on eDP panel side.

977×1152 373 KB

from https://developer.nvidia.com/rdp/assets/jetsontk1modulespecpdf
4. The Available Max Trace Delay for Module (ps) from Table 7 show that
ex) LVDS0_TXD2_N 1012 ps ~= 147.8mm
LVDS0_TXD2_P 1013 ps ~= 147.9mm
(1 ps delay is around 0.146mm distance in case of Jetson PCB)

a. The max length allowed all the way from Jetson's expansion header -> the adapter board ->  eDP panel's driver IC in total is only 147.8mm for LVDS0_TXD2 signals.
   i.e. If eDP panel's cable is already close to 147mm long, you're out of luck.

b. Jetson PCB already has max 1 ps difference allowed for "Max intra-pair (within pair) Skew 1ps" that the adapter board should have the exact same length for LVDS0_TXD2_N & LVDS0_TXD2_P traces.

  1. Max Inter-pair (pair-pair) Skew allowed is 150ps
    ex) LVDS0_TXD0 pair 970ps ~= 141.6mm
    LVDS0_TXD2 pair 1012ps ~=147.7mm
    The difference is 42ps ~= 6.1mm
    The LVDS0_TXD0 pair & LVDS0_TXD2 pair length difference allowed in the adapter board is 108ps ~= 15.7mm.

  2. The trace impedance & spacing requirement should be met.

37

All? Most? DisplayPort sinks will have AC coupling caps already, so I don’t think this is the biggest issue. Also from seeing other DisplayPort implementations, I don’t think a 1ps delay is going to make it not work either, especially for 1mbps low-speed AUX channel. The issue here is that the driver isn’t even turning the hardware on, never mind doing anything else with it. But thanks for the notes, if kernel ever starts supporting DP output properly, I’ll have to use this info if I need to redo the adapter board.

from DisplayPort 1.1a spec:

Why are both pulled down in TK1?

This is generally done on the sink PCB at the eDP connector, and I wouldn’t need to do this at the breakout board.

38

From watching the kernel mailing lists looks like some work has been done on enabling eDP for tegra124 in the 3.17 and 3.18 kernels.

Should be able to compile a new kernel on the board without having to reflash it from a remote source: Tegra/Mainline SW/Gentoo From SD Card - eLinux.org specifically the “Kernel” section of the guide (just remove the CROSS_COMPILE flags since the make is being run native). I tried it, and see more references to displayport funtionality than R19 or R21, though my adapter board is wanting so I haven’t been able to get anything to display yet either.

39

Hi All,
Support for eDP on dc.0 is already existing in l4t kernel. Its just that, you need to add code to select the right panel in SW.
This has been tested with AUO eDP panel ( AUO B140HAN01.1). SW just needs code to select the right panel.
If you want to use another panel initialization , then they have to add panel specific code.
Below are the steps in SW to select a panel ( AUO for example):

  1. Panel selection code is here arch/arm/mach-tegra/board-ardbeg-panel.c

                   panel = &edp_i_1080p_11_6;

  2. Remove “fb=map:1” from kernel command line to get console over display_controller.0. Instead add display board number in command line, “displayboard=0x0720”. You can do this in jetson-tk1.conf file

  3. Remove the below code from target which disable dc.0, file : /etc/init/nv.conf

remove power to dc.0 for jetson-tk1

  machine=`cat /sys/devices/soc0/machine`
  if [ "${machine}" = "jetson-tk1" ] ; then
          echo 4 > /sys/class/graphics/fb0/blank
          BoardRevision=`cat /proc/device-tree/chosen/board_info/major_revision`
          if [ "${BoardRevision}" = "A" ] ||
                  [ "${BoardRevision}" = "B" ] ||
                  [ "${BoardRevision}" = "C" ] ||
                  [ "${BoardRevision}" = "D" ]; then
                  echo 0 > /sys/devices/platform/tegra-otg/enable_device
                  echo 1 > /sys/devices/platform/tegra-otg/enable_host
          fi
  fi
  1. Flash as usual. Make sure that you have the display board id in your kernel command line

This is pretty much what you need to do to get eDP panel UP and running.

regards
Bibek

40

What if I want primary monitor on HDMI and secondary on DP?
Or at least some non-insane (I mean, that doesn’t involve editing kernel sores) method of switching?