DP errors writing to i2c address

Hello,

we developed a custom carrier board /w 2 DP-Outs, replacing the HDMI out on the developer board /w DP.

The dts part configuring this modification is here:

/**
 * Switch HDMI with DP display out
 */

&sor1_hdmi_display {
	status = "disabled";
};

&sor1_dp_display {
	status = "okay";
};

&sor1 {
	nvidia,active-panel = <&sor1_dp_display>;
};

This seems to work generally, but there remains an issue which arises at bootup and if hot-plugging monitors to the former HDMI out (SOR1/HEAD0).

    1.525313] tegradc 15200000.nvdisplay: disp0 connected to head0->/host1x/sor1
[    1.525359] tegradc 15200000.nvdisplay: parse_dp_settings: No dp-lt-settings node
[    1.525573] tegradc 15200000.nvdisplay: DT parsed successfully
[    1.525609] tegradc 15200000.nvdisplay: Display dc.ffffff800bd10000 registered with id=0
[    1.531038] tegradc 15200000.nvdisplay: vblank syncpt # 8 for dc 0
[    1.531049] tegradc 15200000.nvdisplay: vpulse3 syncpt # 9 for dc 0
[    1.542211] tegradc 15200000.nvdisplay: probed
[    1.542912] tegradc 15200000.nvdisplay: fb registered
[    1.547150] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 2
[    1.548692] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 1
[    1.550048] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 0
[    1.551460] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[    1.551497] tegradc 15200000.nvdisplay: dp: Failed for I2C write addr:80, size:1, stat:0x10000100
[    1.554619] tegradc 15200000.nvdisplay: dp: couldn't get regulator vdd-dp-pwr
[    1.554636] tegradc 15200000.nvdisplay: dp: couldn't get regulator avdd-dp-pll
[    1.554650] tegradc 15200000.nvdisplay: dp: couldn't get regulator vdd-edp-sec-mode
[    1.554667] tegradc 15200000.nvdisplay: dp: couldn't get regulator vdd-dp-pad
[    1.560420] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 2
[    1.561777] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 1
[    1.563352] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 0
[    1.564906] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[    1.565068] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[    1.565950] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 2
[    1.567434] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 1
[    1.568996] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 0
[    1.570521] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[    1.570689] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[    1.571571] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 2
[    1.573087] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 1
[    1.574631] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 0
[    1.576014] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[    1.576161] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[    1.577040] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 2
[    1.578583] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 1
[    1.579934] tegradc 15200000.nvdisplay: dp: aux write retry (0x10000100) -- 0
[    1.581510] tegradc 15200000.nvdisplay: dp: aux write got error (0x10000100)
[    1.581669] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[    1.581858] tegradc 15200000.nvdisplay: dp: failed to exit panel power save mode (0xfffffff2)

It seems that HPD only works if the monitor is power-cycled after replugging to HEAD0.

After reading through the internet, i got to the point that there must be some other configuration adaption for using DP_AUX like HDMI_DDC.
So, as I2C is not needed for DP_AUX (am i right?), what config modifications should be performed at dts level for getting DP HPD on HEAD0 working?

I am not sure what you are talking about here. DPAUX will handle the hotplug even.

After reading through the internet, i got to the point that there must be some other configuration adaption for using DP_AUX like HDMI_DDC.
So, as I2C is not needed for DP_AUX (am i right?)

Looks like current device tree setting is not sufficient. Most of other properties may still be the HDMI one so it is not able to work with dp by just changing 1~2 lines.

Please share the schematic and current full dts. Full dts means converting the dtb back to dts with dtc too. Which means only one dts file will be attached but not the whole dtsi files.

Also, share the full dmesg instead of something that parsed by you.

Sure, DP_AUX is responsible for the HPD event, but the logs (see attached full dmesg log) mention i2c errors for the modified nvdisplay.
[ 1.473184] tegradc 15200000.nvdisplay: dp: Failed for I2C write addr:80, size:1, stat:0x10000100

That was the cause that brought me into the i2c direction.
Effectively, the problem is a failure to exit panel power save mode due to failed DPCD write:

[    1.501545] tegradc 15200000.nvdisplay: dp: Failed to write DPCD data. CMD 0x600, Status 0x10000100
[    1.501576] tegradc 15200000.nvdisplay: dp: failed to exit panel power save mode (0xfffffff2)

I am not quite sure if this could relate to some regulator settings which seem to be misconfigured for this DP out:

[    1.475974] tegradc 15200000.nvdisplay: dp: couldn't get regulator vdd-dp-pwr
[    1.475997] tegradc 15200000.nvdisplay: dp: couldn't get regulator avdd-dp-pll
[    1.476018] tegradc 15200000.nvdisplay: dp: couldn't get regulator vdd-edp-sec-mode
[    1.476039] tegradc 15200000.nvdisplay: dp: couldn't get regulator vdd-dp-pad

(All lines taken from outputs attached below!)

Also, i am actually a bit confused about the following statements from you:

Most of other properties may still be the HDMI one so it is not able to work with dp by just changing 1~2 lines.

in contrast to:

Basically, the hint in the last citation worked for us, but leads to the mentioned errors above.

We just confirmed the compatibility of our schematics to the reference by A/B comparison and 4-eyes principle.
For completeness, see attached schematics below.

ac10x.dts (246.5 KB)
dmesg.log (108.9 KB)
ac100-r1_scm.pdf (1.2 MB)

That post was just an example and was mostly for usb, so I didn’t reveal everything that is required there.

For example, the nvdisplay@15210000 is another head for the DP and you can see we write vdd-dp-pwr-supply, avdd-dp-pll-supply, vdd-edp-sec-mode and vdd-dp-pad regulator there. That is the default head we used on NV devkit. So it is a validated DTS setting.

However, since you modified nvdisplay@15200000 which was for HDMI on our devkit, there is no corresponding field for those property. You should add them too.

Basically, what you should do is taking our default DP dts as template and see if anything missing in your nvdisplay and SOR node. That is why using the full dts would be easier to compare.

Moreover, check the pinmux setting too. But I think this could be the last one to check.

I adjusted those regulator props on nvdisplay@15200000 to be the same as on nvdisplay@15210000.
I did not found other props which could be copied from one node to the other, because they seem to be specific for the corresponding head and unrelated to the sor config (DP/HDMI connections).
See dts attached below for your convenience.

Now, the errors occur on the other head (head1 instead of head0), except the i2c error message disappeared.
See dmesg output below for further details.

So, what next? Pinmux settings are Xavier NX defaults. Because the settings for DP & HDMI related pins are equal, we assumed that there is no change needed here for switching HDMI->DP output.

ac10x.dts (246.6 KB)
dmesg.log (100.9 KB)

Idea:
There is a note in the Development Guide, noting that DP_AUX channels need to be active high for DP output.
In the nvidia,active-panel subnode of sor1 (connected to head0), there is a node disp-default-out /w prop nvidia,out-flags .
Is this the option which could be set by sw for HDMI as mentioned in the same note?

Accordingly, this option would need to be removed too, am i right?

Does this issue happen on both of your DP ports or only one DP port has this issue?

Same device tree setting can work on devkit but not on your custom board, thus, I can only suggest you to review your hardware side.

If the DP is not correctly powered up when you hotplug the cable, then it will give out i2c error and dpaux error too.

Sorry that I missed one comment, so there is no i2c error now when hotplug case?

As you can see in the attached logs, it only happens on one of the two ports.
Which port it is depends on the configuration i did above (/wo regulators, /w).
The corresponding other port always shows no such errors in both cases!

Because the HW design for both ports is the same, it is unlikely that it should correspond to a HW-issue.

Yes, exactly! (Pls see the logs to be sure if i couldn’t have missed it!)

To be more specific, there was no physical hotplug event occurring at all! The logs mention it, but there was no replugging or something like this!

Can you clarify what is the exact error you have now?

Are you talking about only one port can work now?

What did you configure in your device tree? Could you just tell the lines you changed?

Sorry, there is i2c error too, but now on the other port!

Please make a summary about your issue and summarize your head with nvdispaly id and sor id…

Share full log for each error instead of just telling by yourself.

It is really hard to understand your comment by some terms like “other port”…

Issue:

  • errors in dmesg related to DP Hotplug on non-connected ports (see logs and output mentioned in first post)
  • no boot time info showing up on connected DP
  • output appears only after X is coming up
  • Hotplug not working (means, if the cable was disconnected, reconnecting it to any of the two ports does not lead to an monitor output anymore until hard reset)

Changes in dts (for switching head0 from HDMI to DP):

@@ -4234,9 +4234,11 @@
                        nvidia,fb-win = <0x0>;
                        nvidia,dc-connector = <0x5c>;
                        nvidia,dc-flags = <0x1>;
-                       avdd_hdmi-supply = <0x5d>;
-                       avdd_hdmi_pll-supply = <0x5e>;
-                       vdd_hdmi_5v0-supply = <0x5f>;
+                       vdd_hdmi_5v0-supply = <0x5d>;
+                       vdd-dp-pwr-supply = <0x5e>;
+                       avdd-dp-pll-supply = <0x5f>;
+                       vdd-edp-sec-mode-supply = <0x19>;
+                       vdd-dp-pad-supply = <0x19>;
                        linux,phandle = <0x13a>;
                        phandle = <0x13a>;

See ac10x.dts (246.5 KB) vs. ac10x.dts (246.6 KB)

Note: rest of mods were discussed above (analog to mentioned thread in post #1 above)

Behaviour:

  • head0 (nvdisplay@15200000) connected, head1 (nvdisplay@15210000) not connected
  • head1 (nvdisplay@15210000) connected, head0 (nvdisplay@15200000) not connected

Hi,

Can you just reply below questions first

  1. Is there any DP port that can work or not? It sounds like currently only one of the port can work in the same time.

  2. If only one port can work, how to determine? Both of your logs look more like a non-hotplug case. Did you hotplug the cable right after the board is powering up?

  3. Could you disable each head one by one at a time and see if the other port can pass both the hotplug and non-hotplug case? One case is just boot up with monitor connected. While another one is boot up the device with no monitor, connecting the cable after 30 seconds.

Hi,

sure:


| |

  • | - |
  1. Is there any DP port that can work or not?

Both ports work if plugged in before power up.

  1. 1.: It sounds like currently only one of the port can work in the same time.

This is more a remark than a question but I have to clearify: if plugged in before power up, both ports work at the same time after system and X are fully up.

  1. If only one port can work, how to determine? Both of your logs look more like a non-hotplug case. Did you hotplug the cable right after the board is powering up?

How to determine what? I have mentioned above that I do not need to hotplug a cable from any head to get those errors, so yes: it is not a hotplug case! The errors just come from HPD which seems to be the kernel interface for hotplug events. That’s cause one why I called it „hotplug“ problem.

As you could see in the detailed overview above, the case described there is focused on one (pre-Boot-up) connected port, leaving the other disconnected. The dpaux error happens always on the disconnected one.
Nevertheless, if trying to plug the cable from one port to another after system came up (hotplugging), and even back to origin, the display never comes up again.
That’s cause two why I called it „hotplug“ problem.

To question 3: I will check and give feedback with the results.

How to determine what?

My 3rd question was based on your reply to the 2nd question, so please ignore this what to determine question. Not matter now.

As you could see in the detailed overview above, the case described there is focused on one (pre-Boot-up) connected port, leaving the other disconnected. The dpaux error happens always on the disconnected one.

Sorry that I have to say your previous comment is hard to understand. I finally got what your situation is until now.
I think the “hotplug” term here is confusing. Maybe just say there is “error” should be more clear.

Please confirm the situation is correct or not.

  1. Both ports can work if you connect it before power up.

  2. One port connected and another port with nothing, there would always be error log coming out on the empty port

  3. Boot up with nothing connected. Inserting the cable after boot up will not bring any monitor back.

Please also share dmesg for these 3 cases as 3 different files.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.