Pogo pins power clarification - reading schematics

[dsimic]

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.

Thank you for the explanation, and my question was actually about the behavior of the official dock with a charger plugged into the dock.  In that case, the dock should act as a power source and its built-in USB devices should require no power from the phone at all.

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.)

Got it now, thanks, and I remember the battery drain bug.  In your opinion, can we expect revision 1.2c of the PCBA, which would include the missing pull-down resistor?  The new PCBA revision could also include a hardware fix for the backlight flicker I've proposed; I would really appreciate if we could discuss the proposed fix.

Quite frankly, I don't like the idea of having parts of the phone actually powered on while the phone is seemingly powered off (RTC is clearly an exception).  That's a dreaded feature already found in Android phones.

According to page 31 of the AXP803 datasheet, it should be possible to use software to turn off the IPSOUT (PS1 and PS2) power outputs entirely upon shutting down the A64 SoC.  According to pages 60, 61, 64 and 65, the states of the 30h and 3Ah registers of the PMIC and, consequently, the regular power sources for the IPSOUT pins, should be restored upon powering the phone on.

How about doing that to make the PinePhone really turned off when it's seemingly powered off?  As far as I can see, that should be a pretty straightforward addition to the axp20x_power_off() function in the Linux kernel driver source.

If requested by the OP, we could also fork this into a separate thread, but this discussion should still be somewhat related to the pogo pins.

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

Very nice; it's always surprising how much can be done in the device tree specification alone.   To reiterate another part of your response, this also applies to non-Type-C USB devices plugged into the phone, which use an appropriate cable that gets the ANX7688 involved in the handshaking process.

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

Would that mean than the peripherals attached to pogo pins would need to be defined in the device tree?  That would be rather difficult, but could be left to the work performed by the peripheral driver instead.

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.

Got it, thanks.  Basically, R1318 is a leftover from the development phase.

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.

Thank you very much for describing this.  To reiterate, the appropriate cable gets the ANX7688 involved in the handshaking process.

By the way, there seems to be a power negotiation issue when powering on the phone with no charger connected and connecting a "dumb" (USB BC-compliant) charger later, but I'll research it further before reporting back and proposing a fix.

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.

Got it, thanks, the confusion came from the way I interpreted your initial description.  Will there be a bugfix for the DTS file?

Phone -> USB C to A cable -> old "dumb" power brick -> AC wall outlet: Connecting the first time causes the phone to power on. But I can power the phone off from software, and then it stays "off".

Phone -> convergence dock -> USB C to a cable -> old "dumb" power brick -> AC wall outlet: Connecting the first time causes the phone to power on. After powering off the phone from software,
the phone powers back on; won't stay "off".

(If anyone wants to talk about more about this aspect, unless it's related to pogo pins, please consider taking it to a new thread)

As requested, I've created another, separate thread for the discussion about the power sources powering on the phone.  However, it is still somewhat related to the pogo pins, because one of the functions of the pogo pins is to provide power to the phone.