similar to: [PATCH] drm/nouveau: fix nouveau_dsm_get_client_id()'s return type

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

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 +--

On Tue, Apr 24, 2018 at 03:15:24PM +0200, Luc Van Oostenryck wrote: > The method struct drm_connector_helper_funcs::mode_valid is defined > as returning an 'enum drm_mode_status' but the driver implementation > for this method uses an 'int' for it. > > Fix this by using 'enum drm_mode_status' in the driver too. > > Signed-off-by: Luc Van Oostenryck

The method struct drm_connector_helper_funcs::mode_valid is defined as returning an 'enum drm_mode_status' but the driver implementation for this method uses an 'int' for it. Fix this by using 'enum drm_mode_status' in the driver too. Signed-off-by: Luc Van Oostenryck <luc.vanoostenryck at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +- 1 file

Another vga_switcheroo cleanup. Maintainers, is it okay to include the one-line change of each driver in here or do you want that split into separate patches? Thanks, Lukas Lukas Wunner (1): vga_switcheroo: Constify vga_switcheroo_handler drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +- drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-

Allow handlers to declare their capabilities and allow clients to obtain that information. So far we have these use cases: * If the handler is able to switch DDC separately, clients need to probe EDID with drm_get_edid_switcheroo(). We should allow them to detect a capable handler to ensure this function only gets called when needed. * Likewise if the handler is unable to switch AUX

Replace nouveau_pr3_present() in favor of a more generic one, pci_pr3_present(). Also the presence of upstream bridge _PR3 doesn't need to go hand in hand with device's _DSM, so check _PR3 before _DSM. Signed-off-by: Kai-Heng Feng <kai.heng.feng at canonical.com> --- drivers/gpu/drm/nouveau/nouveau_acpi.c | 44 ++++++-------------------- 1 file changed, 10 insertions(+), 34

Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port can be runtime-suspended which disables power resources via ACPI. This is incompatible with DSM, resulting in a GPU device which is still in D3 and locks up the kernel on resume. Mirror the behavior of Windows 8 and newer[1] (as observed via an AMLi debugger trace) and stop using the DSM functions for D3cold when

Ensure that the returned set of supported DSM functions (MUX, Optimus) match the ACPI handle that is set in nouveau_dsm_pci_probe. As there are no machines with a MUX function on just one PCI device and an Optimus on another, there should not be a functional impact. This change however makes this implicit assumption more obvious. Convert int to bool and rename has_dsm to has_mux while at it. Let

On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > > can be runtime-suspended which disables power resources via ACPI. This > > is incompatible with DSM, resulting in a GPU device which is still in D3 > > and

Ensure that the returned set of supported DSM functions (MUX, Optimus) match the ACPI handle that is set in nouveau_dsm_pci_probe. As there are no machines with a MUX function on just one PCI device and an Optimus on another, there should not be a functional impact. This change however makes this implicit assumption more obvious. Convert int to bool and rename has_dsm to has_mux while at it. Let

Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port can be runtime-suspended which disables power resources via ACPI. This is incompatible with DSM, resulting in a GPU device which is still in D3 and locks up the kernel on resume (on a Clevo P651RA, GTX965M). Mirror the behavior of Windows 8 and newer[1] (as observed via an AMLi debugger trace) and stop using the

On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: > Hi Peter, > > On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > > can be runtime-suspended which disables power resources via ACPI. This > > is incompatible with DSM, resulting in a GPU device

Do not unconditionally invoke function 0x1B without checking for its availability, it leads to an infinite loop on some firmware. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791 Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)") Signed-off-by: Peter Wu <peter at lekensteyn.nl> --- Hi, I am not sure what exactly 0x1B is used for, it seems related to HDMI

Hello, These days I am reading nouveau source code,but I cannot understand this code! Please look at http://codepad.org/61v3mXmq . The function ‘nouveau_dsm_power_state’ said optimus is disabled in another function ‘nouveau_switcheroo_set_state’. But in fact,the function ‘nouveau_switcheroo_set_state’ will return directly when optimus is detected! Both of these functions won’t disable

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 Mon, May 30, 2016 at 12:57:09PM +0300, Mika Westerberg wrote: > +Rafael > > On Fri, May 27, 2016 at 01:10:37PM +0200, Peter Wu wrote: > > On Wed, May 25, 2016 at 04:55:35PM +0300, Mika Westerberg wrote: > > > On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > > > > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port

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. ---

On Wed, May 25, 2016 at 12:53:01AM +0200, Peter Wu wrote: > Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port > can be runtime-suspended which disables power resources via ACPI. This > is incompatible with DSM, resulting in a GPU device which is still in D3 > and locks up the kernel on resume. > > Mirror the behavior of Windows 8 and newer[1] (as

On Mon, May 30, 2016 at 11:48:34AM +0100, Emil Velikov wrote: > On 27 May 2016 at 22:31, Peter Wu <peter at lekensteyn.nl> wrote: > > On Fri, May 27, 2016 at 02:01:39PM +0100, Emil Velikov wrote: > >> Hi Peter, > >> > >> On 24 May 2016 at 23:53, Peter Wu <peter at lekensteyn.nl> wrote: > >> > Since "PCI: Add runtime PM support for