Date: Thu, 09 Aug 2018 06:14:45 +0000 From: bugzilla-noreply@freebsd.org To: acpi@FreeBSD.org Subject: [Bug 230290] [patch] acpi: call sleep event handler when sleeping via command line Message-ID: <bug-230290-16045-QuHztETDLQ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230290-16045@https.bugs.freebsd.org/bugzilla/> References: <bug-230290-16045@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230290 --- Comment #14 from Johannes Lundberg <johalun0@gmail.com> --- (In reply to John Baldwin from comment #13) > So my question is why does Linuxkpi care about the sleep state?=20 Because the driver asks linuxkpi what is the state we are suspending to. > Does it actually have conditional logic that it is using?=20 Yes, suspending to idle or suspending to sleep is handled somewhat differen= tly. One bug we had was that GPU firmware wasn't reloaded on resume because the driver thought we were suspending to idle. > If it really needs it, then what I think we should do is change DEVICE_SU= SPEND/RESUME to add the type of suspend/resume being requested. Yes, that could be the long term goal. For now, we could fix this suspend/resume bug by using power_* events and assuming S0/S3, without havi= ng to do any invasive changes to base or the driver code. > This is somewhat complicated because devices can be suspended and resumed= not as part of a system wide suspend and resume (e.g. 'devctl suspend foo0= '), and for S0ix what you really want is to power down devices that aren't = used even if the system isn't fully idle itself. Yes. Ben Widawsky said he is working on S0ix so let's see how that fits in = to everything before making any changes to base. > So, the first question is why does Linuxkpi care what the system sleep st= ate is vs what Dx state the GPU device is being placed in? To tell the GPU driver if we're suspending to idle or sleep. This is what t= he device driver expects and having this information in linuxkpi mean we don't have to patch the upstream GPU driver code. For every modification we do to= the upstream driver code, future updating becomes more time consuming and messy= due to merge conflicts. When updating the GPU drivers, it's always a choice whether to make changes= in linuxkpi or patch the driver code. Since this serves all clients of linuxkpi and was easy enough to add to linuxkpi, that's what I chose. I hope this wi= ll make things more clear and give some understanding to how we are working wi= th the GPU drivers. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230290-16045-QuHztETDLQ>