similar to: [PATCH] nouveau/gsp: drop WARN_ON in ACPI probes

These were leftover debug, if we need to bring them back do so for debugging later. Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c index 6c0a8fbf0061..1dba7c49bd9a 100644 ---

This is a collection of nouveau debug prints, memory leak, a very annoying race condition causing system hangs with prime scenarios, and a fix from Lyude to get the panel on my laptop working. I'd like to get these into 6.7, Dave.

Hi Pierre, Em qui, 19 de mai de 2016 às 06:49, Pierre Moreau <pierre.morrow at free.fr> escreveu: > Hello Marcos, > > I sent a serie a year ago to fix some of the ACPI handling in Nouveau and > add > runtime pm support for laptops with an Apple GMUX (see [0], and especially > [1] > and [2]). I was told that a more generic work for the runtime pm was in the > work,

Hello Marcos, I sent a serie a year ago to fix some of the ACPI handling in Nouveau and add runtime pm support for laptops with an Apple GMUX (see [0], and especially [1] and [2]). I was told that a more generic work for the runtime pm was in the work, so I let the whole serie slip away. I was thinking of resubmitting the serie without the runtime pm additions, to at least fix those warning/error

On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: > Most _DSM will return an integer value of 0x80000002 when given an unknown > UUID, revision ID or function ID. Checking locally allows us to differentiate > that case from other ACPI errors, and to not report a "failed to evaluate _DSM" > if 0x80000002 is returned which was confusing.

On Tue, May 26, 2015 at 1:10 AM, Pierre Moreau <pierre.morrow at free.fr> wrote: >> On 26 May 2015, at 00:39, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> >>> On Mon, May 25, 2015 at 6:22 PM, Pierre Moreau <pierre.morrow at free.fr> wrote: >>> Most _DSM will return an integer value of 0x80000002 when given an unknown >>> UUID, revision ID

On Tue, Nov 27, 2018 at 09:49:44PM -0500, Michael S. Tsirkin wrote: > On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote: > > +linux-acpi > > > > Hi Michael, > > > > On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > > > So a new thinkpad: > > > 01:00.0 VGA compatible controller: NVIDIA Corporation GP107GLM

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 Thu, May 4, 2017 at 4:21 AM, Andy Shevchenko <andriy.shevchenko at linux.intel.com> wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use uuid_le type. At the same time we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion and it's safe to > get rid of it. > > The

On Wed, Nov 28, 2018 at 01:08:57PM +0200, Mika Westerberg wrote: > On Tue, Nov 27, 2018 at 09:49:44PM -0500, Michael S. Tsirkin wrote: > > On Tue, Nov 27, 2018 at 11:36:50AM +0200, Mika Westerberg wrote: > > > +linux-acpi > > > > > > Hi Michael, > > > > > > On Mon, Nov 26, 2018 at 10:53:26PM -0500, Michael S. Tsirkin wrote: > > >

On Thu, May 04, 2017 at 12:21:51PM +0300, Andy Shevchenko wrote: > diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c > index cbf7763d8091..420d51b286ad 100644 > --- a/drivers/iommu/dmar.c > +++ b/drivers/iommu/dmar.c > @@ -1808,10 +1808,9 @@ IOMMU_INIT_POST(detect_intel_iommu); > * for Directed-IO Architecture Specifiction, Rev 2.2, Section 8.8 > * "Remapping

acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 bytes. Instead we convert them to use uuid_le type. At the same time we convert current users. acpi_str_to_uuid() becomes useless after the conversion and it's safe to get rid of it. The conversion fixes a potential bug in int340x_thermal as well since we have to use memcmp() on binary data. Cc: Rafael J. Wysocki <rjw

Thanks, Lukas. I've incorporated your feedback into my local tree, but will wait for additional feedback from the individual DRM driver maintainers before sending out a series v2. On 8/8/20 5:11 PM, Lukas Wunner wrote: > On Mon, Jul 27, 2020 at 03:53:54PM -0500, Daniel Dadap wrote: >> + for (i = 0; i < num_dod_entries; i++) { >> + if (adr ==

These occurrences are largely benign these days and tainting the kernel for them is a bit aggressive. Mostly they relate to failing to setup perf which I think we are all aware is something which needs attention on the Xen/pvops side. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 974a528..55e3cc7 100644 ---

Signed-off-by: Yan Zheng <zheng.yan@oracle.com> --- diff -urp btrfs-progs-unstable/btrfsck.c btrfs-progs-2/btrfsck.c --- btrfs-progs-unstable/btrfsck.c 2009-09-28 15:54:55.980479398 +0800 +++ btrfs-progs-2/btrfsck.c 2010-01-31 09:46:24.645485459 +0800 @@ -581,7 +581,6 @@ again: } ret = insert_existing_cache_extent(dst, &ins->cache); if (ret == -EEXIST) { - WARN_ON(src ==

Hello fellows! Signal finally goes through ION's HDMI, however # chvt from 5 "graphical" to 3 "textual", and then at the very end of reboot, WARN emerges: ... nouveau 0000:01:00.0: DRM: EVO timeout ------------[ cut here ]------------ WARNING: CPU: 1 PID: 701 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] Modules linked in: ... nouveau

------------[ cut here ]------------ WARNING: CPU: 3 PID: 692 at drivers/gpu/drm/nouveau/nouveau_bo.c:137 nouveau_bo_del_ttm+0x7f/0x90 [nouveau] Modules linked in: ... nouveau mxm_wmi video i2c_algo_bit ttm drm_kms_helper drm wmi ... CPU: 3 PID: 692 Comm: Xorg Not tainted 4.10.8-1002.fc24.x86_64 #1 ... Call Trace: dump_stack+0x63/0x86 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20

This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2

From: Lyude Paul <lyude at redhat.com> [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul

Hi Greg, This feels like it's missing a From: line. commit b513a18cf1d705bd04efd91c417e79e4938be093 Author: Lyude Paul <lyude at redhat.com> Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly? Cheers, -ilia