Re: USB type-C altmode support for UCSI

Re: USB type-C altmode support for UCSI

[Heikki Krogerus]

+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

Re: USB type-C altmode support for UCSI

[Mika Westerberg]

On Wed, Sep 05, 2018 at 04:24:29PM +0300, Heikki Krogerus wrote:
> +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.

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.

Mario probably has more input about this one.

RE: USB type-C altmode support for UCSI

[Mario.Limonciello]

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

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?

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

Re: USB type-C altmode support for UCSI

[whitequark]

On 2018-09-05 13:50, Mario.Limonciello@dell.com 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

Re: USB type-C altmode support for UCSI

[whitequark]

On 2018-09-05 14:13, whitequark wrote:
> On 2018-09-05 13:50, Mario.Limonciello@dell.com wrote:
>> 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.

I have been able to verify two things by reflashing the adapter with 
upstream
(non-Apple) firmware and experimenting with the configuration:

(a) the altmode with SVID:0x8087 VDO:0x00010001 (16th bit set) means 
that
     this is an altmode advertised by a legacy Thunderbolt (3 to 2) 
adapter.
     So the adapter is fine here.

(b) the Dell USB PD controller doesn't try to negotiate the altmode even 
with
     advertised VDO:0x00000001. Something else is missing in the 
configuration.

-- 
whitequark

RE: USB type-C altmode support for UCSI

[Mario.Limonciello]

> -----Original Message-----
> From: whitequark [mailto:whitequark@whitequark.org]
> Sent: Friday, September 7, 2018 6:04 AM
> To: Limonciello, Mario
> Cc: heikki.krogerus@linux.intel.com; mika.westerberg@linux.intel.com; linux-
> kernel@vger.kernel.org
> Subject: Re: USB type-C altmode support for UCSI
> 
> On 2018-09-05 14:13, whitequark wrote:
> > On 2018-09-05 13:50, Mario.Limonciello@dell.com wrote:
> >> 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.
> 
> I have been able to verify two things by reflashing the adapter with
> upstream
> (non-Apple) firmware and experimenting with the configuration:
> 
> (a) the altmode with SVID:0x8087 VDO:0x00010001 (16th bit set) means
> that
>      this is an altmode advertised by a legacy Thunderbolt (3 to 2)
> adapter.
>      So the adapter is fine here.

Be really careful flashing to "upstream firmware" when it  comes to PD
controllers.  The configuration is usually tied to behavior of the firmware
on there and on in some instances can be modified at runtime via various
mechanisms.

> 
> (b) the Dell USB PD controller doesn't try to negotiate the altmode even
> with
>      advertised VDO:0x00000001. Something else is missing in the
> configuration.
> 
> --
> whitequark

I did inquire to folks who work on PD (not for this notebook)
and they told me that that indeed it's likely it's an alt mode bit missing in
the configuration.

Also they had said it would be interesting to know if anything newer suffers
this same fault (such as XPS 9370 or Precision 5530).

I'll reach out to the right folks for this system to see if we can get that changed,
but this will take some time, so don't expect a quick turnaround.

Re: USB type-C altmode support for UCSI

[Mika Westerberg]

On Mon, Sep 10, 2018 at 09:25:48PM +0000, Mario.Limonciello@dell.com wrote:
> Also they had said it would be interesting to know if anything newer suffers
> this same fault (such as XPS 9370 or Precision 5530).

I tried 9370 and it detects the adapter correctly. IIRC I did the same
for 5530 and it worked as well.

RE: USB type-C altmode support for UCSI

[Mario.Limonciello]

> -----Original Message-----
> From: Mika Westerberg [mailto:mika.westerberg@linux.intel.com]
> Sent: Tuesday, September 11, 2018 4:33 AM
> To: Limonciello, Mario
> Cc: whitequark@whitequark.org; heikki.krogerus@linux.intel.com; linux-
> kernel@vger.kernel.org
> Subject: Re: USB type-C altmode support for UCSI
> 
> On Mon, Sep 10, 2018 at 09:25:48PM +0000, Mario.Limonciello@dell.com wrote:
> > Also they had said it would be interesting to know if anything newer suffers
> > this same fault (such as XPS 9370 or Precision 5530).
> 
> I tried 9370 and it detects the adapter correctly. IIRC I did the same
> for 5530 and it worked as well.

Thanks for confirming that.  Hopefully the same change can be ported to PD controller
firmware then on other models, I'll inquire.

A different PD controller firmware problem?

[Theodore Y. Ts'o]

On Tue, Sep 11, 2018 at 01:02:00PM +0000, Mario.Limonciello@dell.com wrote:
> > I tried 9370 and it detects the adapter correctly. IIRC I did the same
> > for 5530 and it worked as well.
> 
> Thanks for confirming that.  Hopefully the same change can be ported to PD controller
> firmware then on other models, I'll inquire.

Hey Mario,

Sorry for the thread hijack (I've changed the subject line to make it
clear it's a separate issue), but just this evening I just had a
very.... interesting problem with my Dell XPS 9370, and it appears to
be related to the PD controller.

Sortly after 12:30am US/Eastern, I got a low power warning on my
system, and the battery power had dropped below 10%.  Apparently the
laptop was not accepting any charge any more.  I tried doing a suspend
to ram, and then unsuspended it, and it still wasn't accepting any
charge, even though the adapter indicated it was plugged in and
supplying power.  I then did a power cycle, and still the laptop
didn't indicate it was charging with a USB C 45W power supply plugged
in.

I inserted a Satechi USB C voltage monitor in-line, and found that
while it was powered on, the laptop has pulling 0 mA at 5V.  If the
laptop was suspended, it would pull 3A at 5V.  Rebooting and power
cycling didn't change this syndrome.

What *did* fix it was powering down, and disconnecting the power
adapter for 30 seconds or so.  Then when I plugged it back in, the
laptop started accepting 20V at 2A.  I assume what happened is that
the PD controller had crashed, and it required a powerdown *and*
unplugging the power to force the EC to reset.

I have noticed other problems where a USB C to HDMI adapter doesn't
quite work right (the laptop refuses to talk to the display), and the
*only* way to fix things is to powerdown Linux and then remove the
power plug.  So this is not the first time that this particular
technique is needed to make my Dell XPS 9370 (with NVMe SSD, currently
running XPS 13 9370 System Firmware version 0.1.5.1) happy again.

What's the best place to report this sort of problem?  And is there
anything more I can do to debug these sorts of apparent PD Controller
/ EC bugs?

					- Ted

RE: A different PD controller firmware problem?

[Mario.Limonciello]

Ted,

Sorry for my delayed responses.

> 
> On Tue, Sep 11, 2018 at 01:02:00PM +0000, Mario.Limonciello@dell.com wrote:
> > > I tried 9370 and it detects the adapter correctly. IIRC I did the same
> > > for 5530 and it worked as well.
> >
> > Thanks for confirming that.  Hopefully the same change can be ported to PD
> controller
> > firmware then on other models, I'll inquire.
> 
> Hey Mario,
> 
> Sorry for the thread hijack (I've changed the subject line to make it
> clear it's a separate issue), but just this evening I just had a
> very.... interesting problem with my Dell XPS 9370, and it appears to
> be related to the PD controller.
> 
> Sortly after 12:30am US/Eastern, I got a low power warning on my
> system, and the battery power had dropped below 10%.  Apparently the
> laptop was not accepting any charge any more.  I tried doing a suspend
> to ram, and then unsuspended it, and it still wasn't accepting any
> charge, even though the adapter indicated it was plugged in and
> supplying power.  I then did a power cycle, and still the laptop
> didn't indicate it was charging with a USB C 45W power supply plugged
> in.

Just to be clear was this a Dell adapter or another manufacturer?

If it's non-Dell, there could easily be an untested combination of controllers
and one getting into a bad state.

> 
> I inserted a Satechi USB C voltage monitor in-line, and found that
> while it was powered on, the laptop has pulling 0 mA at 5V.  If the
> laptop was suspended, it would pull 3A at 5V.  Rebooting and power
> cycling didn't change this syndrome.
> 
> What *did* fix it was powering down, and disconnecting the power
> adapter for 30 seconds or so.  Then when I plugged it back in, the
> laptop started accepting 20V at 2A.  I assume what happened is that
> the PD controller had crashed, and it required a powerdown *and*
> unplugging the power to force the EC to reset.

That's the same hypothesis I would have come to in these circumstances.

I haven't heard of this particular issue in the past, but that doesn't mean
anything since I don't work in Dell's support group or have access to their
call information.

Is this a 1 time occurrence or something you can regularly trigger with the
right set of events?

As you know if you can't trigger it regularly it's going to be just as hard
for this to be reproduced and fixed by the engineering team maintaining
this platform.

If you can trigger it regularly (or semi-regularly even) the right way to report
it would be to contact the ProSupport team, explain the circumstances that
can cause it and they would escalate it to the proper channels.

Sorry I can't be more helpful.

> 
> I have noticed other problems where a USB C to HDMI adapter doesn't
> quite work right (the laptop refuses to talk to the display), and the
> *only* way to fix things is to powerdown Linux and then remove the
> power plug.  

Is this with the DA200 or DA300?  Or something else?

I think it would be worth checking this with drm-tip, and if it keeps reproducing
there then:
1) Check if UCSI sysfs can tell you anything about what accessory mode the device is operating in.
I'm not sure if accessory_mode gets populated by the EC, but if it does it might be useful to debug.

2) Boot with drm.debug=0xe and double check the differences around the circumstances
of it working or not working.  Having to boot with it plugged in for it to work tells
me that it's either the wrong type C alternate mode coming up for this adapter or the graphics
driver not getting along with the adapter.

3) Raising it with the graphics mailing list.

> So this is not the first time that this particular
> technique is needed to make my Dell XPS 9370 (with NVMe SSD, currently
> running XPS 13 9370 System Firmware version 0.1.5.1) happy again.
> 
> What's the best place to report this sort of problem?  And is there
> anything more I can do to debug these sorts of apparent PD Controller
> / EC bugs?

It sounds like this one might be more reproducible.  If it's a Dell peripheral I think it should be
pretty easy for support to reproduce and escalate.

Re: A different PD controller firmware problem?

[Theodore Y. Ts'o]

On Thu, Nov 08, 2018 at 06:00:59PM +0000, Mario.Limonciello@dell.com wrote:
> > Sortly after 12:30am US/Eastern, I got a low power warning on my
> > system, and the battery power had dropped below 10%.  Apparently the
> > laptop was not accepting any charge any more.  I tried doing a suspend
> > to ram, and then unsuspended it, and it still wasn't accepting any
> > charge, even though the adapter indicated it was plugged in and
> > supplying power.  I then did a power cycle, and still the laptop
> > didn't indicate it was charging with a USB C 45W power supply plugged
> > in.
> 
> Just to be clear was this a Dell adapter or another manufacturer?
> 
> If it's non-Dell, there could easily be an untested combination of controllers
> and one getting into a bad state.

It was multiple non-Dell adapters --- but normally unplugging and
re-pluggin a USB C port *should* be enough to get the port back into a
sane state; a power down and unplugging the power should not be
required!  (A power down was not enough, and unplugging the power
supply and trying a different USB adapter was also not enough.)

Adapters which I tried included the Innergie 45W[1] (which does have
some USB Compliance issues), the original Google Universal Type C
Charger 60W[2], and BatPower ProE plus USB C adapter.  The last hasn't
gotten a USB C conformance review published, but I took that last one
to Benson Leung's lab and he tested it using his USB C analyzer.  The
ProE w/ USB C adapter passed with only one nit (apparently on
disconnection it didn't drop down below 5 volts fast enough to be
within spec; so if you unplugged it from a laptop and immediately
jammed it into a phone which only accepted 5V input, there might be
issues.  :-)

[1] https://gtrusted.com/review/innergie-powergear-usb-c-45
[2] https://gtrusted.com/review/the-microsoft-surface-book-2-charges-fine-with-the-google-universal-type-c-charger-60w-over-usb-power-delivery

The problem with the Dell XPS 13 not accepting power first showed up
while attached to the Google 60W USB power adapter.

Unfortunately, it's never happend again since in the past month, so
there's not much I can report.

> > I have noticed other problems where a USB C to HDMI adapter doesn't
> > quite work right (the laptop refuses to talk to the display), and the
> > *only* way to fix things is to powerdown Linux and then remove the
> > power plug.  
> 
> Is this with the DA200 or DA300?  Or something else?

It was with something else.  The problem stopped happening after I
stopped using a Dell Ultrasharp 30" monitor.  I've noticed that
Linux's drm support for that particular monitor has always been
marginal, and the problem would happen either when connecting to the
Dell Ultrasharp 30, or after it had been connected to the Dell
Ultrasharp 30 and going into work and connecting to a lesser Dell 24"
monitor (at $WORK they're too cheap to buy Ultrasharp's :-).  When I
upgraded my home display to be a 34" 4k display, this particular
problem went away.

The only thing that was interesting about it other than "random drm
bug; MST support in Linux marginal[1], film at 11" (I've been having
problems with the Dell Ultrasharp 30 connected from a Thinkpad Dock
ever since I got it), was that with the Dell XPS 13, it was the first
time where powering down *and* removing the power adapter made a
difference.   That was unique and surprising to me.

[1] https://www.youtube.com/watch?v=6301tGNs9Dc

I still have the Dell Ultrasharp 30", so I could try some experiments,
but since I'm not using it these days, it's been must less important
to me, since I'm not a DRM developer.  :-)   (And yes, it's possible
that the timing was a coincidence where it was something else, like
going to a newer kernel, not stopping the use of the Dell U30 that
made the key difference.  Give all of the Linux problems I've seen
with the Dell U30, over the past few years, I'm less convinced, but I
admit I haven't done a fully controlled experiment yet.)

> It sounds like this one might be more reproducible.  If it's a Dell
> peripheral I think it should be pretty easy for support to reproduce
> and escalate.

When I have time (probably after Vancouver at this point), I can drag
my Dell TB16 dock home, and try an experiment with the Dell XPS 13,
connecting to the Dell Ultrasharp via a TB16 dock.  And I can it with
a bleeding-edge kernel as well as the Debian 4.18.0-2 kernel.

Given that the Dell Ultrasharp 30 is an older monitor, it might be
less urgent to track this down, though.

Cheers,

					- Ted

P.S.  Linux support for 4k monitors are still marginal.  I very often
need to configure to 2560x1600/60Hz, and *then* reconfigure to
3840x2160 with a 59Hz refresh (that's important, usually it won't work
with 60Hz refresh).  And if the laptop display ever goes to sleep, I
need to repeat the "configure to 2560x1600, then reconfigure to
3840x2160@59Hz" dance.  These problems go away if I use an USB C /
HDMI adapter which only supports 4k @ 30Hz, but I want a faster
refresh rate than that.  :-)   (And yes, I've tried multiple USB C /
HDMI adapters; I have a whole collection.)

And this is something I can reproduce with a TB16 dock at work,
although I don't have a Dell 4k monitor, so I can't do a 100% Dell
repro on this particular 4k@60Hz (almost never works) / 4k@59Hz
(usually works, although I can't let the display sleep) exernal
monitor problem.  This particular problem does reproduce on a Acer 32"
4k screen at work, as well as LG 32" 4k monitor at home, though.

P.P.S.  Then there are the problems with using a TB16 at work, and
suspending, then going home and using a USB-C hub/adapter at home.
And after getting two TB16 for home use from Amazon, both of which
didn't work, although the TB16 at work did, I gave up with trying to
get a second TB16 for home use.  So normally I don't use the TB16 at
work, because things are much more stable if I don't use Thunderbolt
at all, unless I want to reboot after every commute.

Ah, life at the bleeding edge.  :-)

Re: A different PD controller firmware problem?

[Theodore Y. Ts'o]

On Thu, Nov 08, 2018 at 04:15:40PM -0500, Theodore Y. Ts'o wrote:
> On Thu, Nov 08, 2018 at 06:00:59PM +0000, Mario.Limonciello@dell.com wrote:
> > > Sortly after 12:30am US/Eastern, I got a low power warning on my
> > > system, and the battery power had dropped below 10%.  Apparently the
> > > laptop was not accepting any charge any more.  I tried doing a suspend
> > > to ram, and then unsuspended it, and it still wasn't accepting any
> > > charge, even though the adapter indicated it was plugged in and
> > > supplying power.  I then did a power cycle, and still the laptop
> > > didn't indicate it was charging with a USB C 45W power supply plugged
> > > in.
> > 
> > Just to be clear was this a Dell adapter or another manufacturer?
> > 
> > If it's non-Dell, there could easily be an untested combination of controllers
> > and one getting into a bad state.

It happened again, just now.  Unfortunately I didn't have a Dell
charger handy when it did, but it was the same symptoms.  One
interesting thing that I did discover is that by observing the voltage
being negotiated via USB-C PD, using a Satechi USB-C power monitor, I
discovered that when the laptop gets into this state, while the laptop
is suspended or powered off, it will negotiate to 5 volts at 3 amps
(assuming the power supply supports it).  So apparently the problem is
that the PD controller on the XPS 13 was refusing to negotiate any
other voltage *besides* 5 volts.  The fact that it could negotiate 3
amps means that it was doing USB-C PD negotiation; it was just doing
so... badly.

As before, the problem persisted across multiple USB-C power sources,
and I could switch between them so long as the laptop was booted into
Linux, suspended, or powered off but with a power supply attached.
The way the problem got fixed is by unplugging the power supply with
the laptop in a powered of state.  Apparently that (and only that)
will reset the problem in the EC or USB-C PD controller.

If there is something that I should try next time (other than trying
to use a Dell USB-C power supply; I'll start carrying it around in the
future), please let me know.  I couldn't find any obvious EC Logs that
I could download, unfortunately.

Firmware versions:

<tytso.root@cwcc> {/usr/projects/linux/ext4-fsverity}, level 2   (master)
1008# fwupdmgr get-devices
XPS 13 9370 System Firmware
  DeviceId:             8a21cacfb0a8d2b30c5ee9290eb71db021619f8b
  Guid:                 7ceaf7a8-0611-4480-9e30-64d8de420c7c
  Guid:                 43ea5588-d9a4-5031-8ad3-308045302d6b
  Guid:                 230c8b18-8d9b-53ec-838b-6cfc0383493a
  Plugin:               uefi
  Flags:                internal|updatable|require-ac|supported|registered|needs-reboot
  Version:              0.1.5.1
  VersionLowest:        0.1.5.1
  Icon:                 computer
  Created:              2018-11-10

KXG50ZNV1T02 NVMe TOSHIBA 1024GB
  DeviceId:             f954c7acdf5fab61aeaca1cd71d29ea5ade6992f
  Guid:                 4d0aed03-a30c-52c6-99e7-a8977797c3d9
  Guid:                 ad9fe8f7-cdc4-52c9-9fea-31b6f4988ffa
  Serial:               Y77S10C8TYAT
  Summary:              NVM Express Solid State Drive
  Plugin:               nvme
  Flags:                internal|updatable|require-ac|registered|needs-reboot
  Vendor:               Toshiba America Info Systems
  VendorId:             NVME:0x1179
  Version:              AADA4102
  Icon:                 drive-harddisk
  Created:              2018-11-10

XPS 13 9370 Thunderbolt Controller
  DeviceId:             8885ea984074c84d636e5458d6b6d12649df2e5d
  Guid:                 4eeb9d07-a96c-56d6-92d3-4a23ee7a6e4a
  Summary:              Unmatched performance for high-speed I/O
  Plugin:               thunderbolt
  Flags:                internal|updatable|supported|registered
  Vendor:               Dell
  VendorId:             TBT:0x00D4
  Version:              33.00
  Icon:                 computer
  Created:              2018-11-10