ryu: USBC->HDMI adapter flakey |
|||||||||||||||||||||||||||||||
Issue descriptionJust tried out the USBC->HDMI adapter on ryu, it's pretty broken. Here are a couple of observations: - hotplugging the adapter plus HDMI cable doesn't result in dpaux hotplug - plugging in the adapter and then plugging/unplugging just the HDMI cable sometimes results in a hotplug interrupt - when a hotplug is detected, dpaux often detects the incorrect state (ie: polarity flipped) - when i can manage to get the connection state correct, link training fails with the following: [ 257.366001] [drm:tegra_dpaux_irq] *ERROR* spdrm: interrupt 1 [ 257.371700] [drm:tegra_dpaux_irq] *ERROR* spdrm: dpaux hotplug PLUG [ 257.378167] [drm:drm_dp_aux_detect] *ERROR* spdrm: detect PLUGGED [ 257.384690] [drm:drm_dp_aux_detect] *ERROR* spdrm: detect PLUGGED [ 257.720041] [drm:drm_dp_aux_detect] *ERROR* spdrm: detect PLUGGED [ 258.123463] [drm:drm_dp_link_equalize_channel] *ERROR* clock recovery lost while equalizing channel [ 258.151877] [drm:drm_dp_link_train_full] *ERROR* channel equalization failed, downgrading link [ 258.171774] [drm:drm_dp_link_equalize_channel] *ERROR* clock recovery lost while equalizing channel [ 258.199586] [drm:drm_dp_link_train_full] *ERROR* channel equalization failed, downgrading link [ 258.213568] [drm:drm_dp_link_train] *ERROR* full link training failed: -22 [ 258.220443] tegra-sor 54580000.sor: link training failed: -22 [ 258.254228] [drm:drm_dp_link_equalize_channel] *ERROR* clock recovery lost while equalizing channel [ 258.282574] [drm:drm_dp_link_train_full] *ERROR* channel equalization failed, downgrading link [ 258.301615] [drm:drm_dp_link_equalize_channel] *ERROR* clock recovery lost while equalizing channel [ 258.328876] [drm:drm_dp_link_train_full] *ERROR* channel equalization failed, downgrading link [ 258.347724] [drm:drm_dp_link_equalize_channel] *ERROR* clock recovery lost while equalizing channel [ 258.375461] [drm:drm_dp_link_train_full] *ERROR* channel equalization failed, downgrading link [ 258.389321] [drm:drm_dp_link_train] *ERROR* full link training failed: -22 [ 258.396197] tegra-sor 54580000.sor: link training failed: -22
,
Mar 24 2016
Ok, so I can get reasonable IRQ/hotplug behavior from the device by adjusting the HPD times in DPAUX_HPD_CONFIG_0 and DPAUX_HPD_IRQ_CONFIG_0. I have them set to 1 right now, which is admittedly insane and does cause false positives when the line jumps. These values will need tuning, I can generate them via trial & error unless Nvidia can provide guidance. It seems I can read the EDID reliably now as well. I'm still getting the link training issues, I'll look into that now.
,
Mar 24 2016
,
Mar 24 2016
,
Mar 25 2016
Sorry, I somehow removed Kary from the CC list when I added Todd.
,
Mar 28 2016
Hi, Sean Please let me know if you want me to do something. Also, could you please cc to treding@nvidia.com? I think he may be working on it. Thanks
,
Mar 28 2016
,
Mar 28 2016
Small update for the Google USBC->HDMI adapter: The clock recovery phase succeeds when training with pattern 1. When it tries to do channel equalization, it fails with all link rates (1 lane). The channel eq phase attempts to use training pattern 3 because the adapter advertises TPS3 support. I don't see anything in the TRM outlining how the training sequence is supposed to be completed, so I'm flying in the dark here. Can someone from Nvidia (kary?) help look into this? Are there any additional documents/scripts from Nvidia on how the DP training is supposed to work? I also tried the Apple Multiport adapter [1] and the Dell adapter [2]. In both of these cases, the USB hub is registered, but there is no hotplug on either. We'll need to investigate why that is, but I'm going to focus on the Google adapter for now. [1] http://www.apple.com/shop/product/MJ1K2AM/A/usb-c-digital-av-multiport-adapter [2] http://www.amazon.com/Dell-Adapter-Type-Ethernet-470-ABQN/dp/B012DT6KW2
,
Mar 28 2016
The hotplug story with DP is complicated, but basically it sounds like you're not catching short pulses somehow? A short pulse + a change in DPCD sink count should be handled pretty much like a normal hpd.
,
Mar 28 2016
@c9: That sounds likely. I haven't tried to poll the sink count on the Apple or Dell adapter, so that would be an interesting test. ATM, I'll see if i can get the Google adapter working. Hopefully once the Google adapter is working, I can sort out the HPD story on the other two, they'll Just Work.
,
Mar 29 2016
@c8: Hi, Sean I can not even read the EDID with the USBC->HDMI adpater at my side. So could you please provide the current patches that can reproduce the training error if you want us(Nvidia) to look into this? Thanks
,
Mar 29 2016
@c11:
Did you lower the HPD times like I described in c2? If you don't do that, the cable will not be detected.
Did you also look into whether there are any additional documentation on link training?
Here's how I'm lowering the HPD times:
diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c
--- a/drivers/gpu/drm/tegra/dpaux.c
+++ b/drivers/gpu/drm/tegra/dpaux.c
@@ -366,6 +372,8 @@ static int tegra_dpaux_probe(struct platform_device *pdev)
DPAUX_INTR_UNPLUG_EVENT | DPAUX_INTR_PLUG_EVENT;
tegra_dpaux_writel(dpaux, value, DPAUX_INTR_EN_AUX);
tegra_dpaux_writel(dpaux, value, DPAUX_INTR_AUX);
+ tegra_dpaux_writel(dpaux, 0x1, DPAUX_HPD_IRQ_CONFIG);
+ tegra_dpaux_writel(dpaux, DPAUX_HPD_CONFIG_UNPLUG_MIN_TIME(1) | DPAUX_HPD_CONFIG_PLUG_MIN_TIME(1), DPAUX_HPD_CONFIG);
mutex_lock(&dpaux_lock);
list_add_tail(&dpaux->list, &dpaux_list);
,
Mar 29 2016
I notice the X1 TRM states: "When DP is active, the LANE0_DP_LANE2 field should be used for lane2 and LANE2_DP_LANE0 should be used for lane0." However the driver is using LANE0_DP_LANE2 for lane0. I tried switching the lane mapping around to match the TRM, but that causes things to stop working entirely. So presumably this is a copy-paste error leftover from t124 systems?
,
Mar 29 2016
,
Mar 29 2016
,
Mar 30 2016
@c12: It can detect the cable even I use the ToT kernel without changing anything at my side. But my issue is that it is failed to read edid due to some i2c errors like this: [ 102.809624] [drm:drm_helper_hpd_irq_event] [CONNECTOR:29:DSI-1] status updated from connected to connected [ 102.819530] [drm:drm_helper_hpd_irq_event] [CONNECTOR:31:DP-1] status updated from disconnected to connected [ 102.829856] [drm:drm_mode_getconnector] [CONNECTOR:29:?] [ 102.835207] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:29:DSI-1] [ 102.843500] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:29:DSI-1] probed modes : [ 102.853635] [drm:drm_mode_debug_printmodeline] Modeline 33:"2560x1800" 60 331334 2560 2640 2720 2800 1800 1804 1808 1812 0x0 0x0 [ 102.865208] [drm:drm_mode_getconnector] [CONNECTOR:29:?] [ 102.870777] [drm:drm_mode_getconnector] [CONNECTOR:31:?] [ 102.876086] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:31:DP-1] [ 102.884649] [drm:drm_dp_i2c_do_msg] transaction failed: -110 [ 102.890312] [drm] Bare address transaction is failed: -110 [ 102.896469] [drm:drm_dp_i2c_do_msg] native defer [ 102.902325] [drm:drm_dp_i2c_do_msg] native defer [ 102.908099] [drm:drm_dp_i2c_do_msg] native defer [ 102.913974] [drm:drm_dp_i2c_do_msg] transaction failed: -110 [ 102.920200] [drm:drm_dp_i2c_do_msg] native defer [ 102.925835] [drm:drm_dp_i2c_do_msg] native defer [ 102.931469] [drm:drm_dp_i2c_do_msg] native defer [ 102.937230] [drm:drm_dp_i2c_do_msg] native defer [ 102.942892] [drm:drm_dp_i2c_do_msg] native defer [ 102.948738] [drm:drm_dp_i2c_do_msg] native defer [ 102.954647] [drm:drm_dp_i2c_do_msg] native defer [ 102.959868] [drm:drm_dp_i2c_do_msg] too many retries, giving up [ 102.965784] [drm] Bare address transaction is failed: -121 [ 102.971695] [drm:drm_dp_i2c_do_msg] native defer [ 102.977477] [drm:drm_dp_i2c_do_msg] native defer [ 102.983128] [drm:drm_dp_i2c_do_msg] native defer [ 102.988778] [drm:drm_dp_i2c_do_msg] native defer [ 102.994427] [drm:drm_dp_i2c_do_msg] native defer [ 103.000239] [drm:drm_dp_i2c_do_msg] native defer [ 103.005892] [drm:drm_dp_i2c_do_msg] native defer [ 103.011106] [drm:drm_dp_i2c_do_msg] too many retries, giving up [ 103.017502] [drm:drm_dp_i2c_do_msg] transaction failed: -110 @c13: AFAIK, the "When DP is active, the LANE0_DP_LANE2 field should be used for lane2 and LANE2_DP_LANE0 should be used for lane0." is automatically done by HW once the SW choose the DP or HDMI protocol. So the code is correct and no need to do the switch on the lane mapping. I met the issue of training link before when I was debugging the compatibility issue on DP monitor. I should have fixed the bugs I found with the following 4 CLs https://chromium-review.googlesource.com/#/c/331028 https://chromium-review.googlesource.com/#/c/331029 https://chromium-review.googlesource.com/#/c/331100 https://chromium-review.googlesource.com/#/c/331101 I attached the code to dump the related registers and maybe you can try it and check where it is failed.
,
Mar 31 2016
+frh Frank, here are the images I'm using for testing. They're ToT plus a few debug patches on top. https://drive.google.com/a/google.com/folderview?id=0B3i2APvE8nD1YVY4YV9BQmlaT2M&usp=sharing
,
Apr 5 2016
Was looking at the HDMI start-up timing on the scope. See attached images. Red is I2C (DDC) clock, Yellow is the HDMI clock, and Blue and Green are HDMI data lines. HDMI_1.png - What I'm seeing is the HDMI signals starting to toggle about 60msec after the HoHo is plugged into the Ryu. Then about 200msec after that, I see a flury of I2C (DDC) transactions (probably reading the EDID). HDMI_2.png - zoom in on the initial HDMI data signalling HDMI_3.png - zoom in on the initial edges of the HDMI signalling. Note the clock is about 100kHz and looks like perhaps it has some pre-emphasis applied to it (that's the only way I can explain why it looks so funny).
,
Apr 5 2016
My (naive) interpretation of these scope traces: - The i2c traffic makes sense since we need to read the EDID - I can't explain the weirdness of the clock lane. I don't think we default to any pre-emphasis on the DP side, but I'd need to double check. Perhaps hoho uses pre-emphasis? - It looks like the host isn't even trying to send HDMI video/control data. I suppose this makes sense, since we can't train the DP link. I'm not sure how hoho does training, I assume we need to have the DP half trained before it'll send meaningful data on the data lanes. Can we get a trace on the DP side of the adapter to see what's happening there?
,
Apr 6 2016
Looks like the early transitions here are probably just HoHo turning on. The same thing happens when I plug the HoHo into a Chell. I also looked at the HPD (connected from the DP/HDMI converter to the micro on HoHo)and AUX signals. On both Ryu and Chell, the HPD goes high about 750msec after connection. Then, we get some AUX transactions happening for 1-2secs. On Chell we get a pulse on HPD at about 2.9sec, followed by a DDC transaction, followed by the HDMI clock and data. Don't see any of this on Ryu. See attached scope pic for what I see on Chell. Blue is DDC, Red is HDP, Yellow is HDMI clock.
,
Apr 6 2016
Also wired up the DP0 signal going into the HoHo (right at the cap on the Hoho side). Took some scope shots. HDMI4.png: This is for Chell. You can see the DP0 signal starts toggling at about 2.46s. Shortly before the HPD signal toggles. DP0_CHELL.png: This is a close up of the start of DP0. It's driven low, for 15ns, then a nice 800MHz clock is driven. DP0_RYU.png: This is the Ryu startup. For some reason a lot noiser. The system isn't driving it low initially, and the waveform does not look like anything. DP0_EYE_CHELL.png: This is a quick eye diagram of Chell driving the DP0 line. DP0_EYE_RYU: This is Ryu driving the DP0 line (which it is doing, so it's always trying to drive the display). Doesn't look too bad, but the voltage scale is the same so for some reason the swing is a lot higher.
,
Apr 7 2016
> DP0_EYE_RYU: This is Ryu driving the DP0 line (which it is doing, so it's always trying to drive the display). I'm guessing we don't stop the training pattern generation when it fails, so that's what we're seeing here, as opposed to video data. > Doesn't look too bad, but the voltage scale is the same so for some reason the swing is a lot higher. This is probably a result of failing training. As we fail channel eq, we increase the swing a number of times. Chell probably succeeds on training at a much lower swing.
,
Apr 8 2016
The initial pattern looks really odd (as in DP0_RYU.png above). Could this be a clue as to why the training is failing?
,
Apr 8 2016
@c23: I can't imagine we would successfully train with a clock lane such as that. However, when I had it on the scope yesterday, I couldn't reproduce (the signal looked clean). Moar investigation needed!
,
Apr 8 2016
Perhaps you weren't triggering correctly. I was able to reproduce every time. I took another scope shot of the first second of the training. It looks very strange.
,
Apr 13 2016
,
Apr 13 2016
,
Apr 13 2016
Some comments on the initial DP waveforms: 1. Verified that Pixel-2 (laptop), also has the same clock waveform as seen on the Chell design in comment 2 (see DP0_CHELL.png vs DP0_RYU.png). 2. On Ryu, the first 100ms look like random data. This is followed by a brief quiet period and then a fixed pattern is transmitted. 3. As can be seen in the attached pic, during the fixed pattern, the waveform has a RC decay behavior. Starts at a common mode of 0V, and then decays about 150mV within 20us. Seems strange. This behavior can be seen on all the DP lanes. I'm probing with a Diff probe on HoHo (the HDMI dongle). I've probed on both sides of the caps and it seems consistent.
,
Apr 19 2016
,
Apr 27 2016
Some feedback from our DP hardware engineers based on the debug logs and comments: I think we should fix the issues one by one in following order: 1. make hotplug work stable. hotplug is not related to DP transfer at all, should be easier to fix. 2. read correct DPCD/EDID through the dongle. 3. link training. 4. video. If we can't even get a stable hot plug, then the problem is with the USB PD controller on the system or the USB-PD controller in the USBC->HDMI adapter. DP hotplug events are sent via USB-PD messages, not a physical wire, when USB-C is used. Are you able to get the expected EDID from the DP to HDMI bridge?
,
Apr 27 2016
@cbareng: Yes. We are successful in parts 1 & 2, and partially part 3. Clock recovery works, but channel eq fails. There's more detail in the comments (specifically c8).
,
Apr 27 2016
FYI, workaround for 1) should it be necessary ... is to directly assert/deassert HPD root@dragon:/ # fwtool ec gpioget USBC_DP_HPD Firmware debug Tool GPIO USBC_DP_HPD = 0 root@dragon:/ # fwtool ec gpioset USBC_DP_HPD 1 Firmware debug Tool GPIO USBC_DP_HPD set to 1
,
Apr 28 2016
Hi, Sean From our DP hardware engineers: "normally, the signal quality may cause channel equalization fail. since HBR2 frequency is high, if the dongle supports RBR/HBR, can we try slow rate first?that should be easier to pass" Could you please help to try the RBR/HBR first? Thanks
,
Apr 28 2016
@c34: I tried 2.7GHz and 1.62GHz rates with the same result.
,
May 2 2016
Feedback from one of our DP hardware engineers: I think the observed reflection could be a real system characteristic or it could be due to the impedance discontinuity at the probe connection point in the middle of the transmission line. A few ideas for follow-up experiments: 1- test whether the DP signal straight out of the Chell or Ryu source is good by measuring the signal out of the USB-C connector terminated to 50ohms. I.e. use some USB-C breakout board or test adapter to connect probes with internal 50ohm terminations. 2- to view the eye diagram that the DP-to-HDMI converter actually "sees" at its input, I would recommend using the highest impedance probe possible and measuring as close to the converter IC input pins as possible. Ideally you would remove the IC, terminate the input pins to 50ohms, and measure at the input pins. You want to make sure the signal sees 50ohm termination at the end of the line. 3- Use a TDR (time domain reflectometer) to actually measure the trace impedance looking into the DP-to-HDMI converter IC when it's powered up and active. The TDR measurement should show if there is any big impedance discontinuity in the trace or if the converter IC is terminating the signal to the wrong resistance.
,
May 3 2016
Which comment were you referring to when mentioning reflections? From what I can see the initial output from the nVidia Soc is random data while from the x86 based system it's a clean clock at 800MHz. Is this expected? Also the waveform goes negative shortly after the training starts. Is this expected or considered an issue? Perhaps the DP_N signal stops toggling? Note, I was measuring right at the input to the Megachips HDMI converter, with a high speed high impedance diff probe (12Ghz BW). The cable is pretty short. While it could be a signal integrity issue, we've seen these devices work at 4k resolutions in DP mode (not sure if that's direct DP or DP bridge).
,
May 3 2016
Frank, the comment about reflections is in regard to the scope captures in comment #21. I'll get answers to your other questions. I quickly ran into Larry R and he mentioned some progress, related to EDID. Can someone provide more detail on that?
,
May 4 2016
Hi, Sean Would you mind trying the attached hack with dump of some related registers during link training ? Then we could check whether the value in these registers are correct or not. Thanks
,
May 4 2017
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue. The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 4 2017
|
|||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||
Comment 1 by seanpaul@chromium.org
, Mar 24 2016