Pogo pins power clarification - reading schematics

[smaeul]

Yes, DCIN is bidirectional, so the phone can be either a power sink (drawing from PIN1 or from the Type-C port) or a power source. And the A64 can be either a USB OTG host or a device. With USB Type-C power delivery negotiation, those two choices are decoupled. That is why you can charge the phone through the convergence dock, while simultaneously using the dock as a USB hub.

I would suppose that one part of the official dock presents itself to the phone as a self-powered USB 2.0 hub?  As such, does the dock actually draw any power from the phone, when a charger is plugged into the dock?  I assume not, because that would turn DCIN into being simultaneously a power input and a power output.

Also, AFAIK self-powered USB hubs may draw some power from the upstream USB port, but they actually don't have to.

The important distinction is between USB PD power sources and power sinks. A hub being "self-powered" vs "bus-powered" isn't really meaningful here, since both of those can still be power sinks. USB PD is rather complicated, but the short version is the initial power "source" end is also the data "host" end, and either power or data swap directions as needed.

So the answer is "sometimes". If you plug in the dock while not charging, the phone will be the power source. If you then plug a charger into the dock, the dock will request to swap power roles with the phone, but until that happens, the phone is still a power source. Similarly, if you first plug the charger into the dock, and then plug the phone in, the phone will be a power sink and data "device", and the phone has to request a data role swap to become the host.

One important piece I have not seen mentioned so far: there is a control loop (implemented fully in hardware in v1.2) that prevents DCIN from being both a power input and output at the same time.

1. DCIN is an input by default, due to the pull-down resistor R1301 on the LPW5206 enable pin. (the LP6226 enable pin should have a pull-down too, oops!)

It seems that it could be fixed in the PinePhone DTS file?  If I'm not wrong, there's an internal pull-down resistor on the PD8 (V17) pin of the A64.

Unfortunately that doesn't help. The reason I suggest a pull-down is to keep the LP6226 off while the A64 is completely powered down. In that case, the A64's GPIO pins are all deconfigured.

(When you shut down Linux/the A64, the two power rails that stay on are PS and VCC-RTC. So anything powered by PS should be considered "always on". This was the source of the battery drain bug in v1.1: there was no way to turn off U1301, the regulator supplying the ANX7688.)

2. The ANX7688 measures the DCIN voltage through the divider at VBUS_DIV8.
3. When a USB cable is plugged in, the ANX7688 determines the phone's power role by negotiating over CC1/CC2 and by using the measured DCIN voltage.
4. If it decides the phone should be a power source (making DCIN an output), it drives VBUS_CTRL high. This does two things (see the bottom of page 13 of the schematics):
- It enables the LPW5206, allowing current to flow from USB-5V to DCIN.
- This is the key here! It drives N_VBUSEN on the AXP803 high. This is an input pin which disconnects VBUS/ACIN1/ACIN2 from PS. In other words, it forces the PMIC to ignore the VBUS voltage and only draw power from the battery.
5. If the USB device wants to switch power roles, it must first renegotiate with the ANX7688, which will drive VBUS_CTRL low at the proper time to switch DCIN back to being an input.
6. As soon as the USB cable is unplugged, the ANX7688 chip is powered off. VBUS_CTRL goes Hi-Z, R1301 pulls DRVVBUS and N_VBUSEN back low, and DCIN goes back to being an input.

Thank you very much for this description!  We have been pretty much ingnoring the ANX7688 so far, and it ties a lot together.

As a note, this entire protection mechanism obviously applies to Type-C USB devices only, but it cannot apply to non-Type-C USB devices.  However, the PMIC should be able to handle different types of non-Type-C USB devices on its own; I'll have a related question later in my response, which should clarify this.

Also, what actually ensures that the LP6226 is enabled, which provides "boosted" 5 V at USB-5V, when DCIN works as power output?  The LP6226 should be disabled by default.

The ANX7688 driver in Linux: https://megous.com/git/linux/tree/arch/a...1-1956#n84

A pogo pin peripheral could reference the regulator in a similar way.

PIN5/USB-5V: This pin should only be used to draw power from the phone. It should not be used to provide power to the phone. In fact, starting with mainboard v1.2, it cannot power the phone, due to the control loop described above. If you drive DRVVBUS high to connect PIN5 to DCIN, you are also telling the PMIC to ignore any power it is receiving from DCIN!

Could you, please, shed some light on why is R1318 currently NC?  I.e. what (presumably) was the use of PL9-DRVVBUS on the A64 as the way for letting software know that USB-5V is powering DCIN?  Or, was it the way for software to disable the LPW5206, as part of the control mechanism in software?

I added the circuit in v1.2, but at that point we had no way to test that VBUS_CTRL worked like we expected. I kept the GPIO connection as a fallback so N_VBUSEN could be driven by the A64 if needed, and so we could monitor VBUS_CTRL from the A64. However, I made a mistake: VBUS_CTRL is a 3.3V output. That's fine for the PMIC, where N_VBUSEN is tolerant up to PS+0.3V. However, the PinePhone is designed with a 1.8V I/O on Port L. So VBUS_CTRL would over-drive the other pins on Port L, messing up the backlight brightness -- fixing that is why R1318 was made NC in v1.2b.

Also, could you please provide an insight into what actually happens to the above-described control mechanism when a non-Type-C USB device is plugged into the phone?  Does the PMIC handle everything by itself?  However, if I'm not wrong, the N_VBUSEN pin on the PMIC cannot be an input and an ouput at the same time, which would be required for the PMIC to provide the protection on its own?

If a non-PD-capable USB device is plugged in, the phone will always be a power sink (e.g. male A to C cable), or always be a power source (e.g. C to female A cable), depending on the marker resistor inside the cable. It's not possible to plug in a "non-Type-C" device. Type-C cables without a marker resistor are not USB compliant. So the ANX7688 always knows which direction the current is supposed to flow.

The PMIC does connect to the D+ and D- lines to do USB BC current limit negotiation for A-to-C charging, but that is unrelated to source/sink direction.

Turning off the LP6226 doesn't actually disable USB-5V! Thanks! You found an error in the device tree description. We should be using a GPIO-controlled regulator (i.e. where the GPIO controls the voltage), not a fixed-voltage regulator with a GPIO enable input.

Quite frankly, this is rather confusing.   When the LP6226 is disabled by its EN pin, USB-5V is just not "boosted" to 5 V and equals to PS minus a certain voltage drop, by having the current going from PS, through L606 and D600, and out of USB-5V.  What's the actual relation with the PinePhone DTS file you've referred to?

Simply that the DTS is not accurately representing the hardware. The DTS claims the GPIO is an on/off switch, when it is really a high/low voltage switch. And this leads the driver to use the wrong API to manipulate it. However, the end result is the same: the GPIO is driven high when we are providing power to the Type-C port, and driven low otherwise.