Pogo pins power clarification - reading schematics
03-13-2021, 05:40 PM
Hello, I am seeing this forum thread (linked from the wiki) for the first time, and there's a lot of information in it, so I'm not going to try to use quotes.
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.
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.
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.)
Now, about the pogo pins.
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.
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!
I don't think the fact that PIN5 can be anywhere from VBAT to 5 V is a problem. Providing a dedicated 3.3 V regulator inside the phone would add to the BOM cost, it would decrease the power efficiency for peripherals with a supply voltage below 3.3 V (but with 3.3 V tolerant I/O for I2C), and it would create a hard limit on the supply current. Putting the regulator in the peripheral provides more freedom to choose the right one.
To answer a couple of other questions:
Why did the phone not charge when connected to the variable power supply? One reason is that the PMIC has a minimum voltage, VHOLD, below which it will not charge. On megi's kernels, this is set to 4.5 V. From the datasheet: "VBUS VHOLD is set as max of VBAT+0.15V or 30H[5:3]".
Why would we disable the LP6226 unless using DCIN as an output? That is simple: we do not want to waste battery power by running the boost converter unless it is needed. As mentioned, any peripheral drawing power from PIN5 should be down-regulating it to 3.3 V anyway, so it should not care if the LP6226 is enabled or not. If it does need a 5 V supply, software on the A64 side can request to turn on the boost converter.
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.
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.
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.
- 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!)
- The ANX7688 measures the DCIN voltage through the divider at VBUS_DIV8.
- 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.
- 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.
- It enables the LPW5206, allowing current to flow from USB-5V to DCIN.
- 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.
- 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.
- ANX7688 interrupts the A64 and tells it over I2C if it should be a power source or sink.
- The A64 uses PD6 to turn the LPW5206 on or off.
- The A64 sets REG30[2] inside the PMIC to enable or disable the VBUS to PS path.
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.)
Now, about the pogo pins.
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.
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!
I don't think the fact that PIN5 can be anywhere from VBAT to 5 V is a problem. Providing a dedicated 3.3 V regulator inside the phone would add to the BOM cost, it would decrease the power efficiency for peripherals with a supply voltage below 3.3 V (but with 3.3 V tolerant I/O for I2C), and it would create a hard limit on the supply current. Putting the regulator in the peripheral provides more freedom to choose the right one.
To answer a couple of other questions:
Why did the phone not charge when connected to the variable power supply? One reason is that the PMIC has a minimum voltage, VHOLD, below which it will not charge. On megi's kernels, this is set to 4.5 V. From the datasheet: "VBUS VHOLD is set as max of VBAT+0.15V or 30H[5:3]".
Why would we disable the LP6226 unless using DCIN as an output? That is simple: we do not want to waste battery power by running the boost converter unless it is needed. As mentioned, any peripheral drawing power from PIN5 should be down-regulating it to 3.3 V anyway, so it should not care if the LP6226 is enabled or not. If it does need a 5 V supply, software on the A64 side can request to turn on the boost converter.
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.
