Could you
-
Share the cboot log (full boot log from uart) with us?
-
Try to add those prod_settings in below file and see if it appears.
hardware/nvidia/soc/t210/kernel-dts/tegra210-soc/tegra210-prods.dtsi
Here the boot log so far. I will try and see if anything changes by adding them in that file.
full-bootlog-21-1-2020.txt (67.8 KB)
I tried adding the prod settings in the file you specified and the good news is that they now load!
The bad news is that it still fails at link training, it tries over and over again for a long time but ultimately stops.
I attached the full boot log.
Something I find odd is that it never really tries to adjust much of the settings, it ups the voltage swing by one level but thats it.
boot-failed-lt.log (133 KB)
Hi timonske,
May I know what is your dts now?
panel-a-edp-1080p-14-0 is a internal nvidia panel that has it own driver. I don’t think you should use it now.
Also, your log looks not have this driver enabled either. It means the dts is not correctly loaded again.
Please do share current dts and the result of /proc/device-tree/sor/.
I just refresh my memory of eDP/DP on Nano. Notice that once helped a forum user “Karis” to enable eDP on DP0.
https://devtalk.nvidia.com/default/topic/1065688
I am not sure why this user does not need to add prod settings of hbr. Please help compare both of your device tree here.
I went through that thread but it seems that user had the display working from the beginning without any changes?
It seems only backlight control was an issue but that’s not a topic for me at this point.
My sor looks like this atm:
nano@nano-desktop:/proc/device-tree/sor$ ls
dp-display nvidia,active-panel panel-s-edp-uhdtv-15-6 status
name panel-a-edp-1080p-14-0 prod-settings
I have not removed the panel yet but like you said its not active.
Here also the output of host1x/sor
nano@nano-desktop:/proc/device-tree/host1x/sor$ ls
clock-names nvidia,active-panel phandle
clocks nvidia,dpaux prod-settings
compatible nvidia,sor1-output-type reg
dp-display nvidia,sor-audio-not-supported reg-names
hdmi-display nvidia,sor-ctrlnum reset-names
linux,phandle nvidia,xbar-ctrl resets
name panel-a-edp-1080p-14-0 status
nano@nano-desktop:/proc/device-tree/host1x/sor/prod-settings$ ls
name prod_c_dp '#prod-cells' prod_c_hbr prod_c_hbr2 prod_c_rbr
Hi timonske,
I also need the final dts file that are flashed to your board.
Please convert it back from dtb using dtc tool. Thanks.
Sorry I forgot about that. I attached the decompiled dtb file.
tegra210-p3448-0002-p3449-0000-b00.txt (285 KB)
Hi timonske,
May I know why you have 2 sor in your dts? This may not be related to the issue but still better cleaning up the unused one.
Hi timonske,
After some discussion with our internal team, we have some suggestion for you but it may need you to prepare your own panel driver:
please try to set below one in device tree:
-
nvidia,is_ext_dp_panel = <0x0>;
-
Please check the logic of “tegra_dc_parse_panel_ops” in of_dc.c.
- You will need to write similar drivers as those in “kernel/nvidia/drivers/video/tegra/dc/panel”.
“panel-a-edp-1080p-14-0.c” is our internal eDP panel driver. You could refer to it.
Hi Wayne,
regarding the duplicate entry, I left it there as it did not make any changes, I will remove it.
Regarding the panel driver, I don’t really understand what is panel specific about them? They all seem to do pretty much the same things, enabling a few regulators as far as I can see? I’m not sure what those refer to, but other than maybe backlight control I can’t see anything that is specific to an eDP panel.
It would also surprise me if eDP panels would require this, by specification they behave the same as a DP monitor. An nvidia desktop GPU is f.e. capable of driving an eDP panel with no driver changes or extra circuitry other than backlight control which on most panels is optional if you just need full brightness.
I will try the
nvidia,is_ext_dp_panel = <0x0>;
option and see if that changes anything.
Hi timonske,
The whole story is actually as below
-
From the beginning, the driver flow of DP and eDP are different. In tx1, we modify device tree to enable eDP(ref: tegra210-jetson-cv-p2597-2180-a00-auo-1080p-edp.dts), but we didn’t provide existing device tree for eDP on jetson nano.
-
Somehow, some forum users are able to run eDP on Nano directly by using DP drivers. Unfortunately, this method seems not work on your panel.
-
Different panels have their own timing as power sequence, so need to check the panel spec for each of them. You could refer to function “edp_a_1080p_14_0_enable” or “edp_s_uhdtv_15_6_enable”.
-
I will try the nvidia,is_ext_dp_panel = <0x0>; option and see if that changes anything.
This line is not enough. You could directly check “panel-a-1080p-14-0.dtsi” and also look into the driver as I pointed out in previous comment.
- The parent clock might cause problems too so better checking it.
nvidia,out-parent-clk = "pll_d_out0";
Thanks I will take a look. Do you maybe have the datasheet for either the 14_0 or the 11_6 eDP panel that are in the driver directory? That would make it easier to understand what the drivers are trying to achieve.
After a break on the project I’m back to this issue and looking through the logs again it becomes pretty clear that the driver fails to either recognize that the panel only uses 2 lanes or has a bug to reduce lane count. During link training it tries to adjust the lane count after failing with 4 lanes but fails to reduce the lane count for unknown reasons, claiming it already uses the lowest lane count but has never tried anything lower than 4.
Though the lane fallback table used to get the next lowest lane count is defined as follows: static int lane_fallback_table[] = {1, 2, 4};
From the log:
[ 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
@WayneWWW I was able to verify that assumption now. I made new hardware to attach a 4 lane eDP panel and everything works just fine without any modification to the Device Tree.
Now the question is why the driver never tries to actually reduce the lane count which it should normally do to be DP1.2+ compliant.
Hi,
Actually we don’t have a eDP panel that uses < 4 lanes so I guess it is probably an issue.
I am wondering why the lane count does not decrease to 1 when running the lt. Could you add some debug log to below function in dp_lt.c driver?
static void lt_reduce_lane_count_state(struct tegra_dp_lt_data *lt_data)
static inline int get_next_lower_lane_count