From: Javier Martinez Canillas <javier.martinez@collabora.co.uk> To: Sudeep Holla <sudeep.holla@arm.com> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com>, "linux-samsung-soc@vger.kernel.org" <linux-samsung-soc@vger.kernel.org>, Jason Cooper <jason@lakedaemon.net>, Chanho Park <parkch98@gmail.com>, Doug Anderson <dianders@chromium.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Kukjin Kim <kgene@kernel.org>, Peter Chubb <peter.chubb@nicta.com.au>, Shuah Khan <shuahkhan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Tomasz Figa <tomasz.figa@gmail.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend Date: Fri, 12 Jun 2015 21:36:07 +0200 [thread overview] Message-ID: <557B34A7.4090507@collabora.co.uk> (raw) In-Reply-To: <557AD728.7090908@collabora.co.uk> Hello Sudeep, On 06/12/2015 02:57 PM, Javier Martinez Canillas wrote: > On 06/12/2015 01:54 PM, Sudeep Holla wrote: [snip] > >> 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. 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. 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. Best regards, Javier [0]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/common.c#657 [1]: https://chromium.googlesource.com/chromiumos/third_party/u-boot firmware-pit-4482.B
WARNING: multiple messages have this Message-ID (diff)
From: javier.martinez@collabora.co.uk (Javier Martinez Canillas) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend Date: Fri, 12 Jun 2015 21:36:07 +0200 [thread overview] Message-ID: <557B34A7.4090507@collabora.co.uk> (raw) In-Reply-To: <557AD728.7090908@collabora.co.uk> Hello Sudeep, On 06/12/2015 02:57 PM, Javier Martinez Canillas wrote: > On 06/12/2015 01:54 PM, Sudeep Holla wrote: [snip] > >> 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. 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. 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. Best regards, Javier [0]: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.8/arch/arm/mach-exynos/common.c#657 [1]: https://chromium.googlesource.com/chromiumos/third_party/u-boot firmware-pit-4482.B
next prev parent reply other threads:[~2015-06-12 19:36 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-06-12 5:43 [PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend Javier Martinez Canillas 2015-06-12 5:43 ` Javier Martinez Canillas 2015-06-12 5:57 ` Krzysztof Kozlowski 2015-06-12 5:57 ` Krzysztof Kozlowski 2015-06-12 10:10 ` Sudeep Holla 2015-06-12 10:10 ` Sudeep Holla 2015-06-12 10:42 ` Krzysztof Kozlowski 2015-06-12 10:42 ` Krzysztof Kozlowski 2015-06-12 10:56 ` Sudeep Holla 2015-06-12 10:56 ` Sudeep Holla 2015-06-12 11:27 ` Javier Martinez Canillas 2015-06-12 11:27 ` Javier Martinez Canillas 2015-06-12 11:54 ` Sudeep Holla 2015-06-12 11:54 ` Sudeep Holla 2015-06-12 12:57 ` Javier Martinez Canillas 2015-06-12 12:57 ` Javier Martinez Canillas 2015-06-12 19:36 ` Javier Martinez Canillas [this message] 2015-06-12 19:36 ` Javier Martinez Canillas 2015-06-12 20:17 ` Doug Anderson 2015-06-12 20:17 ` Doug Anderson 2015-06-15 7:46 ` Javier Martinez Canillas 2015-06-15 7:46 ` Javier Martinez Canillas 2015-06-15 9:01 ` Sudeep Holla 2015-06-15 9:01 ` Sudeep Holla 2015-06-15 15:00 ` Javier Martinez Canillas 2015-06-15 15:00 ` Javier Martinez Canillas 2015-06-15 15:08 ` Sudeep Holla 2015-06-15 15:08 ` Sudeep Holla 2015-06-15 15:23 ` Javier Martinez Canillas 2015-06-15 15:23 ` Javier Martinez Canillas 2015-06-15 23:57 ` Krzysztof Kozlowski 2015-06-15 23:57 ` Krzysztof Kozlowski 2015-06-16 3:19 ` Javier Martinez Canillas 2015-06-16 3:19 ` Javier Martinez Canillas 2015-06-16 8:21 ` Thomas Gleixner 2015-06-16 8:21 ` Thomas Gleixner 2015-06-16 12:32 ` Tomasz Figa 2015-06-16 12:32 ` Tomasz Figa 2015-06-16 13:11 ` Sudeep Holla 2015-06-16 13:11 ` Sudeep Holla 2015-06-15 8:52 ` Sudeep Holla 2015-06-15 8:52 ` Sudeep Holla 2015-06-16 9:36 ` [tip:irq/core] " tip-bot for Javier Martinez Canillas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=557B34A7.4090507@collabora.co.uk \ --to=javier.martinez@collabora.co.uk \ --cc=dianders@chromium.org \ --cc=jason@lakedaemon.net \ --cc=k.kozlowski@samsung.com \ --cc=kgene@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=parkch98@gmail.com \ --cc=peter.chubb@nicta.com.au \ --cc=shuahkhan@gmail.com \ --cc=sudeep.holla@arm.com \ --cc=tglx@linutronix.de \ --cc=tomasz.figa@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.