Quoting Sagar Arun Kamble (2018-02-27 06:54:46) > > > On 2/27/2018 2:22 AM, Chris Wilson wrote: > > Quoting Daniele Ceraolo Spurio (2018-02-26 16:57:11) > >> As you said we do always reset GuC no matter the value of the modparam, > >> but that does not reset the doorbell HW. If we're coming out of S3 and > >> the state as been preserved this will cause the doorbell HW to be left > >> in an unclean state, which could cause spurious doorbell interrupts to > >> be sent to GuC, not sure how the firmware handles those. The code as > >> moved since last time I looked at this in detail and I think we're now > >> most likely going to overwrite those unclean doorbells, but there are > >> unlikely corner cases (preempt context failing to be created) where we > >> might not do so. > > I'm still going "wait, we can put the device into D3 and the GuC is > > still powered?" Something feels wrong if the GuC retains state after the > > HW is powered down. > GuC will be powered down, with RC6. Just that firmware in WOPCM can get > wiped off if > memory is reset/powered down during resume. In case of mem sleep > generally WOPCM stays intact and if we exit > RC6 on resume from sleep, firmware will be restored into GuC without > driver intervention. > But since we do full GPU reset as part of sanitize we have to load it > from driver again. On resume, we don't know if we are coming from module load, resume from S3, resume S3+RST, resume from S4, or resume from kexec. (S3+RST, kexec are truly without our knowledge, the others we could feed the information through but RST makes that moot.) Ergo, you cannot know if the right fw image is loaded and aiui you should treat the state as undefined and always reload. Does that make sense? Is there a way you can query what fw is loaded and so skip instead? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
