Hello, On 1/13/20 11:30 AM, pune wrote: > I am using Banana bi bsp for android which in turn using lichee kernel 3.10
Unfortunately, this is the reason you are not getting much help. The BSP kernel works very differently from mainline Linux, especially with regard to power management. Allwinner provides a proprietary firmware blob that communicates using a custom protocol, and they added a lot of code to their Linux fork to make it play nice with that firmware. The patchset you replied to is for mainline Linux, where the firmware design, communication protocol, memory layout, hardware ownership rules, etc., are all very different. > where i am not able bring up device from deep sleep state > by pressing power button, i can see the power button irq is configured for GIC > parent. Could you please let me know how to make this > irq en-route to r_intc so that system can resume on power button press. The IRQ from the AXP PMIC is the NMI--it always goes through R_INTC in addition to the GIC. In the BSP kernel, the firmware takes care of configuring it, so Linux doesn't know about the topology. As for your suspend issue, here are some guesses based on what I remember from the BSP code: 1) Make sure that an ARISC firmware is actually getting loaded. You cannot have deep sleep without it. There should be some messages from Boot0 or U-Boot telling you that it loaded scp.bin and started the ARISC. 2) Check the ARISC's UART output to see if it does anything when you put the board to sleep, or when you try to wake it up. It's at GPIO pins PL2/PL3, which are test points TP1/TP2 on the Banana Pi M64. 3) Check the ARISC parameters in the FEX or the device tree. That specifies which wakeup sources are enabled in the ARISC firmware (make sure you have wakeup from the PMIC enabled). It also controls properties like DRAM self-refresh (try turning that off and see if it helps). Try playing with the other parameters. Some of them may need to match your ATF or U-Boot, so maybe try a different scp.bin if you have one. 4) As a last resort, there is a register in the RTC power domain at 0x01f0010c, where the firmware writes a status code at several places during the suspend/resume process. If you can reset the board without removing power from the RTC, you can use that to troubleshoot. First clear the register, then attempt to suspend/resume; when it fails, reset the board and read the register again. You'd need to look at a disassembly of the ARISC firmware to interpret the value; see here: https://github.com/smaeul/sunxi-blobs I'm afraid that's all the help I'll be able to give, since I never use the BSP kernel. Good luck, Samuel -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/f01ae15e-d90a-6f73-4dcb-4804e1491549%40sholland.org.
