Re: [Nouveau] [PATCH] drm/nouveau/acr: fix a couple NULL vs IS_ERR() checks

2021-11-18 Thread Ben Skeggs
On Thu, 18 Nov 2021 at 21:13, Dan Carpenter wrote: > > The nvkm_acr_lsfw_add() function never returns NULL. It returns error > pointers on error. > > Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace > "secure boot"") > Signed-off-b

Re: [Nouveau] [PATCH] drm/nouveau: recognise GA106

2021-11-18 Thread Ben Skeggs
On Fri, 19 Nov 2021 at 00:14, Karol Herbst wrote: > > Cc: stable? Yeah, that probably makes sense actually. > > On Thu, Nov 18, 2021 at 4:04 AM Ben Skeggs wrote: > > > > From: Ben Skeggs > > > > I've got HW now, appears to work as expected so fa

[Nouveau] [PATCH] drm/nouveau: recognise GA106

2021-11-17 Thread Ben Skeggs
From: Ben Skeggs I've got HW now, appears to work as expected so far. Signed-off-by: Ben Skeggs --- .../gpu/drm/nouveau/nvkm/engine/device/base.c | 22 +++ 1 file changed, 22 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c b/drivers/gpu/drm

Re: [Nouveau] [PATCH] MAINTAINERS: update information for nouveau

2021-11-10 Thread Ben Skeggs
ave push access to drm-misc > (where changes are pushed to after landing in gitlab) and are known > nouveau developers. > We did this already for some trivial changes and critical bug fixes > already, we just weren't thinking about updating the MAINTAINERS file. > > Cc: Ben Skeggs >

Re: [Nouveau] [PATCH] drm/nouveau: set RGB quantization range to FULL

2021-11-10 Thread Ben Skeggs
ctly. Now displays that advertise RGB Selectable > Quantization Range in their EDID will understand that full range is > transmitted > by the HDMI output. This is consistent to how the Nvidia's driver behaves. > > Signed-off-by: Hans Verkuil Reviewed-by: Ben Skeggs > --- > diff --git a/

Re: [Nouveau] [PATCH] drm/nouveau: hdmigv100.c: fix corrupted HDMI Vendor InfoFrame

2021-11-10 Thread Ben Skeggs
in the HDMI Vendor > InfoFrame when transmitting 4kp30. > > Signed-off-by: Hans Verkuil > Fixes: 290ffeafcc1a (drm/nouveau/disp/gv100: initial support) Reviewed-by: Ben Skeggs > --- > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdmigv100.c > b/drivers/gpu/drm/nouve

[Nouveau] [PATCH] ce/gf100: fix incorrect CE0 address calculation on some GPUs

2021-11-02 Thread Ben Skeggs
From: Ben Skeggs The code which constructs the modules for each engine present on the GPU passes -1 for 'instance' on non-instanced engines, which affects how the name for a sub-device is generated. This is then stored as 'instance 0' in nvkm_subdev.inst, so code can potentially be shared

Re: [Nouveau] [PATCH v1 2/7] nouveau: ACPI: Use the ACPI_COMPANION() macro directly

2021-10-12 Thread Ben Skeggs
so it is way more > straightforward to evaluate the latter directly instead of passing > the handle produced by the former to acpi_bus_get_device(). > > Modify nouveau_acpi_edid() accordingly (no intentional functional > impact). > > Signed-off-by: Rafael J. Wysocki Reviewed-by: Ben Sk

Re: [Nouveau] [PATCH] drm/nouveau/mmu/gp100: remove unused variable

2021-10-12 Thread Ben Skeggs
00-: drop unneeded assignment in the > if condition.") > Signed-off-by: Karol Herbst Reviewed-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/

Re: [Nouveau] [PATCH] drm/nouveau/fifo: Reinstate the correct engine bit programming

2021-10-07 Thread Ben Skeggs
On Fri, 8 Oct 2021 at 07:46, Karol Herbst wrote: > > Reviewed-by: Karol Herbst Reviewed-by: Ben Skeggs > > I haven't checked if other places need fixing up yet, and I still want > to test this patch, but I won't get to it until Monday. But if > everything is in place we c

Re: [Nouveau] RTX 3070 / NV174 / GA104 - is there any development happening?

2021-09-01 Thread Ben Skeggs
On Thu, 2 Sept 2021 at 08:25, Karol Herbst wrote: > > On Wed, Sep 1, 2021 at 11:19 PM Przemo Firszt wrote: > > > > Hi, > > > > Can you advise if there is any work happening on NV174 / GA104 (market > > name RTX 3070)? I checked the features matrix and searched the code of > > kernel, mesa,

Re: [Nouveau] 5.12.1 0010:nvkm_falcon_v1_wait_for_halt+0x8f/0xb9 [nouveau]

2021-05-24 Thread Ben Skeggs
On Fri, 7 May 2021 at 00:50, Bjorn Helgaas wrote: > > [+cc Ben] > > Hi Marc, > > Thanks for paying attention to these things. I added Ben (who > probably would see this via nouveau@lists.freedesktop.org anyway). > I don't see a PCI issue here, but the nouveau timeout, which I know > nothing

Re: [Nouveau] [PATCH v8 8/8] nouveau/svm: Implement atomic SVM access

2021-05-20 Thread Ben Skeggs
notifiers to revoke the atomic access. The original page table > entries are then restored allowing CPU access to proceed. > > Signed-off-by: Alistair Popple The Nouveau bits at least look good to me. For patches 7/8: Reviewed-by: Ben Skeggs > > --- > > v7: > * Removed magic v

Re: [Nouveau] [PATCH] drm/nouveau/kms/nv04: use vzalloc for nv04_display

2021-03-24 Thread Ben Skeggs
On Mon, 8 Mar 2021 at 03:49, Ilia Mirkin wrote: > > The struct is giant, and triggers an order-7 allocation (512K). There is > no reason for this to be kmalloc-type memory, so switch to vmalloc. This > should help loading nouveau on low-memory and/or long-running systems. > > Reported-by: Nathan

Re: [Nouveau] [PATCH] nouveau/nvkm/subdev/devinit/mcp89.c:Unneeded variable

2021-03-24 Thread Ben Skeggs
On Wed, 17 Mar 2021 at 19:51, ChunyouTang wrote: > > From: tangchunyou > > disable,delete disable and return 0 > > Signed-off-by: tangchunyou Thanks! > --- > drivers/gpu/drm/nouveau/nvkm/subdev/devinit/mcp89.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git

Re: [Nouveau] [PATCH v2] drm/nouveau/kms/nv50-: Correct size checks for cursors

2021-03-24 Thread Ben Skeggs
On Fri, 19 Mar 2021 at 09:04, Lyude Paul wrote: > > Found this while trying to make some changes to the kms_cursor_crc test. > curs507a_acquire checks that the width and height of the cursor framebuffer > are equal (asyw->image.{w,h}). This isn't entirely correct though, as the > height of the

Re: [Nouveau] [PATCH -next] drm/nouveau/core/client: Mark nvkm_uclient_sclass with static keyword

2021-03-24 Thread Ben Skeggs
On Tue, 23 Mar 2021 at 17:03, Zou Wei wrote: > > Fix the following sparse warning: > > drivers/gpu/drm/nouveau/nvkm/core/client.c:64:1: warning: symbol > 'nvkm_uclient_sclass' was not declared. Should it be static? > > Signed-off-by: Zou Wei Applied, thanks. > --- >

Re: [Nouveau] [PATCH] drm/nouveau: bail out of nouveau_channel_new if channel init fails

2020-11-15 Thread Ben Skeggs
On Mon, 16 Nov 2020 at 05:19, Karol Herbst wrote: > > On Sun, Nov 15, 2020 at 6:43 PM Salvatore Bonaccorso > wrote: > > > > Hi, > > > > On Fri, Aug 28, 2020 at 11:28:46AM +0200, Frantisek Hrbata wrote: > > > Unprivileged user can crash kernel by using > > > DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC > >

Re: [Nouveau] [PATCH 1/8] drm/nouveau/kms/nv50-: Use atomic encoder callbacks everywhere

2020-11-13 Thread Ben Skeggs
I've merged all of these. Sent the first to 5.10-fixes for the regression there, the rest will go in with a later -next pull request. Thanks, Ben. On Sat, 14 Nov 2020 at 10:14, Lyude Paul wrote: > > It turns out that I forgot to go through and make sure that I converted all > encoder callbacks

Re: [Nouveau] [PATCH] drm/nouveau: Fix out-of-bounds access when deferencing MMU type

2020-11-11 Thread Ben Skeggs
785646] __kmalloc_track_caller+0x1be/0x390 > >>> [ 18.792165] kstrdup_const+0x46/0x70 > >>> [ 18.797686] kobject_set_name_vargs+0x2f/0xb0 > >>> [ 18.803992] kobject_init_and_add+0x9d/0xf0 > >>> [ 18.810117] ttm_mem_global_init+0x12c/0x210 [ttm]

Re: [Nouveau] [RFC] gem: fix "refcount_t: underflow; use-after-free"

2020-10-06 Thread Ben Skeggs
On Wed, 7 Oct 2020 at 08:08, Karol Herbst wrote: > > we can't use nouveau_bo_ref here as no ttm object was allocated and > nouveau_bo_ref mainly deals with that. Simply deallocate the object. I suspect this was fallout from when that whole process was split into stages, seems reasonable to me,

Re: [Nouveau] [PATCH] drm/nouveau: Drop mutex_lock_nested for atomic

2020-09-30 Thread Ben Skeggs
On Wed, 30 Sep 2020 at 19:37, Daniel Vetter wrote: > > On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote: > > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter wrote: > > > > > > On Thu, Sep 17, 2020 at 3:15 PM Daniel Vetter > > > wrote: > > &

Re: [Nouveau] [PATCH] drm/nouveau: Drop mutex_lock_nested for atomic

2020-09-29 Thread Ben Skeggs
ith atomic: With atomic the bo pinning and > > > > actual modeset commit is completely separated in the code patsh. > > > > > > > > This annotation was originally added in > > > > > > > > commit 060810d7abaabcab282e062c595871d661561400 > > &g

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

2020-09-09 Thread Ben Skeggs
On Thu, 10 Sep 2020 at 00:07, Jeremy Cline wrote: > > On Wed, Sep 09, 2020 at 10:22:14AM +0200, Karol Herbst wrote: > > On Wed, Sep 9, 2020 at 6:06 AM Ben Skeggs wrote: > > > > > > On Thu, 13 Aug 2020 at 06:50, Jeremy Cline wrote: > > > > > > &

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

2020-09-08 Thread Ben Skeggs
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 report temperatures in 1 degree Celsius > increments via

Re: [Nouveau] [PATCH v5 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-09-07 Thread Ben Skeggs
On Sat, 5 Sep 2020 at 06:28, Lyude Paul wrote: > > Not entirely sure why this never came up when I originally tested this > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc > appears to cause the display engine to throw an exception on driver > init, at least on my ThinkPad

Re: [Nouveau] [PATCH v2] nouveau: fix the start/end range for migration

2020-09-02 Thread Ben Skeggs
On Tue, 1 Sep 2020 at 06:31, Ralph Campbell wrote: > > The user level OpenCL code shouldn't have to align start and end > addresses to a page boundary. That is better handled in the nouveau > driver. The npages field is also redundant since it can be computed > from the start and end addresses. >

Re: [Nouveau] [PATCH v4] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-09-02 Thread Ben Skeggs
On Wed, 2 Sep 2020 at 09:43, Lyude Paul wrote: > > Not entirely sure why this never came up when I originally tested this > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc > appears to cause the display engine to throw an exception on driver > init, at least on my ThinkPad

Re: [Nouveau] [PATCH 1/3] drm/ttm: make sure that we always zero init mem.bus v2

2020-09-02 Thread Ben Skeggs
On Wed, 2 Sep 2020 at 01:05, Christian König wrote: > > We are trying to remove the io_lru handling and depend > on zero init base, offset and addr here. > > v2: init addr as well Looks like the issues I noticed in the previous version have been dealt with, so, for the series: R

Re: [Nouveau] nouveau PUSHBUFFER_ERR on 5.9.0-rc2-next-20200824

2020-08-30 Thread Ben Skeggs
r0 & 0x001f) { > u32 chid = __ffs(intr0 & 0x001f) - 16; > nv50_disp_intr_error(disp, chid); > intr0 &= ~(0x0001 << chid); > } > ... > } > > Could this be in any way related to this series of commits? > commit 0a9609969

Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-08-30 Thread Ben Skeggs
On Wed, 26 Aug 2020 at 02:52, Lyude Paul wrote: > > On Tue, 2020-08-25 at 08:28 +1000, Ben Skeggs wrote: > > On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote: > > > Not entirely sure why this never came up when I originally tested this > > > (maybe some

Re: [Nouveau] [PATCH 1/2] drm/nouveau/kms/nv50-: Program notifier offset before requesting disp caps

2020-08-24 Thread Ben Skeggs
On Tue, 25 Aug 2020 at 04:33, Lyude Paul wrote: > > Not entirely sure why this never came up when I originally tested this > (maybe some BIOSes already have this setup?) but the ->caps_init vfunc > appears to cause the display engine to throw an exception on driver > init, at least on my ThinkPad

Re: [Nouveau] [RFC 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT

2020-08-11 Thread Ben Skeggs
ongle in before > plugging something into the dongle. > > So, let's fix this by checking the sink count in both > nouveau_dp_probe_dpcd() and nouveau_dp_irq(), and reprobing the > connector if things change. > > Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs > --- > dr

Re: [Nouveau] [RFC 20/20] drm/nouveau/kms: Start using drm_dp_read_dpcd_caps()

2020-08-11 Thread Ben Skeggs
gned-off-by: Lyude Paul Reviewed-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/nouveau_dp.c | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c > b/drivers/gpu/drm/nouveau/nouveau_dp.c > in

Re: [Nouveau] [RFC 10/20] drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps

2020-08-11 Thread Ben Skeggs
On Wed, 12 Aug 2020 at 06:06, Lyude Paul wrote: > > Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++- > 1 file changed, 3 insertions(+), 13 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_

Re: [Nouveau] [RFC 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()

2020-08-11 Thread Ben Skeggs
On Wed, 12 Aug 2020 at 06:05, Lyude Paul wrote: > > Signed-off-by: Lyude Paul Reviewed-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/nouveau_dp.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c > b

Re: [Nouveau] [PATCH 0/2] drm/nouveau: Small CRC fixes for 5.9

2020-08-10 Thread Ben Skeggs
On Tue, 11 Aug 2020 at 07:18, Lyude Paul wrote: > > Just two CRC related fixes for the new CRC functionality in 5.9. One of > these unbreaks CRC reporting on volta+, which accidentally got broken > when converting over to nvidia's class headers. The other simply removes > an unneeded CRC method

Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers

2020-07-28 Thread Ben Skeggs
On Wed, 29 Jul 2020 at 12:48, Dave Airlie wrote: > > On Tue, 28 Jul 2020 at 04:51, James Jones wrote: > > > > On 7/23/20 9:06 PM, Ben Skeggs wrote: > > > On Sat, 18 Jul 2020 at 13:34, James Jones wrote: > > >> > > >> Accept the DRM_FORMAT_

Re: [Nouveau] [PATCH v2] drm/nouveau: Accept 'legacy' format modifiers

2020-07-23 Thread Ben Skeggs
On Sat, 18 Jul 2020 at 13:34, James Jones wrote: > > Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() > family of modifiers to handle broken userspace > Xorg modesetting and Mesa drivers. Existing Mesa > drivers are still aware of only these older > format modifiers which do not differentiate >

Re: [Nouveau] [PATCH][next] drm/nouveau: Use fallthrough pseudo-keyword

2020-07-07 Thread Ben Skeggs
On Wed, 8 Jul 2020 at 03:31, Gustavo A. R. Silva wrote: > > Replace the existing /* fall through */ comments and its variants with > the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary > fall-through markings when it is the case. I really like this! I was not a fan of

Re: [Nouveau] [PATCH v3 3/5] nouveau: fix mapping 2MB sysmem pages

2020-07-07 Thread Ben Skeggs
On Thu, 2 Jul 2020 at 08:54, Ralph Campbell wrote: > > The nvif_object_ioctl() method NVIF_VMM_V0_PFNMAP wasn't correctly > setting the hardware specific GPU page table entries for 2MB sized > pages. Fix this by adding functions to set and clear PD0 GPU page > table entries. I can take this one

Re: [Nouveau] [PATCH v2] nouveau: fix page fault on device private memory

2020-06-28 Thread Ben Skeggs
gt; Cc: sta...@vger.kernel.org > Signed-off-by: Ralph Campbell > Reviewed-by: Jason Gunthorpe > --- > > This is based on Linux-5.8.0-rc2 and is for Ben Skeggs nouveau tree. > It doesn't depend on any of the other nouveau/HMM changes I have > recently posted. > > Resending t

Re: [Nouveau] [RESEND PATCH 1/3] nouveau: fix migrate page regression

2020-06-24 Thread Ben Skeggs
On Thu, 25 Jun 2020 at 15:23, Ben Skeggs wrote: > > On Tue, 23 Jun 2020 at 10:51, John Hubbard wrote: > > > > On 2020-06-22 16:38, Ralph Campbell wrote: > > > The patch to add zero page migration to GPU memory inadvertantly included > > > > inadvertently

Re: [Nouveau] [RESEND PATCH 1/3] nouveau: fix migrate page regression

2020-06-24 Thread Ben Skeggs
On Tue, 23 Jun 2020 at 10:51, John Hubbard wrote: > > On 2020-06-22 16:38, Ralph Campbell wrote: > > The patch to add zero page migration to GPU memory inadvertantly included > > inadvertently > > > part of a future change which broke normal page migration to GPU memory > > by copying too much

Re: [Nouveau] [PATCH] drm/noveau: fix reference count leak in nouveau_debugfs_strap_peek

2020-06-16 Thread Ben Skeggs
Thanks, I've grabbed this, and the others of the same sort you sent out at the same time. Ben. On Mon, 15 Jun 2020 at 17:29, Aditya Pakki wrote: > > nouveau_debugfs_strap_peek() calls pm_runtime_get_sync() that > increments the reference count. In case of failure, decrement the > ref count

Re: [Nouveau] [PATCH] drm/nouveau: gr/gk20a: Use firmware version 0

2020-06-03 Thread Ben Skeggs
On Thu, 4 Jun 2020 at 01:43, Emil Velikov wrote: > > On Wed, 3 Jun 2020 at 15:20, Thierry Reding wrote: > > > > From: Thierry Reding > > > > Tegra firmware doesn't actually use any version numbers and passing -1 > > causes the existing firmware binaries not to be found. Use version 0 to > >

Re: [Nouveau] [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

2020-05-31 Thread Ben Skeggs
On Mon, 1 Jun 2020 at 13:37, Ben Skeggs wrote: > > On Mon, 1 Jun 2020 at 13:27, wrote: > > > > > > Hi Ben, > > > > > > When gk20a_clk_ctor() returns an error code, pointer "clk" > > > > should be released. It's the same when gm

Re: [Nouveau] [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

2020-05-31 Thread Ben Skeggs
On Mon, 1 Jun 2020 at 13:27, wrote: > > > Hi Ben, > > > > When gk20a_clk_ctor() returns an error code, pointer "clk" > > > should be released. It's the same when gm20b_clk_new() > > > returns from elsewhere following this call. > > This shouldn't be necessary. If a subdev constructor fails, and

Re: [Nouveau] [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

2020-05-31 Thread Ben Skeggs
On Sat, 30 May 2020 at 19:42, Dinghao Liu wrote: > > When gk20a_clk_ctor() returns an error code, pointer "clk" > should be released. It's the same when gm20b_clk_new() > returns from elsewhere following this call. This shouldn't be necessary. If a subdev constructor fails, and returns a

Re: [Nouveau] [PATCH] nouveau/hmm: fix migrate zero page to GPU

2020-05-21 Thread Ben Skeggs
On Thu, 21 May 2020 at 07:05, Ralph Campbell wrote: > > > On 5/20/20 12:20 PM, Jason Gunthorpe wrote: > > On Wed, May 20, 2020 at 11:36:52AM -0700, Ralph Campbell wrote: > >> When calling OpenCL clEnqueueSVMMigrateMem() on a region of memory that > >> is backed by pte_none() or zero pages,

Re: [Nouveau] [PATCH v3 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes

2020-05-11 Thread Ben Skeggs
On Tue, 12 May 2020 at 09:06, Ilia Mirkin wrote: > > On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote: > > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c > > b/drivers/gpu/drm/nouveau/nouveau_connector.c > > index 43bcbb6d73c4..6dae00da5d7e 100644 > > ---

Re: [Nouveau] [PATCH] drm/nouveau: Fix regression by audio component transition

2020-04-29 Thread Ben Skeggs
Good catch! The OR is definitely a far better choice than the head here, as it's what we use to select the GPU-side HDA registers too. Merged. On Thu, 16 Apr 2020 at 17:54, Takashi Iwai wrote: > > Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component > notifier support"), the

Re: [Nouveau] [PATCH v3 1/3] device: rework mmio mapping code to get rid of second map

2020-04-29 Thread Ben Skeggs
Merged all 3 patches. Thanks! On Wed, 29 Apr 2020 at 02:55, Karol Herbst wrote: > > Fixes warnings on GPUs with smaller a smaller mmio region like vGPUs. > > Signed-off-by: Karol Herbst > --- > drm/nouveau/nvkm/engine/device/base.c | 27 +++ > 1 file changed, 15

Re: [Nouveau] [PATCH] drm/nouveau/mmu: Remove unneeded semicolon

2020-04-29 Thread Ben Skeggs
Thanks! On Fri, 24 Apr 2020 at 17:29, Zheng Bin wrote: > > Fixes coccicheck warning: > > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded semicolon > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded semicolon > > Reported-by: Hulk Robot > Signed-off-by: Zheng Bin

Re: [Nouveau] [PATCH 1/1] drm/nouveau: Use generic helper to check _PR3 presence

2020-04-29 Thread Ben Skeggs
Thanks! On Thu, 23 Apr 2020 at 17:37, Kai-Heng Feng wrote: > > 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:

Re: [Nouveau] [PATCH -next] drm/nouveau/acr: Use kmemdup instead of kmalloc and memcpy

2020-04-29 Thread Ben Skeggs
Thanks! On Wed, 22 Apr 2020 at 16:56, Zou Wei wrote: > > Fixes coccicheck warning: > > drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity > for kmemdup > drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity > for kmemdup > > Fixes:

Re: [Nouveau] [RFC v3 00/11] drm/nouveau: Introduce CRC support for gf119+

2020-04-24 Thread Ben Skeggs
On Sat, 18 Apr 2020 at 05:42, Lyude Paul wrote: > > Nvidia released some documentation on how CRC support works on their > GPUs, hooray! > > So: this patch series implements said CRC support in nouveau, along with > adding some special debugfs interfaces for some relevant igt-gpu-tools > tests

Re: [Nouveau] [PATCH v3 1/4] nouveau/hmm: fix vma range check for migration

2020-03-12 Thread Ben Skeggs
I've taken all 4 patches in my tree. Thanks Ralph, Ben. On Wed, 4 Mar 2020 at 10:14, Ralph Campbell wrote: > > find_vma_intersection(mm, start, end) only guarantees that end is greater > than or equal to vma->vm_start but doesn't guarantee that start is > greater than or equal to vma->vm_start.

Re: [Nouveau] [PATCH] drm/nouveau: remove checks for return value of debugfs functions

2020-02-18 Thread Ben Skeggs
On Wed, 19 Feb 2020 at 03:28, Wambui Karuga wrote: > > As there is no need to check for the return value of debugfs_create_file > and drm_debugfs_create_files, remove unnecessary checks and error > handling in nouveau_drm_debugfs_init. Thanks! > > Signed-off-by: Wambui Karuga > --- >

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-10 Thread Ben Skeggs
On Tue, 11 Feb 2020 at 09:17, James Jones wrote: > > On 2/10/20 12:25 AM, Thomas Zimmermann wrote: > > Hi > > > > Am 10.02.20 um 09:20 schrieb Ben Skeggs: > >> On Sat, 8 Feb 2020 at 07:10, James Jones wrote: > >>> > >>> I've sent ou

Re: [Nouveau] [PATCH] nouveau: no need to check return value of debugfs_create functions

2020-02-10 Thread Ben Skeggs
On Sun, 9 Feb 2020 at 22:56, Greg Kroah-Hartman wrote: > > When calling debugfs functions, there is no need to ever check the > return value. The function can work or not, but the code logic should > never do something different based on this. Thanks! > > Cc: Ben Skeggs

Re: [Nouveau] [PATCH 4/4] drm/nouveau: Remove struct nouveau_framebuffer

2020-02-10 Thread Ben Skeggs
On Sat, 8 Feb 2020 at 07:10, James Jones wrote: > > I've sent out a v4 version of the format modifier patches which avoid > caching values in the nouveau_framebuffer struct. It will have a few > trivial conflicts with your series, but should make them structurally > compatible. > > I'm fine with

Re: [Nouveau] [PATCH v4 09/22] drm/nouveau: Convert to CRTC VBLANK callbacks

2020-02-02 Thread Ben Skeggs
ff-by: Thomas Zimmermann Reviewed-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 3 +++ > drivers/gpu/drm/nouveau/dispnv50/head.c | 4 > drivers/gpu/drm/nouveau/nouveau_display.c | 14 ++ > drivers/gpu/drm/nouveau/nouveau_display.h | 4 ++-- &

Re: [Nouveau] [PATCH v4 08/22] drm/nouveau: Convert to struct drm_crtc_helper_funcs.get_scanout_position()

2020-02-02 Thread Ben Skeggs
ration > > Signed-off-by: Thomas Zimmermann Reviewed-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 1 + > drivers/gpu/drm/nouveau/dispnv50/head.c | 1 + > drivers/gpu/drm/nouveau/nouveau_display.c | 14 +++--- > drivers/gpu/drm/nouveau/nouveau

Re: [Nouveau] [PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver v2

2020-01-27 Thread Ben Skeggs
On Sat, 25 Jan 2020 at 00:30, Christian König wrote: > > From: Christian König > > While working on TTM cleanups I've found that the io_reserve_lru used by > Nouveau is actually not working at all. > > In general we should remove driver specific handling from the memory > management, so this

Re: [Nouveau] [PATCH 1/2] drm/nouveau: move io_reserve_lru handling into the driver v2

2020-01-25 Thread Ben Skeggs
On Sat, 25 Jan 2020 at 00:48, Roy Spliet wrote: > > Without diving in any of the details, your commit message has me curious > and concerned... In a "manager" kind of way, despite being neither a > manager nor an insider or active contributor. ;-) > > On 24/01/2020 14:30, Christian König wrote: >

Re: [Nouveau] [PATCH -next] drm/ttm: Remove set but not used variable 'mem'

2020-01-12 Thread Ben Skeggs
On Fri, 10 Jan 2020 at 17:32, YueHaibing wrote: > > drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new: > drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but > not used [-Wunused-but-set-variable] > drivers/gpu/drm/nouveau/nouveau_ttm.c: In

Re: [Nouveau] [PATCH] drm/nouveau: Fix copy-paste error in nouveau_fence_wait_uevent_handler

2020-01-12 Thread Ben Skeggs
On Fri, 10 Jan 2020 at 16:51, YueHaibing wrote: > > Like other cases, it should use rcu protected 'chan' rather > than 'fence->channel' in nouveau_fence_wait_uevent_handler. > > Fixes: 0ec5f02f0e2c ("drm/nouveau: prevent stale fence->channel pointers, and > protect with rcu") > Signed-off-by:

Re: [Nouveau] [PATCH] nouveau/secboot/gm20b: initialize pointer in gm20b_secboot_new()

2020-01-08 Thread Ben Skeggs
On Wed, 8 Jan 2020 at 15:46, Dan Carpenter wrote: > > We accidentally set "psb" which is a no-op instead of "*psb" so it > generates a static checker warning. We should probably set it before > the first error return so that it's always initialized. You actually don't need to do either, *psb

Re: [Nouveau] [PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers

2020-01-06 Thread Ben Skeggs
On Tue, 7 Jan 2020 at 05:17, James Jones wrote: > > On 1/5/20 5:30 PM, Ben Skeggs wrote: > > On Tue, 17 Dec 2019 at 10:44, James Jones wrote: > >> > >> This series modifies the NV5x+ nouveau display backends to advertise > >> appropriate format modifiers

Re: [Nouveau] [PATCH v2 0/3] drm/nouveau: Support NVIDIA format modifiers

2020-01-05 Thread Ben Skeggs
On Tue, 17 Dec 2019 at 10:44, James Jones wrote: > > This series modifies the NV5x+ nouveau display backends to advertise > appropriate format modifiers on their display planes in atomic mode > setting blobs. > > Corresponding modifications to Mesa/userspace are available here: > >

Re: [Nouveau] [PATCH v2 2/3] drm/nouveau: Check framebuffer size against bo

2020-01-05 Thread Ben Skeggs
On Tue, 17 Dec 2019 at 10:45, James Jones wrote: > > Make sure framebuffer dimensions and tiling > parameters will not result in accesses beyond the > end of the GEM buffer they are bound to. > > Signed-off-by: James Jones > --- > drivers/gpu/drm/nouveau/nouveau_display.c | 93

Re: [Nouveau] [PATCH] drm/nouveau: Add correct turing page kinds

2020-01-05 Thread Ben Skeggs
On Tue, 17 Dec 2019 at 10:57, James Jones wrote: > > Turing introduced a new simplified page kind > scheme, reducing the number of possible page > kinds from 256 to 16. It also is the first > NVIDIA GPU in which the highest possible page > kind value is not reserved as an "invalid" page > kind.

Re: [Nouveau] [PATCH v2] drm/nouveau: declare constants as unsigned long long.

2020-01-05 Thread Ben Skeggs
On Fri, 3 Jan 2020 at 05:29, Wambui Karuga wrote: > > Explicitly declare constants as unsigned long long to address the > following sparse warnings: > warning: constant is so big it is long > > v2: convert to unsigned long long for compatibility with 32-bit > architectures. > > Signed-off-by:

Re: [Nouveau] [PATCH -next] drm/nouveau/nv04: Use match_string() helper to simplify the code

2020-01-05 Thread Ben Skeggs
On Mon, 30 Dec 2019 at 12:48, YueHaibing wrote: > > match_string() returns the array index of a matching string. > Use it instead of the open-coded implementation. > > Signed-off-by: YueHaibing Thanks! > --- > drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 13 + > 1 file changed, 5

Re: [Nouveau] [PATCH] drm/nouveau: use NULL for pointer assignment.

2020-01-05 Thread Ben Skeggs
On Thu, 2 Jan 2020 at 04:51, Daniel Vetter wrote: > > On Tue, Dec 31, 2019 at 11:57:34PM +0300, Wambui Karuga wrote: > > Replace the use of 0 in the pointer assignment with NULL to address the > > following sparse warning: > > drivers/gpu/drm/nouveau/nouveau_hwmon.c:744:29: warning: Using plain

Re: [Nouveau] [PATCH] drm/nouveau: remove set but unused variable.

2020-01-05 Thread Ben Skeggs
On Thu, 2 Jan 2020 at 04:48, Daniel Vetter wrote: > > On Tue, Dec 31, 2019 at 11:56:07PM +0300, Wambui Karuga wrote: > > The local variable `pclks` is defined and set but not used and can > > therefore be removed. > > Issue found by coccinelle. > > > > Signed-off-by: Wambui Karuga > > --- > >

Re: [Nouveau] [PATCH] drm/dp_mst: add missed nv50_outp_release in nv50_msto_disable

2019-12-12 Thread Ben Skeggs
On Thu, 12 Dec 2019 at 18:14, Jani Nikula wrote: > > On Fri, 06 Dec 2019, Chuhong Yuan wrote: > > nv50_msto_disable() does not call nv50_outp_release() to match > > nv50_outp_acquire() like other disable(). > > Add the missed call to fix it. This is intentional, and it's called at a later time

Re: [Nouveau] [PATCH v3 0/9] drm/nouveau: Various fixes for GP10B

2019-12-10 Thread Ben Skeggs
On Mon, 9 Dec 2019 at 22:00, Thierry Reding wrote: > > From: Thierry Reding > > Hi Ben, > > here's a revised subset of the patches I had sent out a couple of weeks > ago. I've reworked the BAR2 accesses in the way that you had suggested, > which at least for GP10B turned out to be fairly trivial

Re: [Nouveau] [PATCH v2 0/9] drm/nouveau: Various fixes for GP10B

2019-11-19 Thread Ben Skeggs
On Mon, Nov 18, 2019 at 11:45 PM Thierry Reding wrote: > > On Sat, Nov 02, 2019 at 06:56:28PM +0100, Thierry Reding wrote: > > From: Thierry Reding > > > > Hi Ben, > > > > here's a revised subset of the patches I had sent out a couple of weeks > > ago. I've reworked the BAR2 accesses in the way

Re: [Nouveau] Is Nouveau really using the io_reserve_lru?

2019-09-26 Thread Ben Skeggs
On Tue, 24 Sep 2019 at 22:19, Christian König wrote: > > Hi guys, > > while working through more old TTM functionality I stumbled over the > io_reserve_lru. > > Basic idea is that when this flag is set the driver->io_mem_reserve() > callback can return -EAGAIN resulting in unmapping of other BOs.

Re: [Nouveau] [PATCH 03/11] drm/nouveau: secboot: Read WPR configuration from GPU registers

2019-09-17 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 18:40, Thierry Reding wrote: > > On Tue, Sep 17, 2019 at 01:49:57PM +1000, Ben Skeggs wrote: > > On Tue, 17 Sep 2019 at 01:04, Thierry Reding > > wrote: > > > > > > From: Thierry Reding > > > > > > The GPUs found

Re: [Nouveau] [PATCH v4 3/4] pci: set the pcie link speed to 8.0 when suspending

2019-09-17 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 18:28, Karol Herbst wrote: > > On Tue, Sep 17, 2019 at 10:21 AM Ben Skeggs wrote: > > > > On Tue, 17 Sep 2019 at 18:07, Karol Herbst wrote: > > > > > > On Tue, Sep 17, 2019 at 8:01 AM Ben Skeggs wrote: > > > > > >

Re: [Nouveau] [PATCH v4 3/4] pci: set the pcie link speed to 8.0 when suspending

2019-09-17 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 18:07, Karol Herbst wrote: > > On Tue, Sep 17, 2019 at 8:01 AM Ben Skeggs wrote: > > > > On Fri, 13 Sep 2019 at 21:33, Karol Herbst wrote: > > > > > > Apperantly things go south if we suspend the device with a PCIe link speed > >

Re: [Nouveau] [PATCH 0/2] drm/nouveau: Two more fixes

2019-09-17 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 00:36, Thierry Reding wrote: > > From: Thierry Reding > > Hi Ben, > > I messed up the ordering of patches in my tree a bit, so these two fixes > got separated from the others. I don't consider these particularily > urgent because the crash that the first one fixes only

Re: [Nouveau] [PATCH v4 3/4] pci: set the pcie link speed to 8.0 when suspending

2019-09-17 Thread Ben Skeggs
On Fri, 13 Sep 2019 at 21:33, Karol Herbst wrote: > > Apperantly things go south if we suspend the device with a PCIe link speed > set to 2.5. Fixes runtime suspend on my gp107. > > This all looks like some bug inside the pci subsystem and I would prefer a > fix there instead of nouveau, but

Re: [Nouveau] [PATCH v4 2/4] pci: add nvkm_pcie_get_speed

2019-09-16 Thread Ben Skeggs
On Fri, 13 Sep 2019 at 21:33, Karol Herbst wrote: > > v2: fixed compilation error Is there any need for this patch at all now, if you're forcing 8_0 rather than the pre-DEVINIT speed? > > Signed-off-by: Karol Herbst > Reviewed-by: Lyude Paul > --- > drm/nouveau/include/nvkm/subdev/pci.h | 1 +

Re: [Nouveau] [PATCH 1/3] pci: force disable ASPM before changing the link speed

2019-09-16 Thread Ben Skeggs
On Fri, 13 Sep 2019 at 05:00, Karol Herbst wrote: > > taken from nvgpu > > Signed-off-by: Karol Herbst > --- > drm/nouveau/nvkm/subdev/pci/g84.c | 9 + > drm/nouveau/nvkm/subdev/pci/g92.c | 1 + > drm/nouveau/nvkm/subdev/pci/g94.c | 1 + > drm/nouveau/nvkm/subdev/pci/gf100.c |

Re: [Nouveau] [PATCH 03/11] drm/nouveau: secboot: Read WPR configuration from GPU registers

2019-09-16 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 01:04, Thierry Reding wrote: > > From: Thierry Reding > > The GPUs found on Tegra SoCs have registers that can be used to read the > WPR configuration. Use these registers instead of reaching into the > memory controller's register space to read the same information. > >

Re: [Nouveau] [PATCH 2/6] drm/nouveau: fault: Widen engine field

2019-09-16 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote: > > From: Thierry Reding > > The engine field in the FIFO fault information registers is actually 9 > bits wide. Looks like this is true for fault buffer parsing too. > > Signed-off-by: Thierry Reding > --- >

Re: [Nouveau] [PATCH 1/6] drm/nouveau: fault: Store aperture in fault information

2019-09-16 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote: > > From: Thierry Reding > > The fault information register contains data about the aperture that > caused the failure. This can be useful in debugging aperture related > programming bugs. Should this be parsed for fault buffer entries too? >

Re: [Nouveau] [PATCH 3/6] drm/nouveau: Remove bogus gk20a aperture callback

2019-09-16 Thread Ben Skeggs
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote: > > From: Thierry Reding > > The gk20a (as well as all subsequent Tegra instantiations of the GPU) do > in fact use the same apertures as regular GPUs. Prior to gv11b there are > no checks in hardware for the aperture, so we get away with

Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node

2019-09-15 Thread Ben Skeggs
On Wed, 11 Sep 2019 at 07:53, Thierry Reding wrote: > > On Sat, Sep 07, 2019 at 09:58:46PM -0400, Ilia Mirkin wrote: > > On Wed, Aug 21, 2019 at 7:55 AM Thierry Reding > > wrote: > > > > > > On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > &

Re: [PATCH v7 1/9] drm_dp_cec: add connector info support.

2019-08-26 Thread Ben Skeggs
On Fri, Aug 16, 2019 at 4:10 AM Lyude Paul wrote: > > Reviewed-by: Lyude Paul Reviewed-by: Ben Skeggs > > On Wed, 2019-08-14 at 12:44 +0200, Dariusz Marcinkiewicz wrote: > > Pass the connector info to the CEC adapter. This makes it possible > > to a

Re: [Nouveau] [Intel-gfx] [PATCH v6 08/17] drm/ttm: use gem vma_node

2019-08-21 Thread Ben Skeggs
similar by splitting up nouveau_bo_new() > > into allocation and initialization steps, so that when necessary the GEM > > object can be initialized in between. I think that's slightly more > > flexible and easier to understand than a boolean flag. > > Yes, that should work too. > >

Re: [Nouveau] [PATCH] nouveau/hmm: map pages after migration

2019-08-16 Thread Ben Skeggs
e two sets of constants > >> supposed to be the same? Are the actual hardware values or just a > >> driver internal interface? > > > > It looks a bit odd to me too. > > I don't really know the structure/history of nouveau. > > Perhaps Ben Skeggs can s

Re: [Nouveau] [PATCH v2 0/2] drm/nouveau: CRTC Runtime PM ref tracking fixes

2019-08-12 Thread Ben Skeggs
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 51 + > drivers/gpu/drm/nouveau/dispnv50/disp.c | 38 +- > drivers/gpu/drm/nouveau/nouveau_drv.h | 3 -- > 3 files changed, 18 insertions(+), 74 deletions(-) For the series: Acked-by: Ben Skeggs > > -- > 2.21.0 > >

Re: [PATCH v2] drm/nouveau: Only recalculate PBN/VCPI on mode/connector changes

2019-08-12 Thread Ben Skeggs
t; Tested-by: Bohdan Milar > Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") > References: 412e85b60531 ("drm/nouveau: Only release VCPI slots on mode > changes") > Cc: Lyude Paul > Cc: Ben Skeggs > Cc: Daniel Vetter > Cc: David Air

Re: [Nouveau] [PATCH] drm/nouveau: Only release VCPI slots on mode changes

2019-08-01 Thread Ben Skeggs
; that VCPI allocations remain for as long as the CRTC is enabled. > > Signed-off-by: Lyude Paul > Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") > Cc: Lyude Paul > Cc: Ben Skeggs > Cc: Daniel Vetter > Cc: David Airlie > Cc: Jerry Zuo > Cc:

Re: [Nouveau] [PATCH] PCI: Use pci_reset_bus() in quirk_reset_lenovo_thinkpad_50_nvgpu()

2019-08-01 Thread Ben Skeggs
gt; Cc: Peter Wu > Cc: Ilia Mirkin > Cc: Karol Herbst > Cc: Maik Freudenberg > Cc: linux-...@vger.kernel.org > Signed-off-by: Lyude Paul Acked-by: Ben Skeggs > --- > drivers/pci/quirks.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/driv

  1   2   3   4   5   6   7   >