I’m working to set up hibernate on mine, but it would be nice to not have to even have to take the thought of “should I plug this in?” into account.
Hibernate takes longer to wake from, and I tend to use my laptop every few hours for just a few minutes. Hibernate is great for overnight but being able to just open the lid and use the computer is the entire point I have a laptop instead of just booting up my desktop. I only occasionally need USB/HDMI, but I still find value in the convenience of having them available.
Not having USB adapters compromises convenience when I do want to use USB (which I am currently doing).
Hibernate compromises wake times.
Sleep with adapters compromises battery life.
I think this is an elegant solution to phantom drain, for people who need the absolute max in battery life available. Might be my first mod to my F.w kit in fact…
1 Like
Alright I have made some progress on this and learned a lot.
I got breakout boards for a Type-C connector and Type-A receptacle and the concept seems to work so far. Connect the resistor to A5/CC and the device attached to the Type-A board enumerates in windows. Disconnect the resistor and it goes away. Logically I knew that this would work but I really wanted this proof.
Some things I learned:
- The silkscreen on my Type-C breakout board was meant for a receptacle and not the connector. By paying attention to the silkscreen instead of the pin location I got D+/- flipped and A5/A8 flipped.
- Everybody seems to agree that the wire colors for a USB2 cable are Red, Black, Green, and White. Looking at DIY USB cable guides not everybody uses the same mapping of Green/White to D+/D-.
- Because of the issues I was seeing, I cut an existing USB cable in half to solder to my Type-A receptacle breakout board. Whoever manufactured that cable did not agree with the convention that Red is for +5V and Black is for 0V.
It is late. I think my next steps will be:
- Re-soldering or insulating the connections because right now there is a high risk of shorts with how badly everything is connected.
- Verifying that when Rd isn’t connected that VBus isn’t powered.
- Check power consumption when Rd is and isn’t connected to make sure it is as I expect.
- Assuming everything above works well, start messing around with Kicad and trying to find components.
For anyone interested the relevant section of the USB Type-C Cable and Connector Specification is chapter “3.6.1 USB Type-C to USB 3.1 Standard-A Receptacle Adapter Assembly”
3 Likes
I’m surprised to read there is higher power draw for a Type A adapter vs Type C. I would have assumed the Type A had no circuitry or electrical components, and was only connecting the Type A socket pins to the corresponding Type C plug pins, so zero power draw as long as nothing is plugged in.
I assume I have misunderstood something?
The issue isn’t the Type A adapter itself consuming power even when nothing is connected, more it is an issue with how the CPU’s Type C controllers behave with the empty dongle/adapter.
The lowest TCSS power state is TCCOLD, which requires no device attached. A BIG part of how TCSS sees whether a device is attached or not is the Power Delivery communication over the CC pins. The PD chip on the board sees something connected to CC and it sends a message to the EC (I think) which then communicates with the CPU/PCH to inform TCSS that there is something connected and it needs to wake up. With a Type-C to Type-A empty adapter that PD communication still takes place so TCSS thinks that there IS, or at least COULD be a connection. In order to still work as the user expects (plug something into the empty dongle and it shows up) enough of TCSS needs to be awake to respond. The Phy needs to be powered, FIA needs to be powered, XHCI needs some power. I think that need for connection sensing on the USB3 pins prevents TCSS from being in TCCOLD and during sleep it is probably in TC7 which will consume more power.
13 Likes
Awesome explanation, and exactly matches my experience testing minimum idle draw configuration. Each USB-A expansion card plugged in increases battery consumption around .1 or .2 W, even with nothing in the USB-A slot. Not seeing the same increase in draw for USB-C expansion cards. Now I understand why. Thanks!
3 Likes
Thanks @Luke_Mahowald (I would have quoted your post but can’t see the option for that).
So the Type A adapters must not be electrically dumb as I would have assumed then, but must have enough circuitry to inform the USB-C controller that something is attached, and that circuitry draws enough power to cause this issue.
Maybe a USB-A socket does not have the right connections to do a full wake of TCSS via a USB-C port/controller when a device is plugged in, so the adapter has to provide some current draw to prep TCSS for a future USB A connection? (I’m theorising, I don’t know how they actually work)
@D.H I have seen more than 200mW variation in the average power consumption during sleep so without seeing your data and how consistent it is I can’t really guess. I hadn’t really considered the number of connected ports.
@Vectorspace I think we have a miscommunication. I would describe the Type-A adapter as being electrically dumb. Besides wires and physical connectors the only component would be a single 5.1 kΩ resistor connecting CC to ground. That resistor is the circuitry that informs the Power Delivery controller that there is a connection.
Within the Type-A adapter that resistor does consume power, but it is miniscule. If you want the details, check out the Type-C Cable and Connector specification sections 4.5.1.2.1 and 4.11.1. There are a couple of valid configurations but the most simple one is for the host to connect a voltage source to the CC pin using a pull up resistor and then look at the voltage at the CC pin to see if something (Rd to ground) is attached. Suppose the host is set up with a 5V voltage source and Rp value of 10 kΩ to CC. With our Rd of 5.1 kΩ, Rp and Rd together would consume about 1.7mW. This power consumption within the Type A adapter does not explain the 200+mW of power consumption that the system sees from the adapter being connected. The power is being consumed within the host.
Without something attached to the CC pin the data lines of the Type-C connector are not attached to any of the controllers within the USB4 subsystem. USB2 and USB3 both use their data pins to sense if there is a connection, so in order for the system to respond when a device is plugged into the Type-C to Type-A adapter something needs to be awake. What that something is and how much power that consumes is up to Intel.
1 Like
Thanks @Luke_Mahowald
No miscommunication, I think I was just using the terminology wrong. By electrically dumb, I meant no components that would draw current, just direct connections USB-C plug contacts to USB-A socket contacts. I realise now I uses the wrong term for that.
Meaning if you don’t need USB-A, then just remove it (if you need good battery life)…I guess. So, really, externalise USB-A from the unit…and that means just have a USB-A → USB-C adapter instead.
This also explains why other laptops with built-in USB-A and HDMI ports are able to do better with battery life…as they don’t need this on the TC.
Swappability at the cost of battery life.
But don’t leave that adapter plugged in, since it will (I expect) have the same power draw as the USB-A expansion card…
Yeah. Starting a collection of dongles.
I suppose since this thread is getting some attention I should give an update. Even though this idea (adapter with a switch to disconnect the CC pin to tell TCSS nothing is plugged in) is totally workable, I probably won’t pursue it further.
- Sourcing parts is hard. The adapter module format is small enough that many Type-A receptacles won’t work. Slim, mid-board mount Type-A receptacles exist but the last time I looked were hard to come by. Finding (and soldering) a SMD Type-C plug also isn’t trivial.
- Changed jobs and I don’t have the extra bandwidth.
- Not having Type-A ports all the time hasn’t ended up being that big of a problem.
Yeah, starting to see that the swappable expansion cards might be gimmicky to some people, and to others, has some use case specific benefits.
At the end, it’s just 4 USB-C ports from the mainboard…plus embedded dongle slots. Can’t even call it TB4 at this point.
Wait, wasn’t there a company that built laptops exclusively having 2 or 4 thunderbolt ports, and expect you to buy external dongles?
Is this behavior something that could possibly be overridden by the EC firmware? i.e. during deep sleep, can the EC FW ignore the CC communication from expansion cards to allow the system to enter TCCOLD?
I didn’t bother getting a HDMI as I have a USB C to HDMI cable.
I’ve seen a lot of weird wiring in my tinkering but this absolutely sent me.
I’m not sure if the EC actually controls this, might be under OS control already (through the USB controllers).
I had hoped that maybe USB-A ports would be shut down already on suspend, but I just tried suspending the laptop (default Ubuntu 22.04 suspend, no specific “deep” sleep configured), and then it keeps power on the USB-A port, so I guess it does not shut down the port completely.
I hate how “USB controllers” is now such an overloaded term now. I am not aware of any controllers that can influence the PD connection. Even TBT CLd which to TBT looks like a “disconnected” state with absolutely no activity on the high speed lanes still is connected from the PD perspective.
If you look at the EC FW on github, the function pd_task in common/usb_pd_protocol.c does a lot of handling of PD driven events, including handling CC changes. Which #defines are set does make an impact on the functionality.
The way I thought it worked was that events go from the PD to EC which then passes it on to the Type C subsystem. Maybe the EC FW could be modified to send TCSS a disconnect event but that is a lot of FW and dependencies to figure out.