[PATCH v2 1/1] irqchip: exynos-combiner: Save IRQ enable set on suspend

[Sudeep Holla]

On 12/06/15 21:17, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 12, 2015 at 12:36 PM, Javier Martinez Canillas
> <javier.martinez at collabora.co.uk> 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?
>

Right, this makes sense. I assumed status was latched output and might
be lost. But that's wrong assumption I believe.

> 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.
>

Interesting even GIC loses power ? I would be interested in knowing more
details as who will wake up the system then. Is the wakeup source
offloaded to some external power controller ?

>
>> 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.
>

Yes, I did search and find nothing, so definitely not U-Boot if I am
looking at the right source.

> 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.
>

Agreed, not because I believe ROM code are not crazy but because of the
theory you have provided above :)

Regards,
Sudeep