Hi dianders@, can you share the adapter model or just it's picture?

I gave it to shawnn@, but I walked over and took a picture.  Looks like Dell DA200.

Picture attached.

Deleted: dellda200.jpg 2.5 MB

	dellda200.jpg 2.5 MB View Download

Yes, Dell DA200 is correct.

We used to have similar problems with that adapter before if I recall correctly.

could be related to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a86cda07af2c6

Mmmm, we have this Dell adapter at test desks - https://www.amazon.com/gp/product/B012DT6KW2/
Item model number	DA200
Will try to reproduce and get logs.

@4: It seems slightly unlikely it could be related to any kernel change since the EC doesn't even detect it the 2nd time around.  ...and a reboot of the EC is required to fix it.  

...or are you implying that a bad "N" value will somehow crash the adapter such that it needs to be power cycled in order to enumerate again?  The wording of the patch makes it sound (to me) like the worst that could happen with a bad "N" value is that we might fail to recover a clock and fail to display an image.

Note that I could reproduce this problem without actually having an HDMI cable plugged into the dock itself--it just failed to enumerate the 2nd time, which seems like it would make it even less likely that a display port clock would be crashing the device.

Indeed, if it happens without any HDMI cable then that's not the problem.

Able to reproduce this issue on M60 build 9592.94.0/60.0.3112.114

logs are present at https://storage.cloud.google.com/chromiumos-test-logs/bugfiles/cros/766814/debug-logs_20170919-164051.tgz?_ga=2.40681378.-1674710913.1495227414

#4: This is seen on kevin. The referenced patch is in the i915 code.

When kevin presents 3.0A Rp, I measure ~750 mV on CC, which puts us at the top of the Ra range. Interestingly, when we present 1.5A Rp, I measure ~480 mV, which is at the bottom of the Rd range (so it works).

"Why does this work sometimes?" -- kevin has two USB-C ports, but cannot it provide 3A to both ports due to design limitations.

-> At boot, 1.5A Rp will be presented to both ports.
-> When Rd is detected on any port, Rp control will kick in, which works as follows:
----> If 0 ports are in source role, both ports will get 3.0A Rp
----> If 1 port is in source role, it will get 3.0A Rp and the other will get 1.5A Rp.
----> If 2 ports are in source role, whichever was seen plugged first will get 3.0A Rp, and the other 1.5A Rp.

So, the part will work under either of the following cases:

1) It's the first sink device connected since EC boot / sysjump. We'll present 1.5A Rp just long enough to get through our state machine, and then Ra vs Rd won't matter.

2) There's a sink device connected to the other port first.

(1) is a quirk / bug, the behavior at boot should be consistent. I'll work on a fix (which will cause this particular part to work even less often, but will be less confusing for future debug).

@10: If I'm reading it right you're saying that there's a hardware problem somewhere.  Is the problem on our end or on the dock's end?

This dock does work on some laptops so (inevitably) people will blame our laptop for not working with it even if it's the dock's fault.  Are there any clever software tricks we can do to make things reliable?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/7b473c8efdd97bdd7e6a86213731edb4d80b5d96

commit 7b473c8efdd97bdd7e6a86213731edb4d80b5d96
Author: Shawn Nematbakhsh <shawnn@chromium.org>
Date: Thu Sep 21 18:54:26 2017

pd: Apply consistent Rp at boot

CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT Rp is applied when neither port
is a source, so apply it at boot to be consistent.

BUG= chromium:766814 
BRANCH=gru
TEST=On kevin, verify 3A Rp is applied to both ports at boot.

Change-Id: Ib62a96063783e8ef9ac9240800f445fa9e5a59af
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/675845
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

[modify] https://crrev.com/7b473c8efdd97bdd7e6a86213731edb4d80b5d96/common/usb_pd_protocol.c

3A -> 330uA @ 750mV is 2.27K
1.5A -> 180uA @ 480mV is 2.67K

It's almost as if the dongle has two Rd's applied to the same CC pin (5.1K/2 = 2.55K).

Try only attaching it to twinkie and applying the different pull-ups...if the voltages look like 0.218V@RpUSB, 0.578V@Rp1A5, and 1.161V@Rp3A0 (instead of the usual 0.409/0.984/1.72 for a 5.1K Rd), then there's something wrong with the dongle.  Also check if the CC voltages seem to follow each other, in case they're shorted together for some reason.

> tw res RP3A0 RP3A0                                                            
> adc                                                                           
  CC1_PD = 3299                                                                 
  CC2_PD = 1101   
> tw res RP1A5 RP1A5                                                            
> adc                                                                           
  CC1_PD = 3299                                                                 
  CC2_PD = 796 
> tw res RPUSB RPUSB                                                            
> adc                                                                           
  CC1_PD = 3299                                                                 
  CC2_PD = 410 

I don't see any significant difference when I change CC1 to Rd, so I don't think the CC lines are shorted together.

So, for RP3A0, I calculate Rd to be 2.33K, which is close to what you calculated before, and quite far out of spec.

We should probably talk to Dell about implementation, or tear down the thing ourselves.  That sounds pretty messed up.

> We should probably talk to Dell about implementation

I'm on it. For reference, the part is marked:

Model:DA200 RNHDN REV A02

28% of reviewers on Amazon give this adapter one star, major reasons being that it doesn't work in the first place or that it fails after a few weeks or months.

It should be noted that I wasn't one of them. :) Even knowing that their Rd
resistor is out of spec, I would actually only give it 2-stars, because
it's realistically something that can be fixed in a fixed rev of the
product.

I reserve 1-star reviews for stuff that is irredemable or actually blows up
my equipment.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/b42eebb9531f4ad58af6bc71abfe16601dc3a661

commit b42eebb9531f4ad58af6bc71abfe16601dc3a661
Author: Shawn Nematbakhsh <shawnn@chromium.org>
Date: Mon Sep 25 19:09:33 2017

pd: Apply consistent Rp at boot

CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT Rp is applied when neither port
is a source, so apply it at boot to be consistent.

BUG= chromium:766814 
BRANCH=gru
TEST=On kevin, verify 3A Rp is applied to both ports at boot.

Change-Id: Ib62a96063783e8ef9ac9240800f445fa9e5a59af
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/677087

[modify] https://crrev.com/b42eebb9531f4ad58af6bc71abfe16601dc3a661/common/usb_pd_protocol.c

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/106e634f1ccabf6ad63ac2e687a0f073efe9e6fb

commit 106e634f1ccabf6ad63ac2e687a0f073efe9e6fb
Author: Shawn Nematbakhsh <shawnn@chromium.org>
Date: Thu Sep 28 11:10:15 2017

pd: Apply consistent Rp at boot

CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT Rp is applied when neither port
is a source, so apply it at boot to be consistent.

BUG= chromium:766814 
BRANCH=gru
TEST=On kevin, verify 3A Rp is applied to both ports at boot.

Change-Id: Id8d4fc58229a8c243c311b9677ebd812cf51cfa9
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Original-Commit-Id: 7b473c8efdd97bdd7e6a86213731edb4d80b5d96
Original-Change-Id: Ib62a96063783e8ef9ac9240800f445fa9e5a59af
Original-Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/675845
Original-Commit-Ready: Shawn N <shawnn@chromium.org>
Original-Tested-by: Shawn N <shawnn@chromium.org>
Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690178

[modify] https://crrev.com/106e634f1ccabf6ad63ac2e687a0f073efe9e6fb/common/usb_pd_protocol.c

Dell has been notified of the problem, there is nothing else for us to do here.