https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230290
--- Comment #14 from Johannes Lundberg <johal...@gmail.com> --- (In reply to John Baldwin from comment #13) > So my question is why does Linuxkpi care about the sleep state? Because the driver asks linuxkpi what is the state we are suspending to. > Does it actually have conditional logic that it is using? Yes, suspending to idle or suspending to sleep is handled somewhat differently. 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_SUSPEND/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 having 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 state > 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 the 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 will make things more clear and give some understanding to how we are working with the GPU drivers. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-acpi@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
