Power Management w/ MityARM

Added by Ali Asgar Sohanghpurwala about 12 years ago


We're trying to figure out how to utilized MityARM's power management capabilities in our design and this is hard to do without knowing how the AM3359<->PMIC connections operate. I've scoured the datasheets/design guides for TPS65910, AM335x, and MityARM and am still unsure of how this works.

My main confusion is in how the TPS65910 and AM3359 interface and coordinate with each other.

Figure 13 on page 42 of the TPS65910 datasheet shows a state machine that explains how the PMIC device itself transitions based on the various inputs to the system (supply voltage changes, power button, PMIC_SLEEP, etc.). Are these changes in state communicated to the AM3359 over the I2C link? For exampled if PMIC_SLEEP is activated and the PMIC goes into "SLEEP" mode, does the Cortex also go into sleep mode? Or if the power button is pressed while the system is active does the PMIC send a shutdown signal over I2C or does it simply cut power to the AM3359?

Similarly Section of the AM335x Technical User's Guide explains the different AM3359 power modes and domains but doesn't really explain explain what if any communication occurs with the PMIC. From my understanding ALL modes except RTC-Only require all power supplies from the PMIC to be maintained. When Linux halts does the SoC go into RTC-only mode? Does it communicate anything to the PMIC? Does it toggle PMIC_ENABLE pin to turn off any PMIC supplies? What is the PMIC_ENABLE from the AM3359 connected to on the MityARM. I tried to poke around the kernel shutdown process, omap2 platform code and tps driver, but what happens on shutdown is still unclear to me.

I also noticed that both the PMIC and AM3359 have RTC modules, which one is used by your Linux Kernel?

Part of our problem is that we want the MityARM to control our DC power supply via remote on/off pin. On shutdown we need the MityARM to perform some housekeeping duties, shut itself down, and turn off the PSU output via GPIO or other signal(other boards in the system do not have power management capabilities). We need to support both local and remote startup/shutdown (ideally over ethernet).

Our current design has no standby power other than the backup battery. There is a relay-based circuit that enables PSU power if the PWR_SW is pressed momentarily and turns off PSU output if a GPIO pin is driven low or a seperate "force power off" switch is pressed. My main concern with this setup is that depending on the Linux shutdown order the MityARM could cut it's own power in the middle of the shutdown process. It might either complete shutting down using backup battery power, or it might just cut off based on the PMIC supply rules.

We're not sure the above solution will work, so we're trying to power the MityARM with always-on standby power. The controllable PSU output will power everything else in the box. Assuming that standby power is enough to run the MityARM, this should allow us to remove the relay circuit and simply connect the power switch to the PWR_ON input. From there a Linux halt initiated via power button or software (possibly via ethernet command) should be a "soft-shutdown" that performs housekeeping (including turning off external PSU), halts cpu, and enters RTC-only mode. From this mode either activating the EXT_WAKEUP or PWR_ON signals should power on the MityARM into active mode. Does this seem reasonable?

Finally we might need something resembling Wake on Lan operation. It doesn't seem like the AM3359 MAC supports true Wake on Lan so we were thinking of powering the ethernet PHY from standby power and hooking up one of the Ethernet PHY signals to the EXT_WAKEUP pins. Have you guys implemented remote power up on the devkit board?

Thanks in advance for your assistance, any insight you can provide on this matter would help us finish up our schematic design and layout.


Replies (6)

RE: Power Management w/ MityARM - Added by Ali Asgar Sohanghpurwala about 12 years ago

Sure enough after posting this I found the User's Guide for using TPS65910 with AM335x:

Can I assume that this is how the PMIC is hooked up on the MityARM?

If so this is how I understand the PM system on the MityARM to work (correct me if I'm wrong):

Power should always be applied to PMIC power inputs

Two possible power on (from full off or RTC only state) events:
1. Power Button press is detected by PMIC->turns on power banks and processor boots up
a. Power-on RST pin on AM3359 is activated by NRESPPWRON from PMIC
2. EXT_WAKEUP pin on AM3359 is activated and AM3359 PMIC_ENABLE pin is connected to PWRHOLD pin on PMIC starts power-on sequence

While processor is active PMIC can activate the following interrupts over I2C:
1. Power button was pressed (activates shutdown on processor)
2. Power button held for 6 seconds (it interrupt not acknowledged within 2 seconds, PMIC is powered down)
3. overtemp, low voltage, gpio, and RTC alarm interrupts, not sure how these are handled

When Linux shutdown is initiated (either via power button or halt command):
1. Linux goes through normal shutdown process
2. CPU Halts and PMIC_ENABLE is turned off (I think, not confirmed yet) which sets PMCI to OFF/RTCONLY mode

Wakeup from full OFF state can only be done via power button/EXT_WAKEUP pin.

Wakeup from sleep can be done from any WAKEUP power domain pins.

Now the above is how I think the system should work based on the documentation and from poking around the Linux source. A couple things I want to confirm:
1. Power button fires I2C sourced interrupt on AM3359, does kernel interpret this as a shutdown/halt signal?
2. When the CPU halts is PMIC_ENABLE deactivated?
3. Still not sure what is the best way to activate EXT_WAKEUP for remote power on over ethernet

RE: Power Management w/ MityARM - Added by Michael Williamson about 12 years ago

Hi Ali,

Sorry for the delay in response, you have a lot of questions wrapped up in these two posts, and we haven't gone through all the power management states here (we've been focused on basic interface functionality up until now, the product is still fairly new here).

We used the User's Guide as general guidance for connecting the TPS65910 to the AM335x.

We are feeding the 32Khz clock to the PMIC directly, not the AM3359. The PMIC CLK32OUT is routed to the RTC_XTALIN signal on the AM3359. There are pads in place to move the crystal over to the AM3359 if this turns out to be a problem.

I2C1 is connected to SR SCL/SDA port.
I2C2 is connected to the standard SCL/SDA port.

NRESETPWRON of the PMIC is connected to the 3359 PWRONRSTN control line.
PWR_ON of the PMIC is connected to the edge connector of the SOM.
PWRHOLD on the PMIC is connected to PMIC_POWER_EN on the 3359.
EXT_WAKEUP on the 3359 is connected to the edge connector.

I don't have confident answers for your 3 questions at the end of your last post until I sit down and measure the device.


RE: Power Management w/ MityARM - Added by Ali Asgar Sohanghpurwala about 12 years ago


Thanks for your response, it is really helpful to know how the PMIC is connected. I posted a question about how the tsp65910 Linux driver handles interrupts on the TI E2E forums and got a response from TI:

So to answer Question 1 of my second post, an I2C interrupt fires when the power button is pressed but there currently isn't a handler registered to do anything with it. So it sounds like in our case we will want to write our own driver to acknowledge the interrupt, perform housekeeping, and then issue Linux halt/poweroff command.

I haven't been able to find any more information about the PMIC_PWR_ENABLE other than what is listed in the TRM about being able to turn it off via ALARM2. So 2 and 3 are still open questions for us; I might post something in the TI E2E forums about them.


RE: Power Management w/ MityARM - Added by Ali Asgar Sohanghpurwala about 12 years ago

Hey Mike,

I've started playing with writing a "pwrbutton" driver for the TP65910 and am making some progress. We've soldered a momentary switch to PWR_ON/GND and a jumper from PMIC_INT_N to a GPIO and I can source tps65910 interrupts after some minor modifications to drivers/mfd/tps65910-irq.c.

There are a couple issues I have with the default EEPROM configuration:

The PMIC_INT_N signal name implies an active-low signal, but the default EEPROM configuration seems to configure this as active high. The signal remains pulled to ground until I manually clear the IT_POL bit in the DEVCTRL2 register.

We might want to have our MityARM stay off until the power button is pressed, for this to happen we need to change default value of VMBHI_IT_MSK bit in the INT_MSK register.

Is there any way to program the EEPROM defaults in-system over I2C or is this burned into the TPS65910 before being mounted on the MityARM?


RE: Power Management w/ MityARM - Added by Michael Williamson about 12 years ago

Hi Ali,

Unfortunately, the EEPROM settings in the TPS65910 are programmed in by TI prior to installation on the MityARM.

I don't think the EEPROM is programmable once it leaves TI's factory, you have to use the settings they "tuned" for the processor the PMIC was targeted for. You can double check with TI on this, but I think it's their policy to not expose the EEPROM programming capability once it leaves their factory.

Of course, if you are going to be a couple hundred thousand units, they might be willing to make a "new" part number with you desired settings. Until then I think you'll have to come up long enough to flip the bit and shut everything back down (perhaps you could modify the boot loader or first stage boot code to sort this out?).

Not sure if there's much more you can do, but let me stew on it...


RE: Power Management w/ MityARM - Added by Ali Asgar Sohanghpurwala about 12 years ago

Interesting, I thought you guys had customized it because I had interpreted from the TPS65910/AM335X User's Guide that default behavior was to stay powered off unless a startup reason was given. has the following information:
Register: INT_MSK_REG
0 = Device automatically switches on at NO_SUPPLY-to-OFF or BACKUP-to-OFF transition.
1 = Start-up reason is required before switch-on.
Default: 1

I had interpreted that to mean that the device would only turn on if power button was pressed. However, looking at the page 42 in it looks like maybe the AM3359 asserting PWRHOLD is a potential "Start-up reason" along with VMBHI and PWR_ON.

The User Guide also indicates that TPS65910 EEPROM for AM3359 defaults to Active-high PMIC interrupt so you might want to change MityARM documentation to indicate that PMIC_INT_N is active high.

Thanks for the fast response as usual.


    Go to top
    Add picture from clipboard (Maximum size: 1 GB)