Hi,

Heikki Krogerus <heikki.kroge...@linux.intel.com> writes:
>> > +  wcove->cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
>> 
>> we have a slight problem here that affects users of this particular
>> driver. Well, more specifically, it affects Intel Joule.
>> 
>> Because of the way ASL was written and the way Intel's DRD mux works, we
>> don't have a state which means "don't route USB signals to either Host
>> or Peripheral". Because of that, when we plug the type-c cable either
>> XHCI or dwc3 will have noise coming into the IP.
>> 
>> If default mode ends up being peripheral we have two possible problems
>> here:
>> 
>> i) device-to-device cable assembly
>> 
>>      this won't be a big problem because we will just negotiate who's
>>      Sink and who's Source then change mux on one side.
>> 
>> ii) lack of disconnect IRQ on dwc3
>> 
>>      Because of how ASL was written, when we unplug the cable, mux's
>>      VBUS_VALID bit won't be cleared which means dwc3 won't generate
>>      disconnect interrupt. This means that upon cable reconnect (!!)
>>      we will run ->disconnect() callback. The result is that dwc3
>>      will never runtime suspend.
>> 
>> If default mode ends up being host we're possibly going to end up with a
>> host-to-host cable assembly. Now this can cause 2 issues:
>> 
>> i) port config error
>> 
>>      host-to-host is not a supported cable assembly. While we see
>>      errors on dmesg, eventually type-c negotiation will happen and
>>      nothing will actually break.
>> 
>> ii) DbC can start on the other end of the cable
>> 
>>      Now this was really surprising to me. When testing this on Intel
>>      Joule and plugging Intel Joule straight to my PC's roothub port,
>>      I noticed Joule ended up being host and my Desktop (!!!!) became
>>      a peripheral enumerated by Joule. I can only assume this is DbC
>>      somehow being started.
>> 
>>      The only way to have Joule become a peripheral is to connect it
>>      through an external hub to my PC. Odd, ain't it?
>> 
>> I'm not sure how to solve this problem apart from modifying BIOS :-( Any
>> ideas?
>
> I don't think there is any other way to fix this expect modifying BIOS.
>
> The VBUS_VALID bit would need to be handled separate in ASL.

That means we need some method for figuring out VBUS is above 4.4V.

-- 
balbi

Attachment: signature.asc
Description: PGP signature

Reply via email to