I am trying to connect a Display via Display Port with the help of an PTN3460 eDP-LVDS Brigde. This setup worked fine with an 1280x800 px Display, but now I am trying to connect a 480x320 px Display.
When creating the EDID I set the pixel frequency to 11MHz but when meassuring the frequency I get 25MHz. Which frequencys does the Xavier NX support?
When using xrandr no display shows up. I noticed that there is no predefined mode for a 480x320 px Display. Is there a way to add this mode?
Does jetson correctly read the edid as your expectations?
Where can I look this up?
I checked the EDID and it is read correctly by Xavier NX. But while writing the edid I noticed following ERROR Massage:
[ 1181.763489] tegradc 15210000.nvdisplay: can't configure dc with mode 320x480
[ 1181.763491] detected fb_set_par error, error code: -22
[ 1181.807550] H_BLANK >= 25
My Display got the resolution 320x480. Is there a way to configure the dc in this mode?
How did you “write the edid”?
Also, is this issue on NX or on Xavier AGX? You filed this topic in AGX forum.
This Issue is regarding Xavier NX.
I wrote the edid to the PTN3460 eDP to LVDS converter where it is then read by the Xavier NX. Then this ERROR occurs.
The stored EDID in
sudo cat /sys/kernel/debug/tegradc.X/edid #X=0,1,2.is correct but when I print the used mode with
sudo cat /sys/kernel/debug/tegradc.0/mode I get the wrong mode. I think the nx can currently not apply the used resulution.
Please share full dmesg. Your partial log looks like our driver just not support this mode.
Here is the full dmesg.
Is there a way to make the xavier NX support this mode?
There are actually two issues here
The mode your edid tells the driver to run does not meet the criteria that our driver can support.
As the log says, H_BLANK >= 25 so some conditions are invalid. You need to directly check our kernel driver to see what criteria needs to be met.
320x480 is actually a very low pixel clock. There is a known issue on jetson NX pll_d parent clock has a lower bound 40Mhz. If this head is using pll_d as parent clock, then it is very likely you would hit this issue.
A workaround is change the parent clock from pll_d to another parent clock.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.