Expected behavior is Android device remains off after shutdown until user presses on power button.
I am using Android L on DB410c and system reboots after shutdown (also boots as soon as power is connected while normally, it should wait for pressing on power button).
Perhaps some misconfiguration on pm8916?
Does anyone know a way to fix this?
(I have also tried intrinsyc 410 dev board and it doesn’t show this problem)
I believe this is the normal behavior for this board. It is designed to automatically boot when power is applied.
Perhaps I should have broken this into two questions. The main question as in the title is: “why reboot a few seconds after shutdown”. I was aware of the other thread; yet did not find a hint there on how to change the code so that the system stays down after user directs it to do so on the Android UI.
Thanks,
M.
Why?
I think the main reason was to ensure the board would boot automatically when power is applied. This is a big advantage for development boards because it makes it easier to run test images. This is a particular benefit to simplify CI testing but is valuable for regular developers too. The 12v power supply on my desk is run through a software controlled relay so I can load new images to boards fully automatically.
On the DB410C there is no option to disable this feature.
Is there any projected date for the release of next generation dragon board?
As Dr River Song says: “Spoilers”. 
Full Disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinions of my employer.
On the post title topic:
I don’t claim this as a fix and not sure if it breaks anything else - just an observation:
in function qpnp_pon_system_pwr_off
at the very end, if you write 0 to QPNP_PON_PS_HOLD_RST_CTL2 instead of 1, DragonBoard does not reboot by itself after shutdown (and it will reboot if you press on power button or remove/re-insert external power).
I can’t have any insight into what these registers do, and I’m fairly curious about how much power the board consumes in this state, but it does look similar to a proposed (but rejected) approach for the DB410C Debian/OpenEmbedded releases:
https://bugs.96boards.org/show_bug.cgi?id=121#c9
Good point.
My guess is this will keep Soc in reset (haven’t looked at reset input to the Soc).
I’ll update if I have info on power consumption while in this mode.
I’m curious how does DB410c running Linaro behave when user shuts down system using UI; does it reboot by itself or stays shut down.
I am following this interesting thread because I am also concern about the power off-restart. Hoping for another behaviour.
Using the Debian img 260. After the “sudo poweroff” it restart automatically after a few seconds…
Just something I found while digging for the poweroff problem… I found that the reboot happens if you don’t have the PM8941 power key driver in your kernel and device tree:
CONFIG_INPUT_PM8941_PWRKEY=y
The reboot handler in drivers/input/misc/pm8941.c maps the reboot type to the correct PM8916 code so that the shutdown commands happen as expected.
Which DB410c build does your comment apply to?
Are you referring to Qualcomm Android 5.1 BSP branch? or something else?
Thanks,
Mo
I’m working on Debian snapshot 311 with the 4.14 kernel.
I’m no expert on Debian.
I have some trouble finding the exact code you mentioned in your post:
1- are you testing on DB410c? What is current consumption in shut down state? (and what is the current before shutdown?)
2- I checked instructions at:
http://builds.96boards.org/releases/dragonboard410c/linaro/debian/latest/
to get the debian build but after download, there is no " drivers/input/misc/pm8941.c" perhaps you meant: pm8941-pwrkey.c ? or you were referring to to a different branch?
I checked the code for pm8941_reboot_notify there but did not find any difference with respect to the Android’s qpnp_pon_system_pwr_off.
Sorry about the reference… pm8941-pwrkey.c is correct. The driver registers a reboot notifier callback handler (pm8941_reboot_notify) that sets the magic bits in the PM8916 mentioned previously. The main poweroff code (drivers/power/reset/msm-poweroff.c) just sets the PS hold which will reboot unless the reboot notifier changes the function.
I’m using a custom 410 based design, but very similar to the dragonboard. In my design all auxiliary supplies are off when the 410 is shutdown, so power in this state is near 0 (not sure of the exact value). The DB410 has some extra buck regulators that I don’t believe get shutdown. There will be some residual draw from any devices powered by these supplies as well as leakage back into the 410 through the unpowered pins.
I tried out the link for “rejected” fix that @danielt mentioned (thanks for that) and noted the supply current drops from 70mA to 1mA and noticed that Soc reset input line goes active (low) and stays low until user pushes on power button again.
I’m curious what was the reason for rejection.
Cool… maybe a problem for some battery use cases but a perfectly sane level of standby current for automotive use.
Not 100% sure about the reasons this was rejected. It could be concerns about robustness (if kernel PMIC code changes will the behavior could regress) but this is only speculation on my part (@anon91830841?).
The reason why I objected to that patch is that during normal circumstances inserting the power cable would always cause the board to power on, but with this patch the PMIC is reconfigured to not automatically boot the board when this happens. (The issue reported was that the board did shutdown and then the PMIC detected power and booted it again)
So depending on if this code had been run and if the state had been kept in the PMIC (e.g. due to coincell, USB attached etc) you will have different things happening when you insert the power cable.
Regards,
Bjorn
