New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 644663 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

System can’t detect HDMI via Apple dongle with AC connected after bootup.

Reported by kuen....@quantatw.com, Sep 7 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
Platform: 8530.79.0 (Official Build) stable-channel lars

Example URL:

Steps to reproduce the problem:
1. Shutdown Lars system.
2. Plug Apple 3in1 TypeC dongle in ELM system.
3. Plug AC adapter in Apple 3in1 dongle.
4. Plug HDMI in Apple 3in1 dongle.
5. Power on Lars system.
6. Login ChromeOS.
7. System unable to recognize HDMI monitor. 
   (System can be charged.)
8. Unplug AC from Apple dongle, HDMI can display immediately.

What is the expected behavior?

What went wrong?
System can detect HDMI via Apple 3in1 HDMI dongle.

Did this work before? N/A 

Is it a problem with Flash or HTML5? N/A

Does this work in other browsers? N/A 

Chrome version: 53.0.2785.96  Channel: stable
OS Version: 53.0.2785.96
Flash Version: Shockwave Flash 22.0 r0
 
Cc: rongchang@chromium.org drinkcat@chromium.org vpalatin@chromium.org tonycwlin@chromium.org
Cc: marc...@chromium.org
how is the "Elm" system mentioned in step 2. actually related to the 'lars' system mentioned in other steps ?
are there 2 laptops ? is there a typo ?

Can you collect logs or file a feedback at step 7 ?
Issue can reproduce in Lars and Elm platform.

For step 7: log-090716-171907.tar.gz
For step 8: Unplug AC_HDMI display_log-090716-172045.tar.gz
log-090716-171907.tar.gz
860 KB Download
Unplug AC_HDMI display_log-090716-172045.tar.gz
868 KB Download
The USB is enumerating properly at step 7.
Probably worth doing a USB PD trace (at the laptop port) to check when/how we get the HPD in ENTER_MODE and ATTENTION (and whether we enter correctly the DP mode before this)
Components: -Internals>Media OS>Kernel
this is not media bug. give to ChromeOS team.
Cc: ka...@chromium.org sontis@chromium.org tbroch@chromium.org
Components: -OS>Kernel OS>Kernel>Display
Status: Untriaged (was: Unconfirmed)
Confirmed the issue is reproducible in 8950.0.0, 56.0.2905.0. 

It's not reproducible if power on the device first, then do step 2 - 7. 

Feedback report:
http://feedback/#/Report/15023650001. 
@7: Are you saying that the adapter never works? Can you try the adapter without any of the other steps?
#8: It means that if you follow step 5, then 2, 3, 4, 6, in that order, display works.

1, 2, 4, 5, 6 also works.

To summarize: If you boot the system with AC+HDMI connected to Apple dongle (exact sequence does not matter AFAICT), HDMI output does not work until: you unplug/replug the whole Apple dongle OR you unplug the AC adapter.

We'll try to get PD traces this afternoon with Tony.
Cc: mdhayter@chromium.org adamrodr...@chromium.org
We think this is a Apple HDMI adapter bug, fixed with their latest FW update (https://support.apple.com/en-us/HT205858).

We have 3 Apple HDMI adapters here:
 1. "old" adapter with old FW (bcdDevice 45.26 with FW 1.58)
 2. "new" adapter with old FW (bcdDevice 45.28 with FW 1.58)
 3. "new" adapter with new FW (bcdDevice 45.28 with FW 2.33)

(bcdDevice number can be obtained using lsusb. AFAIK FW version can only be obtained from a Mac, see Apple website above)

1/2 both fail the test case above, while 3 works fine.

[on a related note, 1/2 also fails to charge using a non-PD power adapter, while 3 works fine]

Correction, the case that works fine with adapter 3 (and not with 1/2) is:
 1. Power on elm
 2. Plug Apple dongle + power + HDMI
 3. Shut down elm
 4. Power on elm
  => Display works

However, if the dongle + power + HDMI is connect in S5 (when elm is off), display does not come up on reboot.

Traces attached, it looks like when adapter is plugged in S5, dongle does not send attention message.
fw2.33 with elm in s0.tdc
16.5 KB Download
fw2.33 with elm from s5.tdc
20.8 KB Download

Comment 12 Deleted

In S0, Displayport configuration happens _before_ the power role swap:
 - elm sends DP Status VDM
 - Adapter replies with 0000001a, which mean:
    + bit 4: Multi-function preferred
    + bit 3: Adaptor DP functionality is enabled and operational
    + bit 1:0: UFP_D is connected.
 - elm send DP configure 00000806
 - Adapter replies with _Ack_
 - Later on, Adapter sends attention message with VDO 0000019a (IRQ_HPD, HPD_High, and the bits above (0000001a))

In S5, Displayport configuration happens when adapter is already source (there is no power role swap):
 - elm sends DP Status VDM
 - Adapter replies with 00000016, which mean:
    + bit 4: Multi-function preferred
    + bit 2: Adaptor has detect low power and disabled DP support
    + bit 1:0: UFP_D is connected.
 - elm send DP configure 00000806
 - Adapter replies with _Nack_
 - Adapter never sends attention message

I'm not sure why the adapter disables DP support in S5, there is a charger connected so it should not be some low power mode.
Re: I'm not sure why the adapter disables DP support in S5

I'd guess to meet ECO standards like 'CEC 24hr charge & maintain' although as the dongle doesn't ship w/ device that's certainly not a requirement in the strictest sense.
Attached trace collected with Apple Macbook (same adapter 3 with recent FW), system off (S5).

The interesting difference is that the Macbook accepts VConn swap from dongle:
 - SRC: VCONN SWAP
 - SNK: WAIT
 - SRC: VCONN SWAP (1 second later)
 - SNK: ACCEPT

While elm just rejects it:
 - SRC: VCONN SWAP
 - SNK: REJECT

The reason being that usb_pd_protocol.c/PD_CTRL_VCONN_SWAP calls pd_check_vconn_swap(port), which is implemented on elm as:
int pd_check_vconn_swap(int port)
{
	/* in G3, do not allow vconn swap since 5V power source is off */
	return gpio_get_level(GPIO_5V_POWER_GOOD);
}

As the comment says, we do not have 5V regulator enabled, so we reject the command.

If we enable the GPIO in EC console:
gpioset SYSTEM_POWER_H 1
(then check the POWER_GOOD is on:)
gpioget 5V_POWER_GOOD   
  1  5V_POWER_GOOD

And then plug the adapter, DP configure 00000806 is acked, and display works fine on next AP boot.

Actually, we can even disable 5V after negotiation is complete:

gpioset SYSTEM_POWER_H 0

And adapter will still work fine on next boot.

Problem is, enabling that GPIO switches on the PMIC as well, I don't think we really want to do this, even if we just do it when the dongle is plugged... I wonder if there is another workaround we could use...
> Actually, we can even disable 5V after negotiation is complete:
> gpioset SYSTEM_POWER_H 0
> And adapter will still work fine on next boot.

Sure but you are breaking your contract to supply VCONN ...
(admitting that the dongle was supplying the VCONN before and asks the laptop to supply it)

> I wonder if there is another workaround we could use...

The VCONN_SWAP should happen when we are booting the system.
One way is to register the (rejected) request and initiate the swap at boot,
or Hard reset the dongle at boot (but we are momentarily killing our own supply).

Actually at boot, if we are a sink with a PD contract and a Vconn sink, we might always try a VCONN swap
e.g. you can try to add a call to pd_request_vconn_swap() in dual_role_on() and see if this would be an effective workaround for the Apple AV dongle.
At first sight, I don't see any downside of doing this, excepted the corner case of the bad PD peripheral freaking out on the VCONN request. If we are connected to the power source through an active VCONN-powered cable, we might be less efficient afterwards.

Thinking more about it, a less brute-force implementation:
the DP alternate mode of the dongle should have the 'Vconn required' bit set in the AMA VDO.
Then before entering this Alternate mode, we should definitely check whether we are the VConn provider and swap vconn if we are not.

Components: OS>Firmware>EC
Owner: drinkcat@chromium.org
Status: Started (was: Untriaged)
Thanks, implemented among these lines in the series here:
https://chromium-review.googlesource.com/#/c/415698/

Basically:
 1. https://chromium-review.googlesource.com/#/c/415697/ swaps vconn upon receiving the AMA (if possible and necessary), and
 2. https://chromium-review.googlesource.com/#/c/415698/ forces discovery identity on AP boot (which happens to trigger the process in 1).
Project Member

Comment 18 by bugdroid1@chromium.org, Dec 14 2016

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

commit a573d17be93b52e6b3cb0ab7bf374199091752f4
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 04:26:24 2016

usb_pd_protocol: Rename PD_FLAGS_DATA_SWAPPED to _CHECK_IDENTITY

Rename the variable to actually tell us what it does (it sends a
Discover Identity command), instead of littering the code with
comments explaining why we set DATA_SWAPPED when the data roles
have not really been swapped.

BRANCH=none
BUG= chromium:644663 
TEST=make buildall -j

Change-Id: Idbad38e48a55d6518ef82b32a4d96fee65264aae
Reviewed-on: https://chromium-review.googlesource.com/415696
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>

[modify] https://crrev.com/a573d17be93b52e6b3cb0ab7bf374199091752f4/include/usb_pd.h
[modify] https://crrev.com/a573d17be93b52e6b3cb0ab7bf374199091752f4/common/usb_pd_protocol.c

Project Member

Comment 19 by bugdroid1@chromium.org, Dec 14 2016

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

commit 87e8cd610313fa7fe902c2fd359ade18e6b22ef0
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 03:42:11 2016

usb_pd_policy: Automatically swap vconn if adapter requests it

During discovery, if adapter requests vconn power in the AMA flags,
make sure that we provide vconn.

This, for example, is necessary for the Apple HDMI adapter to work
on boot, when connected in S5. In that case, adapter does request
vconn swap, but we reject that as the system is off, and, therefore
5V supply is off. On boot, we send another discovery request, which
will detect this case and swap the power.

BRANCH=none
BUG= chromium:644663 
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
     type "pd 0 vdm ident" in console, display works.

Change-Id: I55b6658c2bc0574b8427ae086f61daf03730a725
Reviewed-on: https://chromium-review.googlesource.com/415697
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

[modify] https://crrev.com/87e8cd610313fa7fe902c2fd359ade18e6b22ef0/common/usb_pd_policy.c
[modify] https://crrev.com/87e8cd610313fa7fe902c2fd359ade18e6b22ef0/include/usb_pd.h
[modify] https://crrev.com/87e8cd610313fa7fe902c2fd359ade18e6b22ef0/common/usb_pd_protocol.c

Project Member

Comment 20 by bugdroid1@chromium.org, Dec 14 2016

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

commit dba4c111137b1819538a314043760bf17092690f
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 04:29:09 2016

usb_pd_protocol: Force rediscovering identity on boot

This is useful with Apple's HDMI adapter, as the code that sends
the discovery message will also swap vconn as required.

BRANCH=none
BUG= chromium:644663 
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
     display works.

Change-Id: I21d47c69e2c7153a5d808dedcb1abe360ce3f5c0
Reviewed-on: https://chromium-review.googlesource.com/415698
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>

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

Project Member

Comment 21 by bugdroid1@chromium.org, Dec 15 2016

Labels: merge-merged-firmware-oak-8438.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/3a8097677c2a2725b66315dd0c71fb935db5cd27

commit 3a8097677c2a2725b66315dd0c71fb935db5cd27
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 04:26:24 2016

usb_pd_protocol: Rename PD_FLAGS_DATA_SWAPPED to _CHECK_IDENTITY

Rename the variable to actually tell us what it does (it sends a
Discover Identity command), instead of littering the code with
comments explaining why we set DATA_SWAPPED when the data roles
have not really been swapped.

BRANCH=none
BUG= chromium:644663 
TEST=make buildall -j

Change-Id: Idbad38e48a55d6518ef82b32a4d96fee65264aae
Reviewed-on: https://chromium-review.googlesource.com/415696
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit a573d17be93b52e6b3cb0ab7bf374199091752f4)
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
[drinkcat: Minor conflicts in usb_pd_protocol.c]
Reviewed-on: https://chromium-review.googlesource.com/420424
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>

[modify] https://crrev.com/3a8097677c2a2725b66315dd0c71fb935db5cd27/include/usb_pd.h
[modify] https://crrev.com/3a8097677c2a2725b66315dd0c71fb935db5cd27/common/usb_pd_protocol.c

Project Member

Comment 22 by bugdroid1@chromium.org, Dec 15 2016

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

commit 4b21744ae76d356816c587c759e316e350e37a29
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 03:42:11 2016

usb_pd_policy: Automatically swap vconn if adapter requests it

During discovery, if adapter requests vconn power in the AMA flags,
make sure that we provide vconn.

This, for example, is necessary for the Apple HDMI adapter to work
on boot, when connected in S5. In that case, adapter does request
vconn swap, but we reject that as the system is off, and, therefore
5V supply is off. On boot, we send another discovery request, which
will detect this case and swap the power.

BRANCH=none
BUG= chromium:644663 
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
     type "pd 0 vdm ident" in console, display works.

Change-Id: I55b6658c2bc0574b8427ae086f61daf03730a725
Reviewed-on: https://chromium-review.googlesource.com/415697
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 87e8cd610313fa7fe902c2fd359ade18e6b22ef0)
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/420425
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>

[modify] https://crrev.com/4b21744ae76d356816c587c759e316e350e37a29/common/usb_pd_policy.c
[modify] https://crrev.com/4b21744ae76d356816c587c759e316e350e37a29/include/usb_pd.h
[modify] https://crrev.com/4b21744ae76d356816c587c759e316e350e37a29/common/usb_pd_protocol.c

Project Member

Comment 23 by bugdroid1@chromium.org, Dec 15 2016

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

commit 386159c2ee0bbfd5b0c669798eb7cc685aa56434
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 04:29:09 2016

usb_pd_protocol: Force rediscovering identity on boot

This is useful with Apple's HDMI adapter, as the code that sends
the discovery message will also swap vconn as required.

BRANCH=none
BUG= chromium:644663 
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
     display works.

Change-Id: I21d47c69e2c7153a5d808dedcb1abe360ce3f5c0
Reviewed-on: https://chromium-review.googlesource.com/415698
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit dba4c111137b1819538a314043760bf17092690f)
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
[drinkcat: Context conflict in usb_pd_protocol.c:dual_role_on]
Reviewed-on: https://chromium-review.googlesource.com/420426
Commit-Queue: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>

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

Project Member

Comment 24 by bugdroid1@chromium.org, Dec 15 2016

Labels: merge-merged-firmware-reef-9042.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/e78d07cc81434e0a0924b4c7893dd70a01731099

commit e78d07cc81434e0a0924b4c7893dd70a01731099
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 04:26:24 2016

usb_pd_protocol: Rename PD_FLAGS_DATA_SWAPPED to _CHECK_IDENTITY

Rename the variable to actually tell us what it does (it sends a
Discover Identity command), instead of littering the code with
comments explaining why we set DATA_SWAPPED when the data roles
have not really been swapped.

BRANCH=none
BUG= chromium:644663 
TEST=make buildall -j

Change-Id: Idbad38e48a55d6518ef82b32a4d96fee65264aae
Reviewed-on: https://chromium-review.googlesource.com/415696
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420778
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>

[modify] https://crrev.com/e78d07cc81434e0a0924b4c7893dd70a01731099/include/usb_pd.h
[modify] https://crrev.com/e78d07cc81434e0a0924b4c7893dd70a01731099/common/usb_pd_protocol.c

Project Member

Comment 25 by bugdroid1@chromium.org, Dec 15 2016

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

commit 2eabc34f72e96ff587ab5fe241672edf6462d7f6
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 03:42:11 2016

usb_pd_policy: Automatically swap vconn if adapter requests it

During discovery, if adapter requests vconn power in the AMA flags,
make sure that we provide vconn.

This, for example, is necessary for the Apple HDMI adapter to work
on boot, when connected in S5. In that case, adapter does request
vconn swap, but we reject that as the system is off, and, therefore
5V supply is off. On boot, we send another discovery request, which
will detect this case and swap the power.

BRANCH=none
BUG= chromium:644663 
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
     type "pd 0 vdm ident" in console, display works.

Change-Id: I55b6658c2bc0574b8427ae086f61daf03730a725
Reviewed-on: https://chromium-review.googlesource.com/415697
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420779
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>

[modify] https://crrev.com/2eabc34f72e96ff587ab5fe241672edf6462d7f6/common/usb_pd_policy.c
[modify] https://crrev.com/2eabc34f72e96ff587ab5fe241672edf6462d7f6/include/usb_pd.h
[modify] https://crrev.com/2eabc34f72e96ff587ab5fe241672edf6462d7f6/common/usb_pd_protocol.c

Project Member

Comment 26 by bugdroid1@chromium.org, Dec 15 2016

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

commit 246afeb8417f4404cdadff012389eb7de847875b
Author: Nicolas Boichat <drinkcat@google.com>
Date: Fri Dec 02 04:29:09 2016

usb_pd_protocol: Force rediscovering identity on boot

This is useful with Apple's HDMI adapter, as the code that sends
the discovery message will also swap vconn as required.

BRANCH=none
BUG= chromium:644663 
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
     display works.

Change-Id: I21d47c69e2c7153a5d808dedcb1abe360ce3f5c0
Reviewed-on: https://chromium-review.googlesource.com/415698
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420780
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>

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

Project Member

Comment 27 by bugdroid1@chromium.org, Oct 30 2017

Labels: merge-merged-firmware-servo-9040.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/16bbea88e7f1f4da4cc40e60ee96324a77cded58

commit 16bbea88e7f1f4da4cc40e60ee96324a77cded58
Author: Nicolas Boichat <drinkcat@google.com>
Date: Mon Oct 30 17:04:48 2017

usb_pd_protocol: Rename PD_FLAGS_DATA_SWAPPED to _CHECK_IDENTITY

Rename the variable to actually tell us what it does (it sends a
Discover Identity command), instead of littering the code with
comments explaining why we set DATA_SWAPPED when the data roles
have not really been swapped.

BRANCH=none
BUG= chromium:644663 
TEST=make buildall -j

Change-Id: Idbad38e48a55d6518ef82b32a4d96fee65264aae
Reviewed-on: https://chromium-review.googlesource.com/415696
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420778
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/739994
Tested-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>

[modify] https://crrev.com/16bbea88e7f1f4da4cc40e60ee96324a77cded58/include/usb_pd.h
[modify] https://crrev.com/16bbea88e7f1f4da4cc40e60ee96324a77cded58/common/usb_pd_protocol.c

Project Member

Comment 28 by bugdroid1@chromium.org, Jan 5 2018

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

commit 8d726388ef83d8bde595542413b31e713a3fcd19
Author: Daisuke Nojiri <dnojiri@chromium.org>
Date: Fri Jan 05 19:32:01 2018

USB/PD: Request discover identity on boot

This patch makes the TCPM request discover identity on boot instead of
resume.

BUG= chromium:644663 ,b:70165261
BRANCH=none
TEST=Verified display works in the following cases:
1. On Fizz, plug in Dell type-c HDMI adapter in S0, shutdown, boot.
2. On Fizz, plug in Dell type-c HDMI adapter in S5, boot.
3. On Fizz, plug in type-c monitor in S0, suspend, resume.
4. On Fizz, plug in type-c monitor in S5, boot.
5. On elm, S5. Plug adapter with power+HDMI, boot.

Change-Id: Ib068c60bc51ebddc461378028a48c64662bc5b81
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/847970
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/852360

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

Project Member

Comment 29 by bugdroid1@chromium.org, Jan 8 2018

Labels: merge-merged-firmware-coral-10068.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/03ba81c13b72a7a94284c6ec992e006213ae97de

commit 03ba81c13b72a7a94284c6ec992e006213ae97de
Author: Daisuke Nojiri <dnojiri@chromium.org>
Date: Mon Jan 08 04:02:20 2018

USB/PD: Request discover identity on boot

This patch makes the TCPM request discover identity on boot instead of
resume.

BUG= chromium:644663 ,b:70165261
BRANCH=none
TEST=Verified display works in the following cases:
1. On Fizz, plug in Dell type-c HDMI adapter in S0, shutdown, boot.
2. On Fizz, plug in Dell type-c HDMI adapter in S5, boot.
3. On Fizz, plug in type-c monitor in S0, suspend, resume.
4. On Fizz, plug in type-c monitor in S5, boot.
5. On elm, S5. Plug adapter with power+HDMI, boot.

Change-Id: Ib068c60bc51ebddc461378028a48c64662bc5b81
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/853672
Commit-Queue: Sean FS Chiang <sean_fs_chiang@wistron.corp-partner.google.com>
Tested-by: Sean FS Chiang <sean_fs_chiang@wistron.corp-partner.google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>

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

Project Member

Comment 30 by bugdroid1@chromium.org, Mar 14 2018

Labels: merge-merged-firmware-eve-9584.B
The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/ec/+/c73cbaf6afbbaaee44ddbaf785fdb18b88788cbd

commit c73cbaf6afbbaaee44ddbaf785fdb18b88788cbd
Author: Daisuke Nojiri <dnojiri@chromium.org>
Date: Wed Mar 14 02:13:51 2018

USB/PD: Request discover identity on boot

This patch makes the TCPM request discover identity on boot instead of
resume.

BUG= chromium:644663 ,b:70165261
BRANCH=none
TEST=Verified display works in the following cases:
1. On Fizz, plug in Dell type-c HDMI adapter in S0, shutdown, boot.
2. On Fizz, plug in Dell type-c HDMI adapter in S5, boot.
3. On Fizz, plug in type-c monitor in S0, suspend, resume.
4. On Fizz, plug in type-c monitor in S5, boot.
5. On elm, S5. Plug adapter with power+HDMI, boot.

Change-Id: If865a0e79c54151ebdedf63a95ef26b652e438fc
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Original-Commit-Id: 069182f5e4082ae1cf569598cdc2d9d423dafaaa
Original-Change-Id: Ib068c60bc51ebddc461378028a48c64662bc5b81
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/847970
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/961785

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

Status: Fixed (was: Started)

Sign in to add a comment