Re: USB type-C altmode support for UCSI

[whitequark]

On 2018-09-05 13:50, Mario.Limonciello@xxxxxxxx wrote:
> > > (There's also an UCSI bug where no notifications appear when connecting
> > > a device, only when disconnecting and only once, but it can be worked
> > > around by reloading the module, so it isn't critical. Not sure what's up
> > > with that either.)
> >
> > This is indeed a separate issue, and you are the second person that
> > reports it. Either the (EC) firmware on those laptops is not
> > generating the connection event as is should for some reason, or the
> > EC driver in Linux kernel fails to deliver the event to the UCSI
> > driver. I don't have XPS 13 that I could use to reproduce the issue
> > unfortunately.
> >
> > Mario! Can you help with this?

First, thanks everyone for spending time on this! I really appreciate 
it.

> I need to know which system this was and which BIOS FW package to try
> to reproduce
> if I can pass this to the right people, 9360/9370?  Current FW?

Here is all relevant system info, taken from dmidecode:

System Information
        Manufacturer: Dell Inc.
        Product Name: XPS 13 9360
        Version: Not Specified
        Serial Number: J5NCSF2
        UUID: 4C4C4544-0035-4E10-8043-CAC04F534632

BIOS Information
        Vendor: Dell Inc.
        Version: 2.9.0
        Release Date: 07/09/2018

> Is this happening with all type-C devices?  Or just Thunderbolt?  Or
> (worse) just that TBT device?

Unfortunately this is the only TBT and (native) USB-C device I own.
Non-Apple TBT3 to TBT2 adapters are very expensive, and I wanted to
avoid that by getting this Apple adapter.

> > This laptop doesn't support SET_NEW_CAM command so I can't do anything
> > laptop-side. I can probably modify adapter firmware if I know what to
> > change, but I'm not sure why this doesn't work in the first place.
>
> I don't really see any problems with USB Type-C here. The PD
> controller seems to take the steps that it should take when a device
> is plugged to the connector: It checks the identity, SVIDs and their
> modes, etc. I don't know based on that sniffer output has the
> Thunderbolt alternate mode been entered or not, but I would imagine
> the PD controller does not try to enter any modes unless the
> Thunderbolt controller explicitly tells it to do so.

The Thunderbolt altmode is not entered, there are no attempts to do so.

> Some Dell XPS systems do not support that TBT2<->TBT3 adapter. I think 
> I
> tried this on XPS 15 9550 and XPS 13 9365 and in both cases it is
> rejected. I think it has something to do with the PD controller
> firmware. Same goes if you Plug TB16 dock and to that dock then connect
> the adapter + device.

This is my understanding as well, however I'd like to fix this issue.
From looking at the BIOS image I can see that the 9360 uses a TPS65982
USB PD controller. The adapter uses a TPS65983A (confusingly remarked
by Apple as CD3215B). I've seen reports on the web that there is some
inherent incompatibility between TPS65982 and TPS65983, however TI is
for some reason extremely secretive about TPS65983 and I wasn't able
to get anything definitive about it.

Anyway, I've reverse engineered a nontrivial part of the TI TPS6598x
firmware and register layout, however my understanding of Thunderbolt
and USB PD is not sufficient to proceed.

Mario, do you think you could get in touch with the people at Dell who
work with USB PD and ask if:

  (a) the adapter advertising an altmode with SVID:0x8087 VDO:0x00010001
      is the problem here, and
  (b) whether configuring the register 0x52 Intel VID Configuration in
      the adapter's USB PD controller to set TBTModeDataTXSOP=0x0000
      would help.

--
whitequark