Message-ID: <20180905132429.GB25121@kuha.fi.intel.com>
Date:   Wed, 5 Sep 2018 16:24:29 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     whitequark <whitequark@...tequark.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Mario Limonciello <mario.limonciello@...l.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: USB type-C altmode support for UCSI

+Mika, Mario, LKML

On Mon, Sep 03, 2018 at 02:17:46PM +0000, whitequark wrote:
> After looking through LKML, I've seen that people refer to you when
> discussing issues with USB-C device compatibility. Do you think you
> could help me with an Apple Thunderbolt 2 to 3 adapter? I've spent
> quite a while studying USB-C, reverse engineering platform and
> adapter firmware and so on, and I'm quite stumped.
> 
> I have a Dell XPS13 laptop. UCSI advertises port altmodes
> 8087:00000001, ff01:00001c46, 413c:00000001, in that order.
> When I plug in the adapter, UCSI advertises partner altmode
> 8087:00000001. A billboard class device enumerates. Nothing else
> happens; the Thunderbolt NHI device doesn't appear, and if I force
> it to appear via the WMI hook, there are no Thunderbolt events,
> and the only device on the Thunderbolt bus is the root switch.

Can you tell which XPS 13 model you have (9360 or 9370 or ...)?

> I made an USB PD sniffer. Here's the exchange that happens
> when I plug the adapter in (GOOD CRC and initial PDO stuff omitted):
> 
> -> REQ Disc Ident SVID:0xff00
> <- ACK Disc Ident SVID:0xff00 VDO:0x6c0005ac VDO:0x00000000 VDO:0x16570348
> VDO:1000000a
> -> REQ Disc SVID SVID:0xff00
> <- ACK Disc SVID SVID:0xff00 VDO:0x808705ac VDO:0x00000000
> -> REQ Disc Mode SVID:0x8087
> <- ACK Disc Mode SVID:0x8087 VDO:0x00010001
> 
> Nothing happens after that.
> 
> I'm a bit puzzled as to why the ACK Disc Mode has a VDO 0x00010001
> and not 0x00000001 as UCSI reports, which is also what I would expect
> from a Thunderbolt device. Am I misunderstanding something in the spec?

I don't have access to the Thunderbolt alt mode spec unfortunately, so
I can't really say what the VDO should be, but I do know that that is
what UCSI reports on all platforms. The VDO value is always 1 on the
first port, and 2 on the second.

> 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.

So I think the problem is with Thunderbolt in this case. Mika is the
man to talk about Thundebolt.

> (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?


Thanks,

-- 
heikki

Powered by blists - more mailing lists