Re: [Nouveau] [PATCH 13/40] drm/nouveau/dispnv50/disp: Include header containing our prototypes

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv50/disp.c:2599:1: warning: no previous > prototype for ‘nv50_display_create’ [-Wmissing-prototypes] > > Cc: Be

Re: [PATCH 14/40] drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nouveau_ioc32.c:2: warning: Cannot understand * > file mga_ioc32.c > > Cc: Ben Skeggs > Cc: David Airlie &

Re: [Nouveau] [PATCH 16/40] drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nouveau_ioc32.c:52: warning: Function parameter or > member 'filp' not described in 'nouveau_compat_ioctl' > drive

Re: [Nouveau] [PATCH 15/40] drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nouveau_svm.c: In function ‘nouveau_pfns_map’: > drivers/gpu/drm/nouveau/nouveau_svm.c:810:6: warning: variable ‘ret’ set but > not used [-Wunused-but-set-variable]

Re: [Nouveau] [PATCH 12/40] drm/nouveau/nv50_display: Remove superfluous prototype for local static functions

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following build error: > > drivers/gpu/drm/nouveau/dispnv50/disp.c:2530:1: error: conflicting types for > ‘nv50_display_fini’ > In file included from drivers/gpu/drm/nouveau/

Re: [Nouveau] [PATCH 11/40] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous > prototype for ‘headc57d_olut’ [-Wmissing-prototypes] > > Cc: Be

Re: [Nouveau] [PATCH 10/40] drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function returning void

On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_cleanup’: > drivers/gpu/drm/nouveau/dispnv50/disp.c:1357:6: warning: variable ‘ret’ set > but not used

Re: [PATCH 09/40] drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:38 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv04/crtc.c:462: warning: Function parameter or > member 'crtc' not described in 'nv_crtc_mode_set_regs' > drive

Re: [Nouveau] [PATCH 07/40] drm/nouveau/nouveau_bo: Remove unused variables 'dev'

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nouveau_bo.c: In function ‘nouveau_ttm_tt_populate’: > drivers/gpu/drm/nouveau/nouveau_bo.c:1228:17: warning: var

Re: [Nouveau] [PATCH 05/40] drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c:53: warning: Function > parameter or member 'speedo' not described in 'gk20a_volt_get_cvb_volt

Re: [Nouveau] [PATCH 06/40] drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:992: warning: Function > parameter or member 'gr' not described in 'gf100_gr_wait_idle' > >

Re: [Nouveau] [PATCH 02/40] drm/nouveau/dispnv50/disp: Remove unused variable 'ret'

On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/dispnv50/disp.c:1381:6: warning: variable ‘ret’ set > but not used [-Wunused-but-set-variable] > not a big fan of just ignoring return codes, I'd rather see it

Re: [Nouveau] [PATCH 01/40] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc

Reviewed-by: Karol Herbst On Fri, Apr 16, 2021 at 4:37 PM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function > parameter or member 'init' not described in 'init_reserved' > drive

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

On Tue, Apr 13, 2021 at 1:17 PM Roy Spliet wrote: > > Op 13-04-2021 om 10:48 schreef Karol Herbst: > > On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet wrote: > >> > >> Op 13-04-2021 om 01:10 schreef Karol Herbst: > >>> On Mon, Apr 12, 2021 at 9:36 PM Ro

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

On Tue, Apr 13, 2021 at 10:24 AM Roy Spliet wrote: > > Op 13-04-2021 om 01:10 schreef Karol Herbst: > > On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet wrote: > >> > >> Hello Aaron, > >> > >> Thanks for your insights. A follow-up query and some observ

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

On Mon, Apr 12, 2021 at 9:36 PM Roy Spliet wrote: > > Hello Aaron, > > Thanks for your insights. A follow-up query and some observations in-line. > > Op 12-04-2021 om 20:06 schreef Aaron Plattner: > > On 4/10/21 1:48 PM, Roy Spliet wrote: > >> Op 10-04-2021 om 20:23 schreef Lukas Wunner: > >>> On

Re: [PATCH 14/19] drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static

ize != 1024) > -- > 2.27.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Reviewed-by: Karol Herbst

Re: [PATCH 12/19] drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers

* The clocks, CRTCs and outputs attached to this CRTC must be off. > -- > 2.27.0 > > _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > Reviewed-by: Karol Herbst

Re: [PATCH 19/19] drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block

* Called whenever a 32-bit process running under a 64-bit kernel > * performs an ioctl on /dev/dri/card. > * > -- > 2.27.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > Reviewed-by: Karol Herbst

Re: [PATCH 17/19] drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc

; * > * 32-bit ioctl compatibility routines for the MGA DRM. > -- > 2.27.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > Reviewed-by: Karol Herbst

Re: [PATCH 10/19] drm/nouveau/nouveau_bo: Remove unused variables 'dev'

> > if (slave) > return; > > drm = nouveau_bdev(bdev); > - dev = drm->dev->dev; > > return ttm_pool_free(>ttm.bdev.pool, ttm); > } > -- > 2.27.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Reviewed-by: Karol Herbst

Re: [PATCH 15/19] drm/nouveau/nv50_display: Remove superfluous prototype for local static functions

gt; _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Reviewed-by: Karol Herbst

Re: [PATCH 05/19] drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers

return mv; > } > > -/** > +/* > * cvb_t_mv = > * ((c2 * speedo / s_scale + c1) * speedo / s_scale + c0) + > * ((c3 * speedo / s_scale + c4 + c5 * T / t_scale) * T / t_scale) > -- > 2.27.0 > > _______ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > Reviewed-by: Karol Herbst

Re: [PATCH 09/19] drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header

___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > Reviewed-by: Karol Herbst

Re: [PATCH 01/19] drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc

Reviewed-by: Karol Herbst On Fri, Mar 19, 2021 at 9:24 AM Lee Jones wrote: > > Fixes the following W=1 kernel build warning(s): > > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c:584: warning: Function > parameter or member 'init' not described in 'init_reserved' > drive

Re: [Nouveau] nouveau regression post v5.8, still present in v5.10

fyi, there is a patch which solves a maybe related issue on your GPU, mind giving it a try before we dig further? https://gitlab.freedesktop.org/drm/nouveau/-/issues/14#note_767791 On Thu, Jan 21, 2021 at 3:33 AM Jamie Heilman wrote: > > Karol Herbst wrote: > > On Wed, Jan 6, 202

Re: [Nouveau] [PATCH] tracing: remove definition of DEBUG

Reviewed-by: Karol Herbst On Fri, Jan 15, 2021 at 11:51 PM wrote: > > From: Tom Rix > > Defining DEBUG should only be done in development. > So remove DEBUG. > > Signed-off-by: Tom Rix > --- > kernel/trace/trace_mmiotrace.c | 2 -- > 1 file changed, 2 deleti

[PATCH] drm/nouveau/svm: fail NOUVEAU_SVM_INIT ioctl on unsupported devices

Fixes a crash when trying to create a channel on e.g. Turing GPUs when NOUVEAU_SVM_INIT was called before. Fixes: eeaf06ac1a558 ("drm/nouveau/svm: initial support for shared virtual memory") Signed-off-by: Karol Herbst --- drivers/gpu/drm/nouveau/nouveau_svm.c | 4 1 file

[PATCH] drm/nouveau/svm: fail NOUVEAU_SVM_INIT ioctl on unsupported devices

Fixes a crash when trying to create a channel on e.g. Turing GPUs when NOUVEAU_SVM_INIT was called before. Fixes: eeaf06ac1a558 ("drm/nouveau/svm: initial support for shared virtual memory") Signed-off-by: Karol Herbst --- drivers/gpu/drm/nouveau/nouveau_svm.c | 4 1 file

Re: [Nouveau] nouveau regression post v5.8, still present in v5.10

On Wed, Jan 6, 2021 at 4:25 AM Jamie Heilman wrote: > > Jamie Heilman wrote: > > Jamie Heilman wrote: > > > Karol Herbst wrote: > > > > do you think you'd be able to do a kernel bisect in order to pinpoint > > > > the actual commit causing it? Thanks &

Re: [Nouveau] nouveau regression post v5.8, still present in v5.10

do you think you'd be able to do a kernel bisect in order to pinpoint the actual commit causing it? Thanks On Sun, Dec 27, 2020 at 8:16 PM Jamie Heilman wrote: > > Something between v5.8 and v5.9 has resulted in periodically losing video. > Unfortunately, I can't reliably reproduce it, it seems

Re: [Nouveau] [PATCH v2] ALSA: hda: Continue to probe when codec probe fails

On Tue, Dec 22, 2020 at 3:50 AM Kai-Heng Feng wrote: > > On Tue, Dec 22, 2020 at 1:56 AM Ilia Mirkin wrote: > > > > On Mon, Dec 21, 2020 at 11:33 AM Kai-Heng Feng > > wrote: > > > > > > [+Cc nouveau] > > > > > > On Fri, Dec 18, 2020 at 4:06 PM Takashi Iwai wrote: > > > [snip] > > > > > Quite

Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Thu, Nov 26, 2020 at 4:28 PM Geert Uytterhoeven wrote: > > Hi Miguel, > > On Thu, Nov 26, 2020 at 3:54 PM Miguel Ojeda > wrote: > > On Wed, Nov 25, 2020 at 11:44 PM Edward Cree wrote: > > > To make the intent clear, you have to first be certain that you > > > understand the intent;

Re: [Nouveau] [PATCH 2/3] drm/nouveau: manage nouveau_drm lifetime with devres

On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote: > > Make use of the devm_drm_dev_alloc() API to bind the lifetime of > nouveau_drm structure to the drm_device. This is important because a > reference to nouveau_drm is accessible from drm_device, which is > provided to a number of DRM layer

Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian

I sent a patch to the mailing list and wanted to have some review on that from at least Ben, but no idea if Ben already picked it and if it's good enough for sending it to stable yet.

Re: [Nouveau] [PATCH RFC] drm/nouveau: fix memory leak in nvkm_iccsense_oneinit

On Thu, Oct 15, 2020 at 6:32 PM Karol Herbst wrote: > > Ben, I think this is like the 5th patch tackling this issue, I think > we should merge one of those. > maybe I just confused that with reports, but it seems to turn up quite a bit and maybe I should have pushed more of it as wel

Re: [Nouveau] [PATCH RFC] drm/nouveau: fix memory leak in nvkm_iccsense_oneinit

Ben, I think this is like the 5th patch tackling this issue, I think we should merge one of those. On Thu, Oct 15, 2020 at 6:23 AM Keita Suzuki wrote: > > struct pw_rail_t is allocated as an array in function nvios_iccsense_parse, > and stored to a struct member of local variable. However, the

Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian

On Sat, Oct 10, 2020 at 12:23 AM Ilia Mirkin wrote: > > On Fri, Oct 9, 2020 at 5:54 PM Karol Herbst wrote: > > > > On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote: > > > > > > Hello, > > > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped work

Re: [Nouveau] nouveau broken on Riva TNT2 in 5.9.0-rc8: GPU not supported on big-endian

On Fri, Oct 9, 2020 at 11:35 PM Ondrej Zary wrote: > > Hello, > I'm testing 5.9.0-rc8 and found that Riva TNT2 stopped working: > [0.00] Linux version 5.9.0-rc8+ (zary@gsql) (gcc (Debian 8.3.0-6) > 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #326 SMP Fri Oct 9 22:31:40 > CEST 2020 >

[PATCH 2/2] drm/nouveau/mem: guard against NULL pointer access in mem_del

other drivers seems to do something similar Signed-off-by: Karol Herbst Cc: dri-devel Cc: Dave Airlie Cc: sta...@vger.kernel.org --- drivers/gpu/drm/nouveau/nouveau_mem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau

[PATCH 1/2] drm/nouveau/device: return error for unknown chipsets

Previously the code relied on device->pri to be NULL and to fail probing later. We really should just return an error inside nvkm_device_ctor for unsupported GPUs. Fixes: 24d5ff40a732 ("drm/nouveau/device: rework mmio mapping code to get rid of second map") Signed-off-by: Karol Her

Re: [PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter

On Thu, Sep 17, 2020 at 4:11 PM Jeremy Cline wrote: > > On Wed, Sep 16, 2020 at 10:03:22PM +0200, Karol Herbst wrote: > > On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst wrote: > > > > > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote: > > > >

Re: [PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter

On Wed, Sep 16, 2020 at 10:01 PM Karol Herbst wrote: > > On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote: > > > > The temp_get() function currently returns negative error numbers or a > > temperature. However, the thermal sensors can (in theory) measure > &g

Re: [PATCH v2 1/2] drm/nouveau: return temperatures in temp_get() via parameter

On Wed, Sep 16, 2020 at 9:47 PM Jeremy Cline wrote: > > The temp_get() function currently returns negative error numbers or a > temperature. However, the thermal sensors can (in theory) measure > negative temperatures. Some implementations of temp_get() correctly > clamp negative temperature

Re: [Nouveau] [PATCH] drm/nouveau: Add fine-grain temperature reporting

On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote: > > On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote: > > > > Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of > > new gp1xx temperature sensor") added support for reading finer-grain > > temperatures, but continued to

Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)

On Mon, Sep 7, 2020 at 10:58 PM Marc MERLIN wrote: > > On Mon, Sep 07, 2020 at 09:14:03PM +0200, Karol Herbst wrote: > > > - changes in the nouveau driver. Mika told me the PCIe regression > > > "pcieport :00:01.0: PME: Spurious native interrupt!" is s

Re: [Nouveau] pcieport 0000:00:01.0: PME: Spurious native interrupt (nvidia with nouveau and thunderbolt on thinkpad P73)

On Sun, Sep 6, 2020 at 8:52 PM Marc MERLIN wrote: > > Ok, I have an update to this problem. I added the nouveau list because > I can't quite tell if the issue is: > - the PCIe changes that went in 5.6 I think (or 5.5?), referenced below > > - a new issue with thunderbold on thinkpad P73, that

Re: [PATCH] drm/nouveau: Add fine-grain temperature reporting

Reviewed-by: Karol Herbst On Wed, Aug 12, 2020 at 10:50 PM Jeremy Cline wrote: > > Commit d32656373857 ("drm/nouveau/therm/gp100: initial implementation of > new gp1xx temperature sensor") added support for reading finer-grain > temperatures, but continued to report te

Re: [Nouveau] [PATCH] drm/nouveau/acr: fix a coding style in nvkm_acr_lsfw_load_bl_inst_data_sig()

Reviewed-by: Karol Herbst On Mon, Aug 3, 2020 at 5:46 AM Jing Xiangfeng wrote: > > This patch performs the following changes: > 1. remove a redundant parentheses around the nvkm_acr_lsfw_add() calls > 2. do assignment before this if condition, it is more readable > > S

Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg wrote: > > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote: > > On 7/21/20 10:27 AM, Mika Westerberg wrote: > > > On Tue, Jul 21, 2020 at 11:01:55AM -0400, Lyude Paul wrote: > > >> Sure thing. Also, feel free to let me know if

Re: [PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops

On Mon, Jul 20, 2020 at 3:19 AM Alex Hung wrote: > > On 2020-07-19 1:50 p.m., Karol Herbst wrote: > > On Fri, Jul 17, 2020 at 9:52 PM Alex Hung wrote: > >> > >> On 2020-07-17 1:05 p.m., Karol Herbst wrote: > >>> It's hard to figure out what sys

Re: [PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops

On Fri, Jul 17, 2020 at 9:52 PM Alex Hung wrote: > > On 2020-07-17 1:05 p.m., Karol Herbst wrote: > > It's hard to figure out what systems are actually affected and right now I > > don't see a good way of removing those... > > > > But I'd like to see thos getting rem

[PATCH] RFC: ACPI / OSI: remove workarounds for hybrid graphics laptops

can look into it and come up with a proper fix (and keep this patch out until we resolve all of those). Signed-off-by: Karol Herbst CC: Alex Hung CC: "Rafael J. Wysocki" CC: Len Brown CC: Lyude Paul CC: linux-kernel@vger.kernel.org CC: dri-de...@lists.freedesktop.or

Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

Filed at https://bugzilla.kernel.org/show_bug.cgi?id=208597 oddly enough I wasn't able to reproduce it on my XPS 9560, will ping once something breaks. On Fri, Jul 17, 2020 at 2:43 AM Karol Herbst wrote: > > On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote: > > > > [+

Re: nouveau regression with 5.7 caused by "PCI/PM: Assume ports without DLL Link Active train links in 100 ms"

On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote: > > [+cc Sasha -- stable kernel regression] > [+cc Patrick, Kai-Heng, LKML] > > On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote: > > On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote: >

Re: [git pull] drm for 5.8-rc1

On Wed, Jul 1, 2020 at 7:37 PM James Jones wrote: > > On 7/1/20 10:04 AM, Karol Herbst wrote: > > On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote: > >> > >> On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote: > >>> > >>> On 7/1/20 4:24 AM,

Re: [git pull] drm for 5.8-rc1

On Wed, Jul 1, 2020 at 6:01 PM Daniel Vetter wrote: > > On Wed, Jul 1, 2020 at 5:51 PM James Jones wrote: > > > > On 7/1/20 4:24 AM, Karol Herbst wrote: > > > On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: > > >> > > >> Thi

Re: [git pull] drm for 5.8-rc1

On Wed, Jul 1, 2020 at 6:45 AM James Jones wrote: > > This implies something is trying to use one of the old > DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifiers with DRM-KMS without > first checking whether it is supported by the kernel. I had tried to > force an Xorg+Mesa stack without my

Re: [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

On Tue, Oct 22, 2019 at 2:45 PM Mika Westerberg wrote: > > On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote: > > I think there is something I totally forgot about: > > > > When there was never a driver bound to the GPU, and if runtime power > > manageme

Re: [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

On Mon, Oct 21, 2019 at 4:09 PM Mika Westerberg wrote: > > On Mon, Oct 21, 2019 at 03:54:09PM +0200, Karol Herbst wrote: > > > I really would like to provide you more information about such > > > workaround but I'm not aware of any ;-) I have not seen any issues lik

Re: [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges

On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas wrote: > > [+cc linux-acpi] > > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote: > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the > > platform means of putting the device into D3cold, right?

Re: [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

On Tue, Oct 1, 2019 at 11:11 AM Mika Westerberg wrote: > > On Tue, Oct 01, 2019 at 10:56:39AM +0200, Karol Herbst wrote: > > On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg > > wrote: > > > > > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:

Re: [RFC PATCH] pci: prevent putting pcie devices into lower device states on certain intel bridges

On Tue, Oct 1, 2019 at 10:47 AM Mika Westerberg wrote: > > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote: > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg > > wrote: > > > > > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote: &

Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to enable dGPU direct output"

On Thu, Aug 15, 2019 at 4:30 PM wrote: > > > On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst wrote: > > > > > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher > > wrote: > > > > > > > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst > &

Re: [PATCH 1/5] drm/nouveau: Check backlight IDs are >= 0, not > 0

Patches 1-5 are Reviewed-by: Karol Herbst I think it might be worth to test those patches on a system without any backlight devices just to verify we don't break things, but the code looked good already, so maybe we don't really need to test. On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote

Re: [PATCH 1/5] drm/nouveau: Check backlight IDs are >= 0, not > 0

Patches 1-5 are Reviewed-by: Karol Herbst I think it might be worth to test those patches on a system without any backlight devices just to verify we don't break things, but the code looked good already, so maybe we don't really need to test. On Thu, Aug 23, 2018 at 3:21 AM, Lyude Paul wrote

Re: [Nouveau] [RFC v2 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

On Fri, Jan 26, 2018 at 4:35 AM, Lyude Paul wrote: > This adds support for enabling automatic clockgating on nvidia GPUs for > Kepler1. While this is not technically a clockgating level, it does > enable clockgating using the clockgating values initially set by the > vbios

Re: [Nouveau] [RFC v2 1/4] drm/nouveau: Add support for basic clockgating on Kepler1

On Fri, Jan 26, 2018 at 4:35 AM, Lyude Paul wrote: > This adds support for enabling automatic clockgating on nvidia GPUs for > Kepler1. While this is not technically a clockgating level, it does > enable clockgating using the clockgating values initially set by the > vbios (which should be safe

Re: [Nouveau] [PATCH] drm/nouveau/mmu: Fix trailing semicolon

Reviewed-by: Karol Herbst <kher...@redhat.com> On Wed, Jan 17, 2018 at 7:53 PM, Luis de Bethencourt <lui...@kernel.org> wrote: > The trailing semicolon is an empty statement that does no operation. > Removing it since it doesn't do anything. > > Signed-off-by:

Re: [Nouveau] [PATCH] drm/nouveau/mmu: Fix trailing semicolon

Reviewed-by: Karol Herbst On Wed, Jan 17, 2018 at 7:53 PM, Luis de Bethencourt wrote: > The trailing semicolon is an empty statement that does no operation. > Removing it since it doesn't do anything. > > Signed-off-by: Luis de Bethencourt > --- > > Hi, > >

Re: [tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

gt; >> On Tue, Dec 12, 2017 at 02:55:30AM -0800, tip-bot for Karol Herbst wrote: >> > Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687 >> > Gitweb: >> > https://git.kernel.org/tip/6d60ce384d1d5ca32b595244db4077a419acc687 >> > Author: Karol Herbst

Re: [tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

p-bot for Karol Herbst wrote: >> > Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687 >> > Gitweb: >> > https://git.kernel.org/tip/6d60ce384d1d5ca32b595244db4077a419acc687 >> > Author: Karol Herbst >> > AuthorDate: Mon, 27 Nov 2017 08:51:39

[tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687 Gitweb: https://git.kernel.org/tip/6d60ce384d1d5ca32b595244db4077a419acc687 Author: Karol Herbst <kher...@redhat.com> AuthorDate: Mon, 27 Nov 2017 08:51:39 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Mon, 11

[tip:x86/urgent] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

Commit-ID: 6d60ce384d1d5ca32b595244db4077a419acc687 Gitweb: https://git.kernel.org/tip/6d60ce384d1d5ca32b595244db4077a419acc687 Author: Karol Herbst AuthorDate: Mon, 27 Nov 2017 08:51:39 +0100 Committer: Ingo Molnar CommitDate: Mon, 11 Dec 2017 15:35:18 +0100 x86/mm/kmmio: Fix

Re: [Nouveau] [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings

Reviewed-by: Karol Herbst <kher...@redhat.com> On Thu, Nov 30, 2017 at 8:53 PM, Christoph Böhmwalder <christ...@boehmwalder.at> wrote: > The kbuild test bot complained about a new coccinelle warning nearby, > which sparked a discussion about the assignment to 'memory' inside of

Re: [Nouveau] [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings

Reviewed-by: Karol Herbst On Thu, Nov 30, 2017 at 8:53 PM, Christoph Böhmwalder wrote: > The kbuild test bot complained about a new coccinelle warning nearby, > which sparked a discussion about the assignment to 'memory' inside of > the conditional expression. See Link below for the

Re: [Nouveau] [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)

Hi julia, I think it would be better to extract the assignment out of the if clause. Then you'll get something like this: memory = ...; if (IS_ERR(memory)) { } so, to answer your question: no, it isn't necessary. On Tue, Nov 28, 2017 at 1:56 PM, Julia Lawall wrote:

Re: [Nouveau] [PATCH] drm/nouveau/mmu: fix odd_ptr_err.cocci warnings (fwd)

Hi julia, I think it would be better to extract the assignment out of the if clause. Then you'll get something like this: memory = ...; if (IS_ERR(memory)) { } so, to answer your question: no, it isn't necessary. On Tue, Nov 28, 2017 at 1:56 PM, Julia Lawall wrote: > This is a false

[PATCH] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

<ly...@redhat.com> Signed-off-by: Karol Herbst <kher...@redhat.com> --- arch/x86/mm/ioremap.c | 4 ++-- arch/x86/mm/kmmio.c | 12 +++- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c index 34f0e1847dd6..5d4c358778dd 100644

[PATCH] x86/mm/kmmio: Fix mmiotrace for page unaligned addresses

Rostedt Cc: Ingo Molnar Cc: Thomas Gleixner Cc: Pekka Paalanen Cc: nouv...@lists.freedesktop.org Cc: x...@kernel.org Acked-by: Pekka Paalanen Tested-by: Lyude Signed-off-by: Karol Herbst --- arch/x86/mm/ioremap.c | 4 ++-- arch/x86/mm/kmmio.c | 12 +++- 2 files changed, 9 insertions

Re: [Nouveau] [PATCH] [RESEND] drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

On Wed, Sep 6, 2017 at 10:11 PM, Arnd Bergmann <a...@arndb.de> wrote: > On Wed, Sep 6, 2017 at 4:20 PM, Karol Herbst <karolher...@gmail.com> wrote: >>> In this instance, I think using multiplication is more intuitive >>> than '&&', so I'm addin

Re: [Nouveau] [PATCH] [RESEND] drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

On Wed, Sep 6, 2017 at 10:11 PM, Arnd Bergmann wrote: > On Wed, Sep 6, 2017 at 4:20 PM, Karol Herbst wrote: >>> In this instance, I think using multiplication is more intuitive >>> than '&&', so I'm adding a comparison to zero instead to shut up >>> the warn

Re: [Nouveau] [PATCH] [RESEND] drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

On Wed, Sep 6, 2017 at 3:56 PM, Arnd Bergmann wrote: > gcc thinks that interpreting a multiplication result as a bool > is confusing: > > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in

Re: [Nouveau] [PATCH] [RESEND] drm/nouveau/clk: fix gcc-7 -Wint-in-bool-context warning

On Wed, Sep 6, 2017 at 3:56 PM, Arnd Bergmann wrote: > gcc thinks that interpreting a multiplication result as a bool > is confusing: > > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c: In function 'read_pll': > drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:133:8: error: '*' in boolean >

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we could convert to WARN_ONCE? Reviewed-By: Karol Herbst <karolher...@gmail.com> On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de> wrote: > On 7/14/17 3:41 PM, Mike

Re: [Nouveau] [regression drm/noveau] suspend to ram -> BOOM: exception RIP: drm_calc_vbltimestamp_from_scanoutpos+335

Yeah, we shouldn't let the machine die. Are there more WARN_ON_ONCE usage we could convert to WARN_ONCE? Reviewed-By: Karol Herbst On Fri, Jul 14, 2017 at 5:05 PM, Tobias Klausmann wrote: > On 7/14/17 3:41 PM, Mike Galbraith wrote: >> >> On Fri, 2017-07-14 at 15:36 +0200, Mike

Re: [PATCH] drm/nouveau: Add support for clockgating on Fermi+

Hi Lyude, thanks for the great work. Just a view comments inline. 2017-04-25 20:38 GMT+02:00 Lyude : > This adds support for enabling automatic clockgating on nvidia GPUs for > Fermi and later generations. This saves a little bit of power, bringing > my fermi GPU's power

Re: [PATCH] drm/nouveau: Add support for clockgating on Fermi+

Hi Lyude, thanks for the great work. Just a view comments inline. 2017-04-25 20:38 GMT+02:00 Lyude : > This adds support for enabling automatic clockgating on nvidia GPUs for > Fermi and later generations. This saves a little bit of power, bringing > my fermi GPU's power consumption from ~28.3W

Re: [Nouveau] [PATCH] drm/nouveau: fix unknown chipset for GTX 1060

we already have that included in 4.10 2016-12-12 12:26 GMT+01:00 Chris Chiu : > Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it > only gives VGA resolution on screen. Use the same chipset as nv134 > then it shows FullHD. This commit copies fields from

Re: [Nouveau] [PATCH] drm/nouveau: fix unknown chipset for GTX 1060

we already have that included in 4.10 2016-12-12 12:26 GMT+01:00 Chris Chiu : > Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it > only gives VGA resolution on screen. Use the same chipset as nv134 > then it shows FullHD. This commit copies fields from nv134_chipset > to

Re: mmiotracer hangs the system

sorry for that, but I forgot the patch 2016-11-19 11:56 GMT+01:00 Karol Herbst <karolher...@gmail.com>: > this is odd, I found a bug related to nouveau (modprobe/bind doesn't > return), but that isn't related to your issue at all or maybe it is > exactly this, cause the bindin

Re: mmiotracer hangs the system

sorry for that, but I forgot the patch 2016-11-19 11:56 GMT+01:00 Karol Herbst : > this is odd, I found a bug related to nouveau (modprobe/bind doesn't > return), but that isn't related to your issue at all or maybe it is > exactly this, cause the binding of the device doesn

Re: mmiotracer hangs the system

;: > On Fri, Oct 14, 2016 at 12:12 AM, Karol Herbst <karolher...@gmail.com> wrote: >> sorry for the delay fixing that bug. I got occupied with other things >> and didn't really got to the issue again, it is on my todo list as the >> next item though and I hope I will be ab

Re: mmiotracer hangs the system

ight know where the issue is, but didn't confirm >> it yet. > > Thanks.I'm still using revert. Feel free to Cc me when you will have > some material to test. > >> >> Again, sorry for the delay. >> >> Karol >> >> 2016-08-19 22:46 GMT+02:00 Karol Herbst

Re: [Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

2016-11-08 17:12 GMT+01:00 Arnd Bergmann : > On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: >> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: >> > The underlying problem is that we already have a number of other >> > symbols that either have "depends

Re: [Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

2016-11-08 17:12 GMT+01:00 Arnd Bergmann : > On Tuesday, November 8, 2016 5:07:01 PM CET Lukas Wunner wrote: >> On Tue, Nov 08, 2016 at 04:52:49PM +0100, Arnd Bergmann wrote: >> > The underlying problem is that we already have a number of other >> > symbols that either have "depends on LEDS_CLASS"

Re: [Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

2016-11-08 16:46 GMT+01:00 Ilia Mirkin : > On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote: >> The newly introduced LED handling for nouveau fails to link when the >> driver is built-in but the LED subsystem is a loadable module: >> >>

Re: [Nouveau] [PATCH] drm/nouveau: fix LEDS_CLASS=m configuration

2016-11-08 16:46 GMT+01:00 Ilia Mirkin : > On Tue, Nov 8, 2016 at 8:56 AM, Arnd Bergmann wrote: >> The newly introduced LED handling for nouveau fails to link when the >> driver is built-in but the LED subsystem is a loadable module: >> >> drivers/gpu/drm/nouveau/nouveau.o: In function

Re: [Nouveau] noveau: emergency shutdown handling is overcomplex and broken

Thanks for the pointer. But I don't like this patch. If you find a bug, make a bug report or just fix it if you know the fix already. Or write something in IRC. Or write on the Mailing list as a general question or something else But I really don't agree on doing it this way. You would have

Re: [Nouveau] noveau: emergency shutdown handling is overcomplex and broken

Thanks for the pointer. But I don't like this patch. If you find a bug, make a bug report or just fix it if you know the fix already. Or write something in IRC. Or write on the Mailing list as a general question or something else But I really don't agree on doing it this way. You would have

  1   2   >