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

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: [PATCH v2] drm/nouveau/kms/nv50-: Correct size checks for cursors

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

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: [PATCH v2] drm/nouveau/pmu: fix timeout on GP108

On Wed, 17 Feb 2021 at 13:30, Alexandre Courbot wrote: > > On Wed, Feb 17, 2021 at 1:20 AM Diego Viola wrote: > > > > This code times out on GP108, probably because the BIOS puts it into a > > bad state. > > > > Since we reset the PMU on driver load anyway, we are at no risk from > > missing a

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

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: Add fine-grain temperature reporting

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

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

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

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

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 PUSHBUFFER_ERR on 5.9.0-rc2-next-20200824

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

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

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: [RFC 17/20] drm/nouveau/kms/nv50-: Add support for DP_SINK_COUNT

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()

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: [RFC 10/20] drm/nouveau/kms: Use new drm_dp_has_mst() helper for checking MST caps

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: [RFC 01/20] drm/nouveau/kms: Fix some indenting in nouveau_dp_detect()

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: [git pull] drm next for 5.9-rc1

On Tue, 11 Aug 2020 at 04:46, Dave Airlie wrote: > > On Mon, 10 Aug 2020 at 22:23, Christoph Hellwig wrote: > > > > On Thu, Aug 06, 2020 at 11:07:02AM +1000, Dave Airlie wrote: > > > nouveau: > > > - add CRC support > > > - start using NVIDIA published class header files > > > > Where does Nvdia

Re: linux-next: manual merge of the hmm tree with the drm tree

On Tue, Aug 4, 2020 at 9:19 AM Jason Gunthorpe wrote: > > On Thu, Jul 30, 2020 at 10:31:45AM -0700, Ralph Campbell wrote: > > > > On 7/30/20 5:03 AM, Jason Gunthorpe wrote: > > > On Thu, Jul 30, 2020 at 07:21:10PM +1000, Stephen Rothwell wrote: > > > > Hi all, > > > > > > > > Today's linux-next

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

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

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

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

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

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: [PATCH] drm/noveau: fix reference count leak in nouveau_debugfs_strap_peek

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: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

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: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

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: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new

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: drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for 'lsb_header_tail_dump'

On Sat, May 30, 2020 at 7:00 AM kbuild test robot wrote: > > Hi Ben, > > FYI, the error/warning still remains. Thanks, I've got a patch in my tree. Ben. > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 75caf310d16cc5e2f851c048cd597f5437013368 >

Re: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:2019:1: warning: no previous prototype for 'gf100_gr_dtor'

;> previous prototype for 'gf100_gr_dtor' [-Wmissing-prototypes] > 2019 | gf100_gr_dtor(struct nvkm_gr *base) > | ^ > > vim +/gf100_gr_dtor +2019 drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c > > 89cd6e2071b3d3b Alexandre Courbot 2016-12-13 2017 > c85ee6ca79590cd Ben S

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

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: [PATCH v3 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes

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

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: [PATCH 1/1] drm/nouveau: Use generic helper to check _PR3 presence

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: [PATCH -next] drm/nouveau/acr: Use kmemdup instead of kmalloc and memcpy

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] [PATCH -next] drm/nouveau/dmem: remove set but not used variable 'drm'

On Thu, 21 Feb 2019 at 13:41, YueHaibing wrote: > > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/gpu/drm/nouveau/nouveau_dmem.c: In function 'nouveau_dmem_free': > drivers/gpu/drm/nouveau/nouveau_dmem.c:103:22: warning: > variable 'drm' set but not used [-Wunused-but-set-variable]

Re: [Nouveau] [PATCH v3 4/4] drm/nouveau: Move PBN and VCPI allocation into nv50_head_atom

e1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") > Cc: Daniel Vetter Reviewed-by: Ben Skeggs > --- > drivers/gpu/drm/nouveau/dispnv50/atom.h | 6 ++ > drivers/gpu/drm/nouveau/dispnv50/disp.c | 28 +++-- > drivers/gpu/drm/nouve

Re: [Nouveau] [PATCH] drm/nouveau: mark expected switch fall-through

Got it, thanks. On Wed, 30 Jan 2019 at 06:55, Gustavo A. R. Silva wrote: > > In preparation to enabling -Wimplicit-fallthrough, mark switch cases > where we are expecting to fall through. > > This patch fixes the following warning: > > drivers/gpu/drm/nouveau/nouveau_bo.c:1434:53: warning: this

Re: [PATCH] drm/nouveau/bios/dp: make array vsoff static, shrinks object size

On Fri, Jan 25, 2019 at 3:26 AM Colin Ian King wrote: > > ping? I've pushed this, and the others you pinged about, to my tree. Thank you, Ben. > > On 04/09/2018 16:23, Colin King wrote: > > From: Colin Ian King > > > > Don't populate the array vsoff on the stack but instead make it > > static.

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

On Thu, May 24, 2018 at 8:48 AM, Kees Cook <keesc...@chromium.org> wrote: > On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook <keesc...@chromium.org> wrote: >> On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs <skeg...@gmail.com> wrote: >>> On 14 March 2018 at 21:08, Thie

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

On Thu, May 24, 2018 at 8:48 AM, Kees Cook wrote: > On Thu, Apr 26, 2018 at 4:25 PM, Kees Cook wrote: >> On Thu, Mar 15, 2018 at 7:05 PM, Ben Skeggs wrote: >>> On 14 March 2018 at 21:08, Thierry Reding wrote: >>>> On Tue, Mar 13, 2018 at 11:24:11AM -0

Re: [PATCH] gpu: drm: nouveau: Use list_for_each_entry_from_reverse

On 27 March 2018 at 19:11, Arushi Singhal wrote: > It's better to use "list_for_each_entry_from_reverse" for iterating list > than "for loop" as it makes the code more clear to read. > This patch replace "for loop" with "list_for_each_entry_from_reverse" > and

Re: [PATCH] gpu: drm: nouveau: Use list_for_each_entry_from_reverse

On 27 March 2018 at 19:11, Arushi Singhal wrote: > It's better to use "list_for_each_entry_from_reverse" for iterating list > than "for loop" as it makes the code more clear to read. > This patch replace "for loop" with "list_for_each_entry_from_reverse" > and remove "cstate" variable as it is

Re: [PATCH v2 2/2] gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

ff-by: Arushi Singhal <arushisinghal19971...@gmail.com> Acked-by: Ben Skeggs <bske...@redhat.com> > --- > drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c &g

Re: [PATCH v2 2/2] gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

On Mon, Mar 26, 2018 at 4:01 AM, Arushi Singhal wrote: > It's better to use list_entry instead of list_{next/prev}_entry > as it makes the code more clear to read. > This patch replace list_entry with list_{next/prev}_entry. > > Signed-off-by: Arushi Singhal Acked

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

On 14 March 2018 at 21:08, Thierry Reding wrote: > On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wvla, remove VLA. In this particular >> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local >> variable

Re: [PATCH v2] drm/nouveau/secboot: remove VLA usage

On 14 March 2018 at 21:08, Thierry Reding wrote: > On Tue, Mar 13, 2018 at 11:24:11AM -0500, Gustavo A. R. Silva wrote: >> In preparation to enabling -Wvla, remove VLA. In this particular >> case directly use macro NVKM_MSGQUEUE_CMDLINE_SIZE instead of local >> variable cmdline_size. Also, remove

Re: [drm-nouveau-mmu] question about potential NULL pointer dereference

On Wed, Feb 14, 2018 at 1:40 AM, Gustavo A. R. Silva wrote: > > Hi all, > > While doing some static analysis I ran into the following piece of code at > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:957: > > 957#define node(root, dir) ((root)->head.dir == >list) ? NULL :

Re: [drm-nouveau-mmu] question about potential NULL pointer dereference

On Wed, Feb 14, 2018 at 1:40 AM, Gustavo A. R. Silva wrote: > > Hi all, > > While doing some static analysis I ran into the following piece of code at > drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:957: > > 957#define node(root, dir) ((root)->head.dir == >list) ? NULL : > \ > 958

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

On 08/18/2017 08:20 AM, Ben Skeggs wrote: > On 08/18/2017 08:16 AM, Colin Ian King wrote: >> On 17/08/17 23:07, Ilia Mirkin wrote: >>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King <colin.k...@canonical.com> >>> wrote: >>>> From: Colin Ian King <co

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

On 08/18/2017 08:20 AM, Ben Skeggs wrote: > On 08/18/2017 08:16 AM, Colin Ian King wrote: >> On 17/08/17 23:07, Ilia Mirkin wrote: >>> On Thu, Aug 17, 2017 at 6:03 PM, Colin King >>> wrote: >>>> From: Colin Ian King >>>> >>>> Th

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

On 08/18/2017 08:16 AM, Colin Ian King wrote: > On 17/08/17 23:07, Ilia Mirkin wrote: >> On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote: >>> From: Colin Ian King >>> >>> The null check on the array msto is incorrect since msto is never >>>

Re: [Nouveau] [PATCH][V2] drm/nouveau: perform null check on msto[i] rathern than msto

On 08/18/2017 08:16 AM, Colin Ian King wrote: > On 17/08/17 23:07, Ilia Mirkin wrote: >> On Thu, Aug 17, 2017 at 6:03 PM, Colin King wrote: >>> From: Colin Ian King >>> >>> The null check on the array msto is incorrect since msto is never >>> null. The null check should be instead on msto[i]

Re: Fwd: [Bug 99900] nouveau: freeze / crash after kernel update to 4.10

On 06/21/2017 02:54 AM, Olof Johansson wrote: > Hey, > > This was reported back in February and it seems nobody's given a shit? > > I've got a machine here with a Quadro 4000 that the screen locks up on > every single time the monitor goes to sleep. Userspace is Ubuntu 16.04, > kernel is recent

Re: Fwd: [Bug 99900] nouveau: freeze / crash after kernel update to 4.10

On 06/21/2017 02:54 AM, Olof Johansson wrote: > Hey, > > This was reported back in February and it seems nobody's given a shit? > > I've got a machine here with a Quadro 4000 that the screen locks up on > every single time the monitor goes to sleep. Userspace is Ubuntu 16.04, > kernel is recent

Re: [4.4.70 REGRESSION] Nouveau hangs up at boot

On 06/10/2017 06:25 AM, Takashi Iwai wrote: > Hi, > > we've received a bug report about 4.4.70 kernel showing the hang up at > boot. And, this turned out to be a regression in nouveau driver: > https://bugzilla.suse.com/show_bug.cgi?id=1043467 > > I provided a test kernel reverting the last

Re: [4.4.70 REGRESSION] Nouveau hangs up at boot

On 06/10/2017 06:25 AM, Takashi Iwai wrote: > Hi, > > we've received a bug report about 4.4.70 kernel showing the hang up at > boot. And, this turned out to be a regression in nouveau driver: > https://bugzilla.suse.com/show_bug.cgi?id=1043467 > > I provided a test kernel reverting the last

Re: [PATCH] gpu: drm: nouveau: add null check before pointer dereference

On 05/23/2017 05:12 AM, Gustavo A. R. Silva wrote: Add null check before dereferencing pointer asyc I've taken the patch into my tree, thanks! Ben. Addresses-Coverity-ID: 1397932 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/nouveau/nv50_display.c | 3

Re: [PATCH] gpu: drm: nouveau: add null check before pointer dereference

On 05/23/2017 05:12 AM, Gustavo A. R. Silva wrote: Add null check before dereferencing pointer asyc I've taken the patch into my tree, thanks! Ben. Addresses-Coverity-ID: 1397932 Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/nouveau/nv50_display.c | 3 ++- 1 file changed, 2

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

f_len=8M drm.debug=0x14 nouveau.debug=disp=trace,i2c=trace,bios=trace" please? Thanks, Ben. Bisected this to: commit df8dc97cd17269474344d73cc02739532c468d04 Author: Ben Skeggs <bske...@redhat.com> Date: Wed Mar 1 09:42:04 2017 +1000 drm/nouveau/kms/nv50: use drm core i2c-ov

Re: nouveau "eDP-1: EDID is invalid" regression after 4.11 with HP ZBook 15 G3

f_len=8M drm.debug=0x14 nouveau.debug=disp=trace,i2c=trace,bios=trace" please? Thanks, Ben. Bisected this to: commit df8dc97cd17269474344d73cc02739532c468d04 Author: Ben Skeggs Date: Wed Mar 1 09:42:04 2017 +1000 drm/nouveau/kms/nv50: use drm core i2c-over-aux algorith

Re: [Nouveau] [PATCH] drm/nouveau/dma: use rb_entry()

On 12/21/2016 12:02 AM, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. Thanks, I've grabbed the patch. Ben. > > Signed-off-by: Geliang Tang > --- > drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c | 4 ++-- >

Re: [Nouveau] [PATCH] drm/nouveau/dma: use rb_entry()

On 12/21/2016 12:02 AM, Geliang Tang wrote: > To make the code clearer, use rb_entry() instead of container_of() to > deal with rbtree. Thanks, I've grabbed the patch. Ben. > > Signed-off-by: Geliang Tang > --- > drivers/gpu/drm/nouveau/nvkm/engine/dma/base.c | 4 ++-- > 1 file changed, 2

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

On 12/12/2016 09:26 PM, Chris Chiu wrote: > 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 nv136_chipset for GTX 1060. I have one of

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

On 12/12/2016 09:26 PM, Chris Chiu wrote: > 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 nv136_chipset for GTX 1060. I have one of

Re: [PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

gt; As far as I can tell, that was true for the rest of that patch except for > this one function, which has been changed to a NOP. > > This patch restores the original behavior. > > Signed-off-by: Arnd Bergmann <a...@arndb.de> > Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosm

Re: [PATCH] nouveau: fix nv40_perfctr_next() cleanup regression

gt; As far as I can tell, that was true for the rest of that patch except for > this one function, which has been changed to a NOP. > > This patch restores the original behavior. > > Signed-off-by: Arnd Bergmann > Fixes: 8c1aeaa13954 ("drm/nouveau/pm: cosmetic changes")

Re: [PATCH 2/3] drm/nouveau: use post-decrement in error handling

On 02/16/2016 04:41 AM, Rasmus Villemoes wrote: > We need to use post-decrement to get the dma_map_page undone also for > i==0, and to avoid some very unpleasant behaviour if dma_map_page > failed already at i==0. > > Signed-off-by: Rasmus Villemoes <li...@rasmusvillemoes.dk

Re: [PATCH 2/3] drm/nouveau: use post-decrement in error handling

On 02/16/2016 04:41 AM, Rasmus Villemoes wrote: > We need to use post-decrement to get the dma_map_page undone also for > i==0, and to avoid some very unpleasant behaviour if dma_map_page > failed already at i==0. > > Signed-off-by: Rasmus Villemoes Reviewed-by: Ben Skeggs >

Re: [PATCH] nouveau: need to handle failed allocation

On 01/29/2016 10:12 AM, Insu Yun wrote: > > On Thu, Jan 28, 2016 at 7:08 PM, Ilia Mirkin > wrote: > > On Thu, Jan 28, 2016 at 7:09 PM, Insu Yun > wrote: > > drm_property_create_range can be failed in memory pressure. > >

Re: [PATCH] nouveau: need to handle failed allocation

On 01/29/2016 10:12 AM, Insu Yun wrote: > > On Thu, Jan 28, 2016 at 7:08 PM, Ilia Mirkin > wrote: > > On Thu, Jan 28, 2016 at 7:09 PM, Insu Yun > wrote: > > drm_property_create_range

Re: [Nouveau] [PATCH] instmem/gk20a: use DMA API CPU mapping

On 11/11/2015 06:07 PM, Alexandre Courbot wrote: > Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") > tried to be smart while using the DMA-API by managing the CPU mappings of > buffers allocated with the DMA-API by itself. In doing so, it relied > on dma_to_phys() which is

Re: [Nouveau] [PATCH] instmem/gk20a: use DMA API CPU mapping

On 11/11/2015 06:07 PM, Alexandre Courbot wrote: > Commit 69c4938249fb ("drm/nouveau/instmem/gk20a: use direct CPU access") > tried to be smart while using the DMA-API by managing the CPU mappings of > buffers allocated with the DMA-API by itself. In doing so, it relied > on dma_to_phys() which is

Re: drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c:70:2-8: preceding lock on line 67

ct 2015, kbuild test robot wrote: > >> CC: kbuild-...@01.org >> CC: linux-kernel@vger.kernel.org >> TO: Ben Skeggs >> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master >> head: 5b5f1455272e23f4e7889cec37228802d8d0

Re: drivers/gpu/drm/nouveau/nvkm/engine/fifo/base.c:70:2-8: preceding lock on line 67

ct 2015, kbuild test robot wrote: > >> CC: kbuild-...@01.org >> CC: linux-kernel@vger.kernel.org >> TO: Ben Skeggs <bske...@redhat.com> >> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> master &

Re: [PATCH] drm/nouveau/disp,pm: constify nvkm_object_func structures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/11/2015 10:18 PM, Julia Lawall wrote: > These nvkm_object_func structures are never modified. All other > nvkm_object_func structures are declared as const. > > Done with the help of Coccinelle. I've picked up the patch, thanks! Ben. > >

Re: [PATCH] drm/nouveau/disp,pm: constify nvkm_object_func structures

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/11/2015 10:18 PM, Julia Lawall wrote: > These nvkm_object_func structures are never modified. All other > nvkm_object_func structures are declared as const. > > Done with the help of Coccinelle. I've picked up the patch, thanks! Ben. > >

Re: [PATCH] drm/nouveau: fix memory leak

On 09/25/2015 01:59 AM, Sudip Mukherjee wrote: > On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote: >> If pm_runtime_get_sync() we were going to "out" but we missed >> freeing vma. >> >> Signed-off-by: Sudip Mukherjee --- > Hi Ben, Another gentle ping for another patch. Both

Re: [PATCH] drm/nouveau: fix memory leak

On 09/25/2015 01:59 AM, Sudip Mukherjee wrote: > On Fri, Sep 11, 2015 at 03:00:56PM +0530, Sudip Mukherjee wrote: >> If pm_runtime_get_sync() we were going to "out" but we missed >> freeing vma. >> >> Signed-off-by: Sudip Mukherjee --- > Hi Ben, Another gentle ping for

Re: [PATCH] gpu: drm: nouveau: nvif: device: Remove unused function

On Sun, Jan 11, 2015 at 11:53 PM, Rickard Strandqvist wrote: Hey Rickard, > Remove the function nvif_device_new() that is not used anywhere. It's used, just not by the kernel. All the code under core/ and nvif/ is also built into a userspace library (not in the kernel tree, obviously) and used

Re: [PATCH] gpu: drm: nouveau: nvif: device: Remove unused function

On Sun, Jan 11, 2015 at 11:53 PM, Rickard Strandqvist rickard_strandqv...@spectrumdigital.se wrote: Hey Rickard, Remove the function nvif_device_new() that is not used anywhere. It's used, just not by the kernel. All the code under core/ and nvif/ is also built into a userspace library (not in

Re: [PATCH] gpu: drm: nouveau: core: subdev: clock: base.c: Remove unused function

- Original Message - > From: "Rickard Strandqvist" > To: "David Airlie" , "Ben Skeggs" > Cc: "Rickard Strandqvist" , > "Alexandre Courbot" , "Ilia > Mirkin" , dri-de...@lists.freedesktop.org, > linux-kernel@

Re: [PATCH] gpu: drm: nouveau: core: subdev: clock: base.c: Remove unused function

- Original Message - From: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se To: David Airlie airl...@linux.ie, Ben Skeggs bske...@redhat.com Cc: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se, Alexandre Courbot acour...@nvidia.com, Ilia Mirkin imir

Re: nouveau oops in pramin_fini

- Original Message - > From: "Dave Jones" > To: "Linux Kernel" > Cc: bske...@redhat.com > Sent: Thursday, 18 December, 2014 6:43:22 AM > Subject: nouveau oops in pramin_fini > > Started seeing this during boot on one machine: Hey Dave, I've got a fix for that in my tree, I'll get it to

Re: nouveau oops in pramin_fini

- Original Message - From: Dave Jones da...@redhat.com To: Linux Kernel linux-kernel@vger.kernel.org Cc: bske...@redhat.com Sent: Thursday, 18 December, 2014 6:43:22 AM Subject: nouveau oops in pramin_fini Started seeing this during boot on one machine: Hey Dave, I've got a fix

Re: [Nouveau] [RESEND PATCH nouveau 3/3] volt: add support for GK20A

On Tue, Dec 2, 2014 at 9:00 AM, Martin Peres wrote: > On 28/11/2014 12:13, Vince Hsu wrote: >> >> The voltage value are calculated by the hardware characterized >> result. >> >> Signed-off-by: Vince Hsu >> --- >> >> Resend this patch with the fuse change and proper patch prefix >> per Thierry's

Re: [Nouveau] [RESEND V2 PATCH 1/3] soc/tegra: fuse: export tegra_sku_info for module use

On Mon, Dec 1, 2014 at 8:01 PM, Thierry Reding wrote: > I think the subject doesn't need "for module use" because that's > implicit in exporting a symbol. > > On Fri, Nov 28, 2014 at 07:12:58PM +0800, Vince Hsu wrote: >> Some Tegra drivers might be complied as kernel modules, and > > "compiled" >

Re: [Nouveau] [RESEND V2 PATCH 1/3] soc/tegra: fuse: export tegra_sku_info for module use

On Mon, Dec 1, 2014 at 8:01 PM, Thierry Reding thierry.red...@gmail.com wrote: I think the subject doesn't need for module use because that's implicit in exporting a symbol. On Fri, Nov 28, 2014 at 07:12:58PM +0800, Vince Hsu wrote: Some Tegra drivers might be complied as kernel modules, and

Re: [Nouveau] [RESEND PATCH nouveau 3/3] volt: add support for GK20A

On Tue, Dec 2, 2014 at 9:00 AM, Martin Peres martin.pe...@free.fr wrote: On 28/11/2014 12:13, Vince Hsu wrote: The voltage value are calculated by the hardware characterized result. Signed-off-by: Vince Hsu vin...@nvidia.com --- Resend this patch with the fuse change and proper patch

Re: [PATCH v2] drm/ttm: expose CPU address of DMA-allocated pages

On Mon, Aug 4, 2014 at 7:28 PM, Alexandre Courbot wrote: > Pages allocated using the DMA API have a coherent memory mapping. Make > this mapping visible to drivers so they can decide to use it instead of > creating their own redundant one. I've picked this up in nouveau's linux-3.17 staging

Re: [PATCH v2] drm/ttm: expose CPU address of DMA-allocated pages

On Mon, Aug 4, 2014 at 7:28 PM, Alexandre Courbot acour...@nvidia.com wrote: Pages allocated using the DMA API have a coherent memory mapping. Make this mapping visible to drivers so they can decide to use it instead of creating their own redundant one. I've picked this up in nouveau's

Re: [Nouveau] [PATCH v4 2/6] drm/nouveau: map pages using DMA API on platform devices

On Fri, Jul 11, 2014 at 12:35 PM, Alexandre Courbot wrote: > On 07/10/2014 09:58 PM, Daniel Vetter wrote: >> >> On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote: >>> >>> page_to_phys() is not the correct way to obtain the DMA address of a >>> buffer on a non-PCI system. Use the

Re: [PATCH 0/3] drm/gk20a: support for reclocking

On Fri, Jul 11, 2014 at 11:49 AM, Alexandre Courbot wrote: > On 07/10/2014 06:43 PM, Peter De Schrijver wrote: >> >> On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote: >>> >>> This series adds support for reclocking on GK20A. The first two patches >>> touch >>> the clock subsystem

Re: [Nouveau] [PATCH 0/3] drm/gk20a: support for reclocking

On Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot wrote: > This series adds support for reclocking on GK20A. The first two patches touch > the clock subsystem to allow GK20A to operate, by making the presence of the > thermal and voltage devices optional, and allowing pstates to be provided >

Re: [Nouveau] [PATCH 0/3] drm/gk20a: support for reclocking

On Thu, Jul 10, 2014 at 5:34 PM, Alexandre Courbot acour...@nvidia.com wrote: This series adds support for reclocking on GK20A. The first two patches touch the clock subsystem to allow GK20A to operate, by making the presence of the thermal and voltage devices optional, and allowing pstates to

Re: [PATCH 0/3] drm/gk20a: support for reclocking

On Fri, Jul 11, 2014 at 11:49 AM, Alexandre Courbot acour...@nvidia.com wrote: On 07/10/2014 06:43 PM, Peter De Schrijver wrote: On Thu, Jul 10, 2014 at 09:34:34AM +0200, Alexandre Courbot wrote: This series adds support for reclocking on GK20A. The first two patches touch the clock

Re: [Nouveau] [PATCH v4 2/6] drm/nouveau: map pages using DMA API on platform devices

On Fri, Jul 11, 2014 at 12:35 PM, Alexandre Courbot acour...@nvidia.com wrote: On 07/10/2014 09:58 PM, Daniel Vetter wrote: On Tue, Jul 08, 2014 at 05:25:57PM +0900, Alexandre Courbot wrote: page_to_phys() is not the correct way to obtain the DMA address of a buffer on a non-PCI system. Use

Re: [PATCH v2] drm/gk20a: add BAR instance

On Sat, Jun 28, 2014 at 11:41 AM, Ken Adams wrote: > > On 6/27/14 8:56 PM, "Ben Skeggs" wrote: > >>On Sat, Jun 28, 2014 at 4:51 AM, Ken Adams wrote: >>> quick note re: tegra and gpu bars... >>> >>> to this point we've explicitly avoi

Re: [PATCH v2] drm/gk20a: add BAR instance

On Sat, Jun 28, 2014 at 11:41 AM, Ken Adams kad...@nvidia.com wrote: On 6/27/14 8:56 PM, Ben Skeggs skeg...@gmail.com wrote: On Sat, Jun 28, 2014 at 4:51 AM, Ken Adams kad...@nvidia.com wrote: quick note re: tegra and gpu bars... to this point we've explicitly avoided providing user-mode

Re: [PATCH v2] drm/gk20a: add BAR instance

On Sat, Jun 28, 2014 at 4:51 AM, Ken Adams wrote: > quick note re: tegra and gpu bars... > > to this point we've explicitly avoided providing user-mode mappings due to > power management issues, etc. > looks to me like this would allow such mappings. is that the case? are > there any paths

  1   2   3   >