Re: [PATCH v3 2/3] drm/nouveau/gsp/r570: Never enter Gcoff state

["Danilo Krummrich" <dakr@kernel.org>]

On Thu Jul 2, 2026 at 2:30 AM CEST, David Airlie wrote:
> On Thu, Jul 2, 2026 at 10:27 AM Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> (Cc: John)
>>
>> On Wed Jul 1, 2026 at 8:17 PM CEST, Lyude Paul wrote:
>> > It turns out that the only reason our previous fixes looked like they
>> > worked for this was because we would occasionally set the Gcoff state to 0
>> > in the normal S3 path, which fixed suspend/resume on desktops - but not on
>> > machines using runtime suspend.
>> >
>> > The proper fix is to just never set this flag. Our current guess for the
>> > reasoning behind this is that Gcoff likely coincides with GC6, and not
>> > literally power off.
>>
>> I don't think GcOff coincides with GC6, it should actually be a power off.
>>
>> From a quick glance in OpenRM, it seems that with bEnteringGcoffState = 1 it
>> also saves off buffers flagged as MEMDESC_FLAGS_LOST_ON_SUSPEND.
>>
>> My guess would be that with bEnteringGcoffState = 1, GSP's resume path expects
>> certain kernel-driver-allocated buffers to still be in place that nouveau didn't
>> save off, or rather never had in the first place.
>>
>> John, do you have some details about this?
>>
>
> In nouveau we have the INST_SR_LOST target, for buffers that aren't
> preserved, I wonder did something change between 535 and 570 around
> what needs to be kept around.

The r535 code never set bEnteringGcoffState in the first place. In r535 OpenRM
seems to do the exact same thing.