Apply this patch:
From 51b4d415971bb052a26938791337d1050bf94748 Mon Sep 17 00:00:00 2001
Yeah I recognize that code from source code not written by TI employees. The file is called tps65217_charger.c, and is written by an employee of another company.
Anyway, I think we’re going to blow this off. The idea was to wait around without power for 5 minutes, to see if power comes back up. Before issuing a shutdown. Then, on the power up end, using a simple R/C circuit to ramp up voltage to 5v over a specific time period.
By the way, my local source tree is already patched with Robert’s BBB patches.
The real reason why our source trees do not match up. My source tree is based on 4.1.x, and yours seems to be 3.8.x. The patch you showed above would probably botch up my source tree . . .
Say you want to use the mcasp0 interface but you don't want to use all
the pins
P9_25 GPIO3_21 Allocated mcasp0_pins AUDIO DIGITAL IN
P9_28 SPI1_CS0 Allocated mcasp0_pins AUDIO DIGITAL OUT
P9_29 SPI1_D0 Allocated mcasp0_pins AUDIO FSK
P9_31 SPI1_SCLK Allocated mcasp0_pins AUDIO B CLOCK
Can these pins be used for GPIO if you set up the pinmux correctly?
P9_27 GPIO3_19 Allocated mcasp0_pins
P9_30 SPI1_D1 Allocated mcasp0_pins
P9_42 GPIO3_18 Allocated mcasp0_pins
Nope, mine is based on 4.1. This patch was adapted by Robert from code that was written for 3.8.
Regards,
John
Yep, it is in the BB kernel:
So again, on line 164 is the Interrupt routing. It is this line:
- input_report_key(tps->pwr_but, KEY_POWER, |
- |
- ~status_reg & TPS65217_STATUS_ACPWR); |
that send a power button pressed as an input key when the AC 5V power is removed.
Regards,
John
Sorry, that should have read line 75 in the patch file, line 164 in the source code. BTW, this was something I was going to work on but thanks to you I now have a handle on this.
Regards,
John
Interesting. Too bad if you want the battery to act as a UPS it cant
some how notify the kernel that AC has been removed
and have a routine to just chill a while to see if power comes back.
Be nice to have a variable that is user settable for the time between
loss of AC and shutdown.
As it is now it sees the AC removed, shuts down and no easy way to
restart on power restored. Requiring some other IC to monitor power
and then press the pwr_but to restart the processor.
Yep, you need a hardware state machine to monitor the power source. I don’t use batteries as I use supercaps which are just big enough to power the board during shutdown. When the power returns, I restart the board. There are a few corner cases that occur, such as when the power comes back on during the power down cycle, or the power fails during the power up cycle.
Regards,
John
One more thing, the power down sequence uses the RTC framework (described earlier in this thread), so it will be possible to set a timer for the shutdown and the wait for the power to return event to cancel the timer. If the power on event does not occur, the shutdown will occur.
Regards,
John
Where in the code do you set that timer ?
Look at drivers/rtc/rtc-omap.c
omap_rtc_power_off_program()
Regards,
John
There is no timer in that code. The timer would have to be added, and careful consideration would have to be given to exactly how that was implemented.
So in other words, you would, or should write a completely new kernel module, that is meant to replace what already exists - As an option.
The way I read this is all you have to do is set ALARM2 when the AC line fails. If there is no ALARM2, it switches off 15uS later.
Regards,
John
I asked Robert how the pwr button is processed and interestingly it is done via udev and systemd. Also, there is some new code going mainstream for the pwr button and battery charger. Perhaps you can implement the timer delay via a custom systemd service. Here is what Robert sent me:
Oh this is finally getting upstreamed:
https://www.spinics.net/lists/linux-omap/msg127184.html
I need to switch to their version, vs our 3.8.13 erra hack that’s been forward ported for years. 
Behind the scenes’s that patch is reporting a key-event to systemd…
Regards,
John
#1
william@beaglebone:~$ ls /etc/udev/rules.d/
50-hidraw.rules 50-spi.rules 60-omap-tty.rules 70-persistent-net.rules uio.rules
#2
We do not care about the button press. We did care about what happens when power is removed, while a battery is connected.
Now we do not care. We’re not going to bother with it. It’s too much hassle for a result that is not really all that important. So what if the power down routine is inefficient . . . it works.
That is OK if this doesn’t work for you, but there are other BBB users who might find this helpful. Currently the powerfail uses the same key function as the pwr button, so the first place to start would be changing the key function to something else. Also, the interrupt routine does not report power good, so that would have to be added. After that, a systemd service could take care of the rest.
Regards,
John
I have an interest in this. It’s way above my pay grade from a programming perspective… Mike
I have an interest in this. It’s way above my pay grade from a programming perspective…
Mike
Hi Mike,
This is actually something I’m personally very interested in too. However, at this moment in time, my buddy and I are actually in the process of making two different capes for the beaglebone. So this is one of those situations where you have to have priorities . . . and while I obviously do not know everything involved to get this certain thing done, it is not above my pay grade.
So perhaps in the future, it may be something I’ll revisit, and would be something I’d contribute back to the community.
So there is apparently a bug related to this whole situation. Once the input power goes away, whatever it may be. You lose USB, because the PMIC is not longer able to supply 5V. You even get a kernel message in relation to this from musb.
The problem is, once input power is restored, I see no indication that 5V is restored to USB. So If you tail -f /var/log/messages, you’ll see one musb message when pulling power, but you will not see a corresponding message when plugging power back in. Additionally if you pull power multiple times. Only the first message is displayed.
What this tells me is that the current kernel modules are not written to deal / handle this yet. So for now, unless I’m wrong ( which i doubt ). It’s best just to power down period. After input power goes away, and simply use an R/C network to “time” system up’s, in case power goes up / down rapidly. One, or more times consecutively.