Pogo pins power clarification - reading schematics

[dsimic]

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.

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.

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.

If you want to play with this VBUS-to-PS path, there is a second, independent way it can be disabled: REG30[7] in the PMIC, which is mapped by the Linux driver to /sys/class/power_supply/axp20x-usb/online. Writing 0 to this file disables the DCIN/VBUS input, so you can see what PIN5 does when PS is driven by battery only. (Note: this bit gets reset when DCIN/VBUS stops being supplied with voltage.)

Again, thank you very much for this description!

PIN1/DCIN: This pin can be used to provide power to the phone, or to draw power directly from the USB Type-C port (if you only want your peripheral to work while the phone is plugged in). Yes, there is a concern if both PIN1 and the USB port are used as power inputs at the same time. Any peripheral that wants to supply power to PIN1 will need voltage sensing or I2C handshaking to detect when a USB charger is plugged in and stop providing power.

This is exactly one part the "handshaking" I've predicted to be necessary for the recently announced PinePhone keyboard case.

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?

Also, could you please provide an insigh 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?

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?

- USB-5V seems like it should always be 5V if PS-5V is enabled and if it has some other voltage when PS-5V is disabled, it's only because there's some remaining charge on the capacitors, or some current going in the reverse direction via U1302 via internal N-MOSFET body diode (see https://megous.com/dl/tmp/06d11858b841c503.png - there's a parasitic diode between S-D in that direction) You're not supposed to rely on USB-5V in this case, when PS-5V is off (another diode on the PS-5V output prevents backfeeding of power through PS-5V)

I believe DC from PS is always allowed to pass through L606 and D600 and charge C645/C646 to the PS voltage. It is only when you want to charge the capacitors to a higher voltage that you need U601 pumping charge out its LX pin. (And in that case, L606 prevents the high-frequency charge pulses from backfeeding into PS.)

It may still be possible for current to flow backward through U1302: if DCIN is at 5V, but PS is at VBAT due to disabling the VBUS path with the sysfs knob mentioned above. It would be interesting to try that and measure the voltage at PIN5.

Earlier experimental measurements (as explained further by @bokomaru in their latest post) performed on the pogo pins confirm that, with the LP6226 (U601) disabled, current may freely go from PS, through L606 and D600, and out of USB-5V.  That's also why a Schottky diode has been selected for D600, for its low forward voltage drop, despite being a "plain" diode in the reference LP6226 design.

Obviously, D600 prevents the current flowing back from USB-5V to PS.  We may safely disregard the case of reaching the breakdown voltage of D600.