PinePhone Power Management - Revision history

Dsimic: Alright; Avoid extra whitespace

2021-04-26T14:57:20Z

Alright; Avoid extra whitespace

← Older revision		Revision as of 14:57, 26 April 2021
Line 194:		Line 194:

	# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).		# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).

	-->		-->

	=== Assignments after Suggested Changes ===		=== Assignments after Suggested Changes ===

Fxc: Undo revision 9430 by Dsimic (talk)commenting out done by the devs, exposing it would alter the meaning

2021-04-26T13:14:48Z

Undo revision 9430 by Dsimic (talk)commenting out done by the devs, exposing it would alter the meaning

← Older revision		Revision as of 13:14, 26 April 2021
Line 191:		Line 191:
	# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in		# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in

	==== Sensors ====		<!--==== Sensors ====

	# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).		# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).
			-->

	=== Assignments after Suggested Changes ===		=== Assignments after Suggested Changes ===

Dsimic: /* Suggested Regulator Hardware Changes */ Let it be seen

2021-03-11T20:22:35Z

Suggested Regulator Hardware Changes: Let it be seen

← Older revision		Revision as of 20:22, 11 March 2021
Line 191:		Line 191:
	# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in		# DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in

	~~<!--~~==== Sensors ====		==== Sensors ====

	# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).		# This may or may not be a good idea, so it's a very weak suggestion: Swap the VDD and LEDA inputs of the STK3311-A sensor, moving VDD to DLDO1 and LEDA to GPIO0-LDO. The sensor VDD needs to match the I2C voltage, and the LED driver should be on a separate power supply from the sensors. There is some concern, because GPIO0-LDO has a 100mA limit, but the proximity sensor should work properly at the lowest LED drive current (12.5mA).
	~~-->~~

	=== Assignments after Suggested Changes ===		=== Assignments after Suggested Changes ===

Fxc: Fxc moved page PinePhone/Power Management to PinePhone Power Management: Naming style

2020-10-21T12:18:24Z

Fxc moved page PinePhone/Power Management to PinePhone Power Management: Naming style

← Older revision

Revision as of 12:18, 21 October 2020

Abcde: added categories

2020-10-17T19:36:44Z

added categories

← Older revision		Revision as of 19:36, 17 October 2020
Line 442:		Line 442:
	* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?		* What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1?
	* Currently STATUS pin is connected to PWRKEY and to PB3. STATUS can't be read reliably since voltage divider from R1526 and R1517 places the STATUS signal at 0V or 0.5Vcc-IO, which is unspecified input value according to A64 datasheet (Vih is 0.7Vcc-IO, Vil is 0.3*Vcc-IO, the range in between is unspecified).		* Currently STATUS pin is connected to PWRKEY and to PB3. STATUS can't be read reliably since voltage divider from R1526 and R1517 places the STATUS signal at 0V or 0.5Vcc-IO, which is unspecified input value according to A64 datasheet (Vih is 0.7Vcc-IO, Vil is 0.3*Vcc-IO, the range in between is unspecified).

			[[Category:PinePhone]] [[Category:Allwinner A64]]

Smaeul: /* Regulators */

2020-03-14T20:02:33Z

Regulators

@@ Line 246: / Line 246: @@
 * If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent?
 ** Looks like this is N/A, because DLDO2 should be 1.8V.
 == GPIO ==

Smaeul: /* Suggested GPIO Hardware Changes */

2020-03-01T19:53:24Z

Suggested GPIO Hardware Changes

← Older revision		Revision as of 19:53, 1 March 2020
Line 442:		Line 442:
	# <strike>Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere.</strike>		# <strike>Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere.</strike>
	# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).		# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).
	## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.		## <strike>Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.</strike>
	## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.		## Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level.
	## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.		## <strike>Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.</strike>
	# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)		# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)
	# <strike>Remove the transistors inverting <tt>VCONN1_EN</tt> and <tt>VCONN2_EN</tt>, and use a pull-up to <tt>DVDD1V8</tt> (that is really already present) instead of the pull-up to <tt>3V3</tt>.</strike>		# <strike>Remove the transistors inverting <tt>VCONN1_EN</tt> and <tt>VCONN2_EN</tt>, and use a pull-up to <tt>DVDD1V8</tt> (that is really already present) instead of the pull-up to <tt>3V3</tt>.</strike>

Smaeul: /* ANX7688 */

2020-03-01T19:52:56Z

ANX7688

← Older revision		Revision as of 19:52, 1 March 2020
Line 180:		Line 180:
	==== ANX7688 ====		==== ANX7688 ====

	# Move ANX7688 AVDD33 (the chip input only, not the other things connected to 3v3) and ANX7688 I2C Level Shift (3.3V side) from DLD01 to DCDC1		# Move ANX7688 AVDD33 (the chip input only, not the other things connected to 3v3) and ANX7688 I2C Level Shift (3.3V side) from DLD01 to DCDC1, and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to ANX1.8V
	# Move ANX7688 ~~DVDD1V8 (the chip input only, not the other things labeled DVDD1V8)~~ from GPIO1-LDO to ALDO2		# <strike>Move ANX7688 ANX1.8V from GPIO1-LDO to ALDO2</strike>
	# Move ANX7688 ANX-V1.0 Regulator Enable (R1352~~) and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366~~) from DLDO1 to ~~GPIO1-LDO~~		# Move ANX7688 ANX-V1.0 Regulator Enable (R1352) from DLDO1 to a GPIO

	These are all medium priority.		These are all medium priority.

Smaeul: /* Suggested GPIO Hardware Changes */

2020-03-01T06:48:23Z

Suggested GPIO Hardware Changes

Smaeul: /* Suggested GPIO Hardware Changes */

2020-02-24T03:43:15Z

Suggested GPIO Hardware Changes

← Older revision		Revision as of 03:43, 24 February 2020
Line 437:		Line 437:
	# Swap <tt>DTR</tt> (was at PL6, now at PB2 with level shift) and <tt>RI</tt> (was at PB2, now at PL6 with '''no level shift''', but a pull-up to ALDO2 on the A64 side*). ''partly a bugfix''		# Swap <tt>DTR</tt> (was at PL6, now at PB2 with level shift) and <tt>RI</tt> (was at PB2, now at PL6 with '''no level shift''', but a pull-up to ALDO2 on the A64 side*). ''partly a bugfix''
	# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''		# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''
	# Connect the modem <tt>STATUS</tt> to an A64 GPIO input (any 3.3V pin bank is fine; this can reuse the level shifter previously connected to PL6). This needs a pull-up ~~to VDD_EXT~~ on the ~~modem~~ side. ''bugfix''		# Connect the modem <tt>STATUS</tt> to an A64 GPIO input (any 3.3V pin bank is fine; this can reuse the level shifter previously connected to PL6). This needs a pull-up on the A64 side. ''bugfix''
	# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).		# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).
	# Connect the modem debug UART TX/RX to PD0-1.		# Connect the modem debug UART TX/RX to PD0-1.

← Older revision		Revision as of 06:48, 1 March 2020
Line 434:		Line 434:
	# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''		# Connect the LIS3MDL <tt>DRDY</tt> pin, not <tt>INT</tt> pin, to PB1. ''bugfix''
	# Reconnect <tt>LINEOUTN</tt> to make the line output differential.		# Reconnect <tt>LINEOUTN</tt> to make the line output differential.
	# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. ~~I think~~ this ~~needs a~~ pull-up ~~to VDD_EXT~~ on the modem side.		# Connect PH7 to <tt>AP_READY</tt> instead of <tt>WAKEUP_IN</tt>. Since the A64 needs to drive this pin high (no pull-up on the modem side), this uses the level shifter channel previously used by RI (U1503 channel 4).
	# Swap <tt>DTR</tt> (was at PL6, now at PB2 with level shift) and <tt>RI</tt> (was at PB2, now at PL6 with '''no level shift''', but a pull-up to ALDO2 on the A64 side*). ''partly a bugfix''		# Swap <tt>DTR</tt> (was at PL6, now at PB2 with U1503 channel 3 level shift) and <tt>RI</tt> (was at PB2, now at PL6 with '''no level shift''', but a pull-up to ALDO2 on the A64 side*). ''partly a bugfix''
	# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''		# Connect the modem <tt>PWRKEY</tt> to PB3 only, not <tt>STATUS</tt> or DCDC1 (depopulate R1526). ''bugfix''
	# Connect the modem <tt>STATUS</tt> to ~~an A64 GPIO input (any 3~~.~~3V pin bank~~ is ~~fine; this can reuse the level shifter previously connected to PL6). This~~ needs a pull-up on the A64 side. ''bugfix''		# Connect the modem <tt>STATUS</tt> to PH9. This is an open-drain signal, so it needs a pull-up on the A64 side. ''bugfix''
	# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).		# Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART).
	# Connect the modem debug UART TX/RX to PD0-1.		# <strike>Connect the modem debug UART TX/RX to PD0-1.</strike>
	# Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere.		# <strike>Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere.</strike>
	# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).		# Connect both AXP803 <tt>USB-DRVVBUS</tt> (populate R1300) and ANX7688 <tt>VBUS_CTRL</tt> to <tt>DRVVBUS</tt> (in addition to PD6).
	## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.		## Connecting to ANX7688 <tt>VBUS_CTRL</tt> would need a level shift to 1.8V.
Line 446:		Line 446:
	## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.		## Alternatively, do not connect ANX7688 <tt>VBUS_CTRL</tt>, and at least populate R1300 to connect AXP803 <tt>USB-DRVVBUS</tt>.
	# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)		# Reorient the transistors for <tt>ANX_POWER</tt> (PD10) and <tt>ANX_RESET</tt> (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.)
	# Remove the transistors inverting <tt>VCONN1_EN</tt> and <tt>VCONN2_EN</tt>, and use a pull-up to <tt>DVDD1V8</tt> (that is really already present) instead of the pull-up to <tt>3V3</tt>.		# <strike>Remove the transistors inverting <tt>VCONN1_EN</tt> and <tt>VCONN2_EN</tt>, and use a pull-up to <tt>DVDD1V8</tt> (that is really already present) instead of the pull-up to <tt>3V3</tt>.</strike>

	'''Note:'''		'''Note:'''
	Changes 1-7 and 11 are high priority.		Changes 1-7 and 11 are high priority.
	Changes 12-13 are medium priority.		Changes 12-13 are medium priority.
	Changes 6-10 are low priority.		Changes 8-10 are low priority.

	* There should be at least one pin where the default value at boot changes, due to being pulled differently, for use in distinguishing the hardware revisions. In v1.1, PL6 reads 0 at boot. Since RI is an active-low interrupt, it needs a pull up. And it doesn't need any level translation. So that's our perfect opportunity. If PL6 reads low at boot, it's a v1.1 device; if PL6 reads high at boot, it's a v1.2 device.		* There should be at least one pin where the default value at boot changes, due to being pulled differently, for use in distinguishing the hardware revisions. In v1.1, PL6 reads 0 at boot. Since RI is an active-low interrupt, it needs a pull up. And it doesn't need any level translation. So that's our perfect opportunity. If PL6 reads low at boot, it's a v1.1 device; if PL6 reads high at boot, it's a v1.2 device.