Hi, On Fri, Jun 12, 2015 at 12:36 PM, Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx> wrote: >>> registers are lost assuming the combiner was powered down, even the >>> status register will be lost and you will not know exactly the wakeup >>> reason right ? >>> >> >> Good question, I didn't find in the documentation I've access to that >> this happen but just found through experimentation that the IRQ enable >> set register values are lost after a resume and that saving/restoring >> the values makes the interrupts to be triggered again. >> > > I'll share here too the findings I mentioned over IRC. As you suggested I > add some printouts and noticed that the ISTRn (Interrupt Status) registers > values are indeed preserved on resume so I can know for example if the > wakeup source was the power gpio-key or cros_ec keyboard. I've checked the > values of the registers against the Exynos manual and they corresponds to > the interrupt sources in each case so the values are correct. > > So as you said, it seems that is not that the IP block loses its state on > S2R but that something is blindly writing the IESRn (Interrupt Enable Set) > registers. I'll postulate an alternate theory here. You can tell me if you buy it or if you think I've been out in the sun too long. Let's say that the interrupt combiner's status registers show the raw status as asserted by whatever is hooked up to the combiner. This means that even if the combiner got reset we could still read the status register and get the status of the source. Imagine that the combiner is like a GPIO bank. If you reset the GPIO bank, you'll lose all kinds of config (input vs. output, edge interrupt status, maybe pulls, etc). ...but you can still read the state asserted by an external source, right? In this case the combiner's interrupt source is 'EINT 11'. ...and I'm pretty sure that the controller managine 'EINT 11' _doesn't_ lose power across suspend/resume... I'll further bolster my theory by saying that _almost nothing_ in the exynos keeps power across suspend/resume. The UART? Nope. The GPIO controllers? Nuh-uh. The GIC? Sorry, but no. The clock tree? It might be nice, but you're out of luck. ...so it would make me terribly surprised to see the combiner keep power. > To reduce the possible s/w components that could be doing this, I booted a > signed FIT image directly using the RO U-Boot instead of chain loading a > mainline nv-uboot. In this configuration I've the same issue so it seems > that if something is zeroing those registers on S2R, this can't be changed > without void the warranty of these machines. > > I also looked at the downstream ChromiumOS v3.8 tree [0] and I see that > they have a very similar solution than my patch, the IESRn are also saved > but using a notifier for the CPU_PM_ENTER and CPU_PM_EXIT events instead > or registering a syscore ops but the idea is basically the same. Yup, you can see where kliegs added it in <https://chromium-review.googlesource.com/#/c/27964/>. As per the comments in that CL, this was probably broken in: 063bd6f ARM: EXYNOS: Remove GIC save & restore function > I have to take a look to the U-boot that is shipped on the device, I think > the correct branch is [1] but I'm not sure if that is the correct one. It is the right one. If U-Boot were touching this (which would greatly surprise me) it should be here: arch/arm/include/asm/arch-exynos/cpu.h ...and it's not. Doing a grep for '10440000' (the combiner base address) doesn't find anything in U-Boot either, which makes it less likely. ...and it's even less likely since the amount of code that is in U-Boot that runs at resume time is a very small subset and I'm fairly familiar with it and I would have remembered it touching the combiner. It's POSSIBLE that the internal ROM in exynos is clobbering this, but as per above it seems crazy unlikely and I think it's just losing power. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |