similar to: [PATCH] drm: silence unimportant HDMI status message

The hdmi device is required for runtime pm. However it is not available on many esp older devices, which were all seeing these error messages. Take this opportunity to also convert to nv_debug instead of the DRM_* messages, like the rest of nouveau does. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 11 +++++------ 1 file changed, 5

Op 24-07-13 09:13, Dave Airlie schreef: > After a full device powerdown via the optimus power switch, we seem > to lose the HDMI device completely on power on, this keep track of > whether we had a hdmi audio sub function device at power on, and > pokes a magic register to make it reappear after the optimus power > switch is thrown. > > This at least works on my NVC4 machine,

After a full device powerdown via the optimus power switch, we seem to lose the HDMI device completely on power on, this keep track of whether we had a hdmi audio sub function device at power on, and pokes a magic register to make it reappear after the optimus power switch is thrown. This at least works on my NVC4 machine, probably needs testing on a few other laptops with other nvidia GPUs.

Add a missing newline at the end of a DRM_INFO message. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index b2a674531fba..ef27949057c3 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++

From: Markus Elfring <elfring at users.sourceforge.net> Date: Wed, 20 Jul 2016 19:43:27 +0200 The pci_dev_put() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring at users.sourceforge.net> ---

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Use pci_get_domain_bus_and_slot() with a domain number of 0 where we can't extract the domain number. Other places, use the actual domain number from the device. Signed-off-by: Sinan Kaya <okaya at codeaurora.org>

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot() and extract the domain number from 1. struct pci_dev 2.

+nouveau at lists.freedesktop.org On 11/27/2017 11:57 AM, Sinan Kaya wrote: > pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > where a PCI device is present. This restricts the device drivers to be > reused for other domain numbers. > > Getting ready to remove pci_get_bus_and_slot() function in favor of > pci_get_domain_bus_and_slot(). > >

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot() and extract the domain number from 1. struct pci_dev 2.

pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as where a PCI device is present. This restricts the device drivers to be reused for other domain numbers. Getting ready to remove pci_get_bus_and_slot() function in favor of pci_get_domain_bus_and_slot(). Replace pci_get_bus_and_slot() with pci_get_domain_bus_and_slot() and extract the domain number from 1. struct pci_dev 2.

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

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

It's really confusing for NV_DEBUG's printing to be controlled via drm.debug while everything else is controlled via nouveau.debug. These messages can be turned on with nouveau.debug=DRM=debug. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Updated version that makes the top-level DRM client have a separate debug flag from everything else, since it presents debug info

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

Currently, it appears that nouveau_do_suspend() forgets to roll back suspending fbcon and suspending the device LEDs. We also currently skip the entire rollback process if nouveau_display_suspend() fails. So, fix that. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: stable at vger.kernel.org Cc: Lukas Wunner <lukas at wunner.de> Cc: Karol Herbst <karolherbst at gmail.com>

On a failed resume we may experience unrecoverable errors. Plumb the error code through to actually let the driver fail. On a reverse-prime setup this helps the drm subsystem to at least recover the integrated gpu. This can especially happen with secboot timing out, leaving the hardware in a non-functioning state. Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de>

The T124 generation of Tegra GPUs uses the Kepler architecture and can thus be driven by Nouveau. However, they are declared as platform devices using the Device Tree, and Nouveau has a very strong dependency on PCI. This patch makes Nouveau core able to handle platform devices as well as PCI devices. Commonly-used PCI functions include resource range query and page mapping. These functions are

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

On the Lenovo P50 I've been working on, ACPI notifications for hotplugs always seem happen even while the GPU has it's hotplugs enabled. This means that we're uselessly scheduling two connector probes every time we get a hotplug. Since we can't unregister the acpi handler without causing userspace to start getting mysterious keypresses from the ACPI_VIDEO_REPROBE events that are

Hi. In ocfs2, fdatasync and fsync are identical. I think fdatasync should skip committing transaction when inode->i_state is set just I_DIRTY_SYNC and this indicates only atime or/and mtime updates. Following patch improves fdatasync throughput. #sysbench --num-threads=16 --max-requests=300000 --test=fileio --file-block-size=4K --file-total-size=16G --file-test-mode=rndwr