similar to: [PATCH] drm/nouveau: Drop superfluous DRM_SWITCH_POWER_DYNAMIC_OFF checks

Hi Ben, On Tue, Nov 08, 2016 at 09:29:38PM +0100, Peter Wu wrote: > On Tue, Nov 08, 2016 at 12:57:00PM +0100, Lukas Wunner wrote: > > nouveau's ->suspend and ->resume callbacks are currently skipped if the > > device's status is either DRM_SWITCH_POWER_OFF (powered off by > > vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF > > (runtime

On Tue, Nov 08, 2016 at 12:57:00PM +0100, Lukas Wunner wrote: > nouveau's ->suspend and ->resume callbacks are currently skipped if the > device's status is either DRM_SWITCH_POWER_OFF (powered off by > vga_switcheroo manual power control) or DRM_SWITCH_POWER_DYNAMIC_OFF > (runtime suspended). > > In the former case this makes sense since the device is powered off

On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > <mika.westerberg at intel.com> wrote: > > > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > > > overall, what I really want to know is, _why_ does it work on windows? > > > > So do I ;-) > > > > > Or what are

On Sat, 2019-05-04 at 18:32 +0200, Karol Herbst wrote: > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/nouveau_acpi.c | 6 +++--- > drm/nouveau/nouveau_acpi.h | 4 ++-- > drm/nouveau/nouveau_drm.c | 15 +++++++++++---- > drm/nouveau/nouveau_drv.h | 2 ++ > 4 files changed, 18 insertions(+), 9 deletions(-) > > diff --git

why the nouveau_is_rpm_worker stuff? On Sat, Nov 17, 2018 at 2:50 AM Lyude Paul <lyude at redhat.com> wrote: > > Now that we have ->pre_transfer() and ->post_transfer() for DP AUX > channel devices, we can implement these hooks in order to ensure that > the GPU is actually woken up before AUX transactions happen. This fixes > /dev/drm_dp_aux* not working while the GPU is

On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > overall, what I really want to know is, _why_ does it work on windows? So do I ;-) > Or what are we doing differently on Linux so that it doesn't work? If > anybody has any idea on how we could dig into this and figure it out > on this level, this would probably allow us to get closer to the root > cause? no?

Hi, This series includes some pieces of fixes to complete the GK20A power on/off sequences and add the suspend/resume support. The patches 1/11 - 4/11 are based on the linux-next-20141219. The patches 5/11 - 11/11 are based on the branch "linux-3.19" of Ben Skeggs's tree (http://cgit.freedesktop.org/~darktama/nouveau). Thanks, Vince Vince Hsu (4): (linux-next-20141219) ARM:

fixes bogus values userspace gets from hwmon while the GPU is powered down Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_hwmon.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drm/nouveau/nouveau_hwmon.c b/drm/nouveau/nouveau_hwmon.c index 618d8b780..d445c6f3f 100644 --- a/drm/nouveau/nouveau_hwmon.c +++ b/drm/nouveau/nouveau_hwmon.c @@ -426,6

[+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime) resume")] On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote: > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote: > > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote: > > > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote: > > > > On Thu,

Here's some fixes for the less important DP AUX issues I mentioned a while back. Lyude Paul (2): drm/dp: Add ->pre/post_transfer() hooks for drm_dp_aux drm/nouveau: Grab an rpm reference before/after DP AUX transactions drivers/gpu/drm/drm_dp_helper.c | 5 ++ drivers/gpu/drm/nouveau/nouveau_connector.c | 36 ++++++++ drivers/gpu/drm/nouveau/nouveau_drm.c | 12 ++-

While investigating the runpm issues on my GP107 I noticed that something inside devinit makes runpm break. If Nouveau loads up to the point right before doing devinit, runpm works without any issues, if devinit is ran, not anymore. Out of curiousity I even tried to "bisect" devinit by not running it on vbios provided signed PMU image, but on the devinit parser we have inside Nouveau.

On Wed, Nov 20, 2019 at 4:15 PM Mika Westerberg <mika.westerberg at intel.com> wrote: > > On Wed, Nov 20, 2019 at 01:11:52PM +0100, Karol Herbst wrote: > > On Wed, Nov 20, 2019 at 1:09 PM Mika Westerberg > > <mika.westerberg at intel.com> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:58:00PM +0100, Karol Herbst wrote: > > > > overall,

CCing linux-pci and Bjorn Helgaas. Maybe we could get better insights on how a reasonable fix would look like. Anyway, to me this entire issue looks like something which has to be fixed on a PCI level instead of inside a driver, so it makes sense to ask the pci folks if they have any better suggestions. Original cover letter: While investigating the runpm issues on my GP107 I noticed that

On Sun, Feb 11, 2018 at 06:58:11PM +0000, Mike Lothian wrote: > On 11 February 2018 at 09:38, Lukas Wunner <lukas at wunner.de> wrote: > > The patches for radeon and amdgpu are compile-tested only, I only have a > > MacBook Pro with an Nvidia GK107 to test. To test the patches, add an > > "msleep(12*1000);" at the top of the driver's ->runtime_suspend

Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_acpi.c | 6 +++--- drm/nouveau/nouveau_acpi.h | 4 ++-- drm/nouveau/nouveau_drm.c | 15 +++++++++++---- drm/nouveau/nouveau_drv.h | 2 ++ 4 files changed, 18 insertions(+), 9 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c b/drm/nouveau/nouveau_acpi.c index ffb19585..49b11d22 100644 ---

v2: rework detection of if Nouveau calling a DSM method or not Signed-off-by: Karol Herbst <kherbst at redhat.com> --- drm/nouveau/nouveau_acpi.c | 7 ++++++- drm/nouveau/nouveau_acpi.h | 2 ++ drm/nouveau/nouveau_drm.c | 14 +++++++++++--- drm/nouveau/nouveau_drv.h | 2 ++ 4 files changed, 21 insertions(+), 4 deletions(-) diff --git a/drm/nouveau/nouveau_acpi.c

When looking into the runpm issues, the first workaround I came up with was setting the PCIe link speed to whatever it was before running devinit on the GPU. As I was playing around with my patches today, it seems like that just reworking the runpm bits itself fixed it on my machine as well. Hopefully this will be enough for other laptops as well. Anyhow, it's a nice rework and if it's

When looking into the runpm issues, the first workaround I came up with was setting the PCIe link speed to whatever it was before running devinit on the GPU. As I was playing around with my patches today, it seems like that just reworking the runpm bits itself fixed it on my machine as well. Hopefully this will be enough for other laptops as well. Anyhow, it's a nice rework and if it's

On Tue, May 7, 2019 at 9:16 PM Lyude Paul <lyude at redhat.com> wrote: > > On Sat, 2019-05-04 at 18:32 +0200, Karol Herbst wrote: > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > > --- > > drm/nouveau/nouveau_acpi.c | 6 +++--- > > drm/nouveau/nouveau_acpi.h | 4 ++-- > > drm/nouveau/nouveau_drm.c | 15 +++++++++++---- > >

In order to fix all of the spots that need to have runtime PM get/puts() added, we need to ensure that it's possible for us to call pm_runtime_get/put() in any context, regardless of how deep, since almost all of the spots that are currently missing refs can potentially get called in the runtime suspend/resume path. Otherwise, we'll try to resume the GPU as we're trying to resume the