Re: [Nouveau] [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: [Nouveau] [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: [Nouveau] [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: [Nouveau] [PATCH 0/2] drm/nouveau: Small CRC fixes for 5.9

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

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

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

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: [Nouveau] [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: [Nouveau] [PATCH] drm/nouveau: gr/gk20a: Use firmware version 0

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

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

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

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

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

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: [Nouveau] [PATCH v3 1/3] device: rework mmio mapping code to get rid of second map

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

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

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

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+

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

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

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

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

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

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

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

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

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

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'

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

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

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

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

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

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

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.

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

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.

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.

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

Re: [Nouveau] [PATCH 2/4] drm/nouveau: Fill out gem_object->resv

drivers that would avoid having two of these, on in ttm_buffer_object > and the other in drm_gem_object, one just there for confusion. > > Acked-by: Gerd Hoffmann > Cc: Gerd Hoffmann > Reviewed-by: Emil Velikov > Signed-off-by: Daniel Vetter > Cc: Ben Skeggs > Cc: nouveau@list

Re: [Nouveau] [PATCH v3 0/4] Refuse to load if power cable are not connected

I've merged these patches to my tree. Thank you, Ben. On Thu, 18 Jul 2019 at 18:07, Mark Menzynski wrote: > > Added config override for power checks. > > Mark Menzynski (4): > bios/gpio: sort gpios by values > gpio: fail if gpu external power is missing > gpio: check the gpio function 16

Re: [Nouveau] [PATCH v2 2/4] gpio: fail if gpu external power is missing

On Mon, 15 Jul 2019 at 22:26, Ilia Mirkin wrote: > > Please add a config override to skip this, since we'll invariably get > it wrong for some setup, and should be able to provide users with > workarounds while the issue is being worked out. Yeah, this makes me nervous as well. In the very

Re: [Nouveau] [PATCH] drm/nouveau: fix memory leak in nouveau_conn_reset()

On Mon, 1 Jul 2019 at 12:37, Yongxin Liu wrote: > > In nouveau_conn_reset(), if connector->state is true, > __drm_atomic_helper_connector_destroy_state() will be called, > but the memory pointed by asyc isn't freed. Memory leak happens > in the following function

Re: [Nouveau] [PATCH 08/13] drm/nouveau: drop DRM_AUTH from DRM_RENDER_ALLOW ioctls

iver POV there is no distinction between primary and render > > nodes, thus we can drop the token. > > > > Note: the outstanding DRM_AUTH instance is: > > - legacy DRI1 ioctl, which is already neutered > > > > Cc: Ben Skeggs > > Cc: nouveau@lists.fr

Re: [Nouveau] [PATCH 1/2] drm/nouveau/disp/nv50-: force scaler for any non-default LVDS/eDP modes

On Sun, 26 May 2019 at 08:41, Ilia Mirkin wrote: > > Higher layers tend to add a lot of modes not actually in the EDID, such > as the standard DMT modes. Changing this would be extremely intrusive to > everyone, so just force the scaler more often. There are no practical > cases we're aware of

Re: [Nouveau] [PATCH] drm/nouveau/mmu: use struct_size() helper

On Sat, 25 May 2019 at 03:35, Gustavo A. R. Silva wrote: > > Make use of the struct_size() helper instead of an open-coded version > in order to avoid any potential type mistakes, in particular in the > context in which this code is being used. > > So, replace the following form: > >

Re: [Nouveau] [PATCH 2/2] drm/nouveau: remove open-coded drm_invalid_op()

On Sat, 25 May 2019 at 01:15, Emil Velikov wrote: > > On 2019/05/23, Ben Skeggs wrote: > > On Thu, 23 May 2019 at 01:03, Emil Velikov wrote: > > > > > > From: Emil Velikov > > > > > > Cc: Ben Skeggs > > > Cc: nouveau@lists.free

Re: [Nouveau] [PATCH 2/2] drm/nouveau: remove open-coded drm_invalid_op()

On Thu, 23 May 2019 at 01:03, Emil Velikov wrote: > > From: Emil Velikov > > Cc: Ben Skeggs > Cc: nouveau@lists.freedesktop.org > Signed-off-by: Emil Velikov Thanks! > --- > drivers/gpu/drm/nouveau/nouveau_abi16.c | 6 -- > drivers/gpu/drm/nouveau/nouveau_abi16

Re: [Nouveau] [PATCH v1 0/4] drm/nouveau: drop use of drmP.h

On Mon, 20 May 2019 at 00:00, Sam Ravnborg wrote: > > The following patchset remove use of the deprecated drmP.h > header file in the nouveau driver(s). > As preparation a dependency on drm_os_linux.h is dropped. > The list of include files are sorted and are in some cases > divided up in blocks

Re: [PATCH] drm/nouveau/bios/init: fix spelling mistake "CONDITON" -> "CONDITION"

On Wed, 15 May 2019 at 06:57, Colin King wrote: > > From: Colin Ian King > > There is a spelling mistake in a warning message. Fix it. Thanks, merged. > > Signed-off-by: Colin Ian King > --- > drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [Nouveau] [PATCH] drm/nouveau: fix duplication of nv50_head_atom struct

On Sun, 12 May 2019 at 04:23, Peteris Rudzusiks wrote: > > nv50_head_atomic_duplicate_state() makes a copy of nv50_head_atom > struct. This patch adds copying of struct member named "or", which > previously was left uninitialized in the duplicated structure. > > Due to this bug, incorrect nhsync

Re: [Nouveau] [PATCH v2] drm/nouveau/i2c: Disable i2c bus access after ->fini()

On Fri, 12 Apr 2019 at 03:37, Lyude Paul wrote: > > On Thu, 2019-04-11 at 08:48 +1000, Ben Skeggs wrote: > > On Wed, 10 Apr 2019 at 06:23, Lyude Paul wrote: > > > For a while, we've had the problem of i2c bus access not grabbing > > > a runtime PM ref when it's bein

Re: [Nouveau] [PATCH v2] drm/nouveau/i2c: Disable i2c bus access after ->fini()

On Wed, 10 Apr 2019 at 06:23, Lyude Paul wrote: > > For a while, we've had the problem of i2c bus access not grabbing > a runtime PM ref when it's being used in userspace by i2c-dev, resulting > in nouveau spamming the kernel log with errors if anything attempts to > access the i2c bus while the

Re: [Nouveau] [PATCH 0/4] NV50/GF100 behind constrained hierarchies

On Mon, 25 Mar 2019 at 13:33, Jon Derrick wrote: > > Hi Ben, Hey John, > > I've been working with an mmio-constrained pci hierarchy intended almost > solely for nvme devices and switches. Binding nouveau to an NV50-based > gpu results in a kernel panic as the device cannot be fully mapped. > >

Re: [Nouveau] [PATCH] drm/nouveau/dmem: Fix a NULL vs IS_ERR() check

Got it, thanks! On Fri, Feb 22, 2019 at 4:34 PM Dan Carpenter wrote: > > The hmm_devmem_add() function doesn't return NULL, it returns error > pointers. > > Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM") > Signed-off-by: Dan Carpenter > --- >

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: [Nouveau] [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: [Nouveau] [PATCH v2] drm/nouveau/volt/gf117: fix speedo readout register

On Mon, 14 Jan 2019 at 08:50, Ilia Mirkin wrote: > > GF117 appears to use the same register as GK104 (but still with the > general Fermi readout mechanism). > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 > Signed-off-by: Ilia Mirkin > --- > > v1 -> v2: split out different

Re: [Nouveau] [PATCH v6 00/20] MST refcounting/atomic helpers cleanup

For the nouveau patches in the series: Reviewed-By: Ben Skeggs On Fri, 11 Jan 2019 at 05:59, Lyude Paul wrote: > > This is the series I've been working on for a while now to get all of > the atomic DRM drivers in the tree to use the atomic MST helpers, and to > make the atomic

Re: [Nouveau] [PATCH 0/6] Remove all bad dp_mst_port uses and hide struct def

For the series: Acked-by: Ben Skeggs On Sat, 17 Nov 2018 at 10:21, Lyude Paul wrote: > > So we don't ever have to worry about drivers touching drm_dp_mst_port > structs without verifying them and crashing again. > > Lyude Paul (6): > drm/dp_mst: Add drm_dp_get_payload_info

Re: [Nouveau] [PATCH] drm/nouveau/secboot/acr: fix memory leak

On Fri, 14 Sep 2018 at 07:35, Kees Cook wrote: > > On Fri, Sep 7, 2018 at 8:02 PM, John Hubbard wrote: > > On 8/2/18 12:51 PM, Gustavo A. R. Silva wrote: > >> Hi all, > >> > >> Friendly ping! Who can take this? > >> > >> Thanks > >> -- > >> Gustavo > >> > >> On 07/24/2018 08:27 AM, Gustavo A. R.

Re: [Nouveau] [PATCH] drm/nouveau: Don't disable polling in fallback mode

On Wed, 12 Sep 2018 at 20:59, Takashi Iwai wrote: > > When a fan is controlled via linear fallback without cstate, we > shouldn't stop polling. Otherwise it won't be adjusted again and > keeps running at an initial crazy pace. Martin, Any thoughts on this? Ben. > > Fixes: 800efb4c2857

Re: [Nouveau] [linux-next] DDC responded, but no EDID for %s errors

On Thu, Sep 6, 2018 at 12:42 PM Sergey Senozhatsky wrote: > > On (08/02/18 11:46), Sergey Senozhatsky wrote: > > Hi, > > > > My dmesg is filled up with these errors > > > > nouveau :01:00.0: DRM: DDC responded, but no EDID for HDMI-A-1 > > nouveau :01:00.0: DRM: DDC responded, but no

Re: [Nouveau] [PATCH 0/5] drm/nouveau: add basic HDMI 2.0 support

On Tue, 4 Sep 2018 at 10:59, Ilia Mirkin wrote: > > This is the beginnings of HDMI 2.0 support. All of the "extra" > features are left out, such as 12/16bpc, YUV420, etc. > > I've verified that with this code, a GP108 (GT1030) can switch between > 4k@60 and 1920x1080@60 on a LG 4K TV. Further,

Re: [Nouveau] [PATCH 4/5] drm/nouveau: Grab RPM ref when i2c bus is in use

On Tue, 17 Jul 2018 at 20:18, Karol Herbst wrote: > > mhh, we shouldn't call to Linux APIs from within of nvkm. Rather gaurd > the Linux glue code to the i2c stuff instead, but this is all done > from inside of nvkm. I think we should move it out into > drm/nouveau/nouveau_i2c.c and do the

Re: [Nouveau] [bug report] drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts

On Tue, Jul 3, 2018 at 9:51 PM Dan Carpenter wrote: > > Hello Ben Skeggs, > > The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel > interfaces to control error interrupts" from May 8, 2018, leads to > the following static checker warning: > > d

Re: [Nouveau] no mouse cursor on nv50

On Mon, Jun 18, 2018 at 7:46 AM, Adam Borowski wrote: > Hi! > On v4.18-rc1, the mouse cursor is missing on my right monitor. > Card is G98 [GeForce 8400 GS Rev. 2]. > > I have two monitors: one small landscape 1280x1024 on DVI-I-1 left, and one > big 1600x1200 (1200x1600 portrait) on HDMI-1

Re: [Nouveau] [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: [Nouveau] [PATCH 1/3] drm/connector: Add generic underscan properties

On 8 May 2018 at 04:26, Harry Wentland wrote: > > > On 2018-05-07 12:19 PM, Boris Brezillon wrote: >> On Mon, 7 May 2018 18:01:44 +0300 >> Ville Syrjälä wrote: >> >>> On Mon, May 07, 2018 at 04:44:32PM +0200, Boris Brezillon wrote: We

<    1   2   3   4   5   6   7   8   9   10   >