Unset IsHibernate to avoid resume from GC6/S0ix suspend taking incorrect hibernation resume path

[freenull]

With S0ix enabled and using the latest version 610.43.02, the following sequence:

• Hibernate
• Resume from hibernate
• Suspend
• Resume from suspend

Results in no video output and no backlight with spinning fans. Kernel logs reveal an assertion failure:

NVRM: nvAssertFailedNoLog: Assertion failed: pKernelPmu->pPrintBuf == NULL @ kern_pmu.c:188

After many debug prints I have been able to pinpoint this down to rm_power_management picking the wrong branch here during the final resume (RmPowerManagement instead of RmGcxPowerManagement). It turns out that the root cause is InHibernate never getting reset after resuming from hibernation. Because the _RESUME action conditionally switches the path based on InHibernate, the correct GC6 path is used during suspend, but once resume is requested the driver attempts to resume from hibernation instead. I've added a single line to reset InHibernate back to false after resuming from hibernation and I can now successfully execute any mix of suspend and hibernate on my machine.

This fixes Bug 5156763 based on my report on the NVIDIA forums from a while back. The proprietary driver used to dump the exact same assertion failure back when I was still using it, so I suspect the same patch should apply cleanly there as well :)

[CLAassistant]

All committers have signed the CLA.

[Binary-Eater]

@freenull your findings are intriguing. The reason RmPowerManagement does not take care of setting nvp->pm_state.InHibernate on the NV_PM_ACTION_RESUME path is because this should be taken care of in the NV_PM_ACTION_STANDBY and NV_PM_ACTION_HIBERNATE paths in RmPowerManagement. I am worried if this patch ends up masking the underlying issue. RmPowerManagement should be the only function updating nvp->pm_state.InHibernate.

[freenull]

@Binary-Eater RmPowerManagement does in fact reset InHibernate on the STANDBY path, but the STANDBY path of RmPowerManagement is never executed if S0ix PM is enabled because this branch here uses RmGcxPowerManagement for suspend.
Hibernating the system correctly sets InHibernate, that value is still true after resuming, suspending goes through the RmGcxPowerManagement path which never resets InHibernate, and then resuming hits the else path of the aforementioned branch which confuses the driver into trying to resume from hibernation when the system is S0ix-suspended. From my debugging, this does seem to be the actual and only underlying issue - I was able to print evidence into dmesg that after the hibernation->resume->suspend sequence, the system incorrectly executes an NV_PM_ACTION_RESUME through RmPowerManagement instead of through RmGcxPowerManagement.
Without hibernating first, suspending executes RmGcxPowerManagement with bEnter == true, and then resuming executes RmGcxPowerManagement with bEnter == false. If the system is previously hibernated, suspending executes RmGcxPowerManagement with bEnter == true but resumes through RmPowerManagement with pmAction == NV_PM_ACTION_RESUME.
I guess an alternative fix would be to unset InHibernate inside RmGcxPowerManagement (in a bEnter == true branch, so it's equivalent to NV_PM_ACTION_SUSPEND of RmPowerManagement) instead of modifying InHibernate directly on resume in RmPowerManagement. I can do that if it's preferable.