similar to: [PATCH] drm/nouveau: only runtime suspend by default in optimus configuration

Displaying 20 results from an estimated 500 matches similar to: "[PATCH] drm/nouveau: only runtime suspend by default in optimus configuration"

2014 Mar 19
2
[PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm
There was a proliferation of duplicated checks for runpm == -1 && optimus. Instead of continuing that tradition, get rid of all of them, only doing the optimus computation once on load. This should hopefully fix secondary cards suspending and then being unable to come back in non-optimus setups. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: <stable at
2014 Mar 19
0
[PATCH] drm: compute runpm on load, don't register autosuspend for non-runpm
On Thu, Mar 20, 2014 at 1:28 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > There was a proliferation of duplicated checks for runpm == -1 && > optimus. Instead of continuing that tradition, get rid of all of them, > only doing the optimus computation once on load. > > This should hopefully fix secondary cards suspending and then being > unable to come back in
2017 Feb 24
0
[PATCH 3/5] drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo
An external Thunderbolt GPU can neither drive the laptop's panel nor be powered off by the platform, so there's no point in registering it with vga_switcheroo. In fact, when the external GPU is runtime suspended, vga_switcheroo will cut power to the internal discrete GPU, resulting in a lockup. Cc: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Lukas Wunner <lukas at
2017 Feb 24
1
[PATCH 3/5] drm/nouveau: Don't register Thunderbolt eGPU with vga_switcheroo
On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner <lukas at wunner.de> wrote: > An external Thunderbolt GPU can neither drive the laptop's panel nor be > powered off by the platform, so there's no point in registering it with > vga_switcheroo. > In fact, when the external GPU is runtime suspended, > vga_switcheroo will cut power to the internal discrete GPU, resulting in
2015 May 28
12
[PATCH v2 1/9] acpi: Rename v1 DSM to mux to avoid ambiguity
This is especially true when variables or functions are just called dsm without specifying the v1. Changes since v1: * Fix typo in commit explanation * Change has_dsm to has_mux in nouveau_dsm_detect Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 72 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +--
2015 May 25
15
[PATCH 1/8] acpi: Rename v1 DSM to mux to avoid ambiguity
This is especially true when variables or functions are just called dsm without precising the v1. Signed-off-by: Pierre Moreau <pierre.morrow at free.fr> --- drm/nouveau/nouveau_acpi.c | 64 +++++++++++++++++++++++----------------------- drm/nouveau/nouveau_acpi.h | 4 +-- drm/nouveau/nouveau_drm.c | 4 +-- drm/nouveau/nouveau_vga.c | 10 ++++---- 4 files changed, 41 insertions(+), 41
2015 Jan 17
0
[PATCH RFC] nouveau: Add support for Gmux _DSM method
This patch certainly needs some more work, but I'd like to get some comments. Not sure if it is really related to the gmux or if it is a different Optimus _DSM version. I tested it on my laptop (MCP79/7A + G96) and the G96 successfully goes to sleep, however it is still marked as PWR in vga_switcheroo, despite `vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF)` being called. ---
2014 Dec 23
0
[PATCH nouveau 09/11] drm: export some variable and functions to resue the PM functions
This patch adds some checks in the suspend/resume functions to distinguish the dGPU and mobile GPU and exports some variables/functions so that the nouveau platform device can reuse them. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/nouveau_drm.c | 16 +++++++++++----- drm/nouveau_drm.h | 2 ++ 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/drm/nouveau_drm.c
2016 Aug 02
0
[PATCH 0205/1285] Replace numeric parameter like 0444 with macro
I find that the developers often just specified the numeric value when calling a macro which is defined with a parameter for access permission. As we know, these numeric value for access permission have had the corresponding macro, and that using macro can improve the robustness and readability of the code, thus, I suggest replacing the numeric parameter with the macro. Signed-off-by: Chuansheng
2014 Dec 30
0
[PATCH nouveau 09/11] drm: export some variable and functions to resue the PM functions
Hi Emil, On 12/30/2014 10:34 AM, Emil Velikov wrote: > On 23/12/14 10:40, Vince Hsu wrote: >> This patch adds some checks in the suspend/resume functions to distinguish >> the dGPU and mobile GPU and exports some variables/functions so that the >> nouveau platform device can reuse them. >> > Hi Vince, > > Afaiu one needs to export a symbol as it's used by
2015 May 28
3
[PATCH v2 8/9] acpi: Add support for Apple Gmux _DMS
Hi Dave, ----- Mail original ----- > Changes since v1: [...] > diff --git a/drm/nouveau/nouveau_vga.c b/drm/nouveau/nouveau_vga.c > index 9a6328f..7b13804 100644 > --- a/drm/nouveau/nouveau_vga.c > +++ b/drm/nouveau/nouveau_vga.c > @@ -36,7 +36,7 @@ nouveau_switcheroo_set_state(struct pci_dev *pdev, > { > struct drm_device *dev = pci_get_drvdata(pdev); > > - if
2015 May 21
2
[PATCH 1/2] drm/nouveau: add staging module option
On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: > Add a module option allowing to enable staging/unstable APIs. This will > allow us to experiment freely with experimental APIs for a while before > setting them in stone. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drm/nouveau/nouveau_drm.c | 18
2014 Dec 30
2
[PATCH nouveau 09/11] drm: export some variable and functions to resue the PM functions
On 23/12/14 10:40, Vince Hsu wrote: > This patch adds some checks in the suspend/resume functions to distinguish > the dGPU and mobile GPU and exports some variables/functions so that the > nouveau platform device can reuse them. > Hi Vince, Afaiu one needs to export a symbol as it's used by another module or subsystem. With the follow up two patches you are not doing either one,
2015 May 21
2
[PATCH 1/2] drm/nouveau: add staging module option
On 21 May 2015 at 15:49, Alexandre Courbot <gnurou at gmail.com> wrote: > On Thu, May 21, 2015 at 1:48 PM, Ben Skeggs <skeggsb at gmail.com> wrote: >> On 20 May 2015 at 15:56, Alexandre Courbot <acourbot at nvidia.com> wrote: >>> Add a module option allowing to enable staging/unstable APIs. This will >>> allow us to experiment freely with experimental
2016 May 24
0
[PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload
nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. We therefore leak a runtime pm ref whenever nouveau is loaded with runpm=0 and then unloaded. The GPU will subsequently never runtime suspend even if nouveau is loaded again with runpm=1. Fix by taking the runtime pm ref under the same condition that it was
2016 Apr 10
1
[PATCH] module parameters: permissions as defines, readable to everyone
For the purposes of the module parameters, specifies the permissions of the corresponding files in sysfs in predefined S_I* form rather than in octal notation. Withal it makes the source code more consistent. Moreover, because all parameters are readable to everyone, it is more user-friendly. $ grep S_IRUGO include/linux/stat.h #define S_IRUGO (S_IRUSR|S_IRGRP|S_IROTH) $ grep
2016 May 29
0
[PATCH 1/9] drm/nouveau: Don't leak runtime pm ref on driver unload
Hi Peter, On Fri, May 27, 2016 at 03:07:33AM +0200, Peter Wu wrote: > On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote: > > nouveau_drm_load() calls pm_runtime_put() if nouveau_runtime_pm != 0, > > but nouveau_drm_unload() calls pm_runtime_get_sync() unconditionally. > > We therefore leak a runtime pm ref whenever nouveau is loaded with > > runpm=0 and then
2018 Jul 03
0
[PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs
Currently nouveau doesn't actually expose the state debugfs file that's usually provided for any modesetting driver that supports atomic, even if nouveau is loaded with atomic=1. This is due to the fact that the standard debugfs files that DRM creates for atomic drivers is called when drm_get_pci_dev() is called from nouveau_drm.c. This happens well before we've initialized the display
2007 Oct 11
1
Boot problem with x86 VxWorks on a XEN HVM
Hi, i managed to boot a VxWorks 6.5 Kernel on QEMU without kqemu acceleration. The bootloader and the precompiled Kernel, both belong to the Pentium 3 BSP, which was delivered with the evaluation version of windriver workbench 2.6 for "intel". Now I tried to boot the same VxWorks bootloader and Kernel inside a XEN HVM. I see a message from the bootloader "V1.6+++..." and the
2016 Apr 11
0
[PATCH] nouveau: Switch perms from macros to octal notations, module params readable to everyone
From: poma <pomidorabelisima at gmail.com> Switch from "silly" S_* macros to "definitely more readable" octal "way" permissions, moreover to not "so restrictive" module parameters permissions. Suggested-by: Ilia Mirkin <imirkin at alum.mit.edu> Fixes: poma <pomidorabelisima at gmail.com> Tested-by: poma <pomidorabelisima at