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

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 P72: nouveau :01:00.0: disp: chid 0 mthd 008c data 000

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

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 P72: nouveau :01:00.0: disp: chid 0 mthd 008c data 000

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

On Mon, 2020-08-31 at 14:26 +1000, Ben Skeggs wrote: > 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 > >

Re: [Nouveau] [PATCH 3/3] drm/ttm: remove io_reserve_lru handling v2

o use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Christian-K-nig/drm-ttm-make-sure-that-we-always-zero-init-mem-bus-v2/20200901-230736 base:b36c969764ab12faebb74711c942fa3e6eaf1e96 config: x86_64-randconfig-a006-202

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote: > Use the proper modern API to transfer cache ownership for incoherent DMA. > > Signed-off-by: Christoph Hellwig > --- > drivers/net/ethernet/seeq/sgiseeq.c | 12 > 1 file changed, 8 insertions(+), 4 deletions(-) >

Re: [Nouveau] [PATCH 08/28] MIPS: make dma_sync_*_for_cpu a little less overzealous

On Wed, Aug 19, 2020 at 08:55:35AM +0200, Christoph Hellwig wrote: > When transferring DMA ownership back to the CPU there should never > be any writeback from the cache, as the buffer was owned by the > device until now. Instead it should just be invalidated for the > mapping directions where the

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

On Tue, Sep 01, 2020 at 07:12:41PM +0200, Thomas Bogendoerfer wrote: > On Tue, Sep 01, 2020 at 05:22:09PM +0200, Thomas Bogendoerfer wrote: > > On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote: > > > Use the proper modern API to transfer cache ownership for incoherent DMA. > > > >

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

On Tue, Sep 01, 2020 at 05:22:09PM +0200, Thomas Bogendoerfer wrote: > On Wed, Aug 19, 2020 at 08:55:49AM +0200, Christoph Hellwig wrote: > > Use the proper modern API to transfer cache ownership for incoherent DMA. > > > > Signed-off-by: Christoph Hellwig > > --- > > drivers/net/ethernet/seeq/s

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

On Wed, 2020-08-19 at 08:55 +0200, Christoph Hellwig wrote: > Switch the 53c700 driver to only use non-coherent descriptor memory > if it really has to because dma_alloc_coherent fails. This doesn't > matter for any of the platforms it runs on currently, but that will > change soon. > > To help w

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

On 01.09.20 17:22, James Bottomley wrote: > On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: >> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: >>> I think this looks mostly OK, except for one misnamed parameter >>> below. Unfortunately, the last non-coherent parisc was the

Re: [Nouveau] [PATCH 22/28] sgiseeq: convert from dma_cache_sync to dma_sync_single_for_device

On Tue, Sep 01, 2020 at 07:16:27PM +0200, Christoph Hellwig wrote: > Well, if IP22 doesn't speculate (which I'm pretty sure is the case), > dma_sync_single_for_cpu should indeeed be a no-op. But then there > also shouldn't be anything in the cache, as the previous > dma_sync_single_for_device shou

Re: [Nouveau] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support

Super minor nitpicks: On Tue, 2020-09-01 at 16:22 +1000, Sam McNally wrote: > From: Hans Verkuil > > Signed-off-by: Hans Verkuil > [sa...@chromium.org: > - rebased > - removed polling-related changes > - moved the calls to drm_dp_cec_(un)set_edid() into the next patch > ] > Signed-off-by: Sa

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: > On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: > > I think this looks mostly OK, except for one misnamed parameter > > below. Unfortunately, the last non-coherent parisc was the 700 > > series and I no longer own a box, so

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

On Tue, Sep 01, 2020 at 06:41:12PM +0200, Helge Deller wrote: > > I still have a zoo of machines running for such testing, including a > > 715/64 and two 730. > > I'm going to test this git tree on the 715/64: The 715/64 is a 7100LC machine though. I think you need to boot on the 730 to test the

Re: [Nouveau] [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

On Tue, Sep 1, 2020 at 1:06 PM Christoph Hellwig wrote: > > On Thu, Aug 20, 2020 at 07:33:48PM +0200, Tomasz Figa wrote: > > > It wasn't meant to be too insulting, but I found this out when trying > > > to figure out how to just disable it. But it also ends up using > > > the actual dma attr flag

Re: [Nouveau] [PATCH 06/28] lib82596: move DMA allocation into the callers of i82596_probe

On Wed, Aug 19, 2020 at 08:55:33AM +0200, Christoph Hellwig wrote: > This allows us to get rid of the LIB82596_DMA_ATTR defined and prepare > for untangling the coherent vs non-coherent DMA allocation API. > > Signed-off-by: Christoph Hellwig > --- > drivers/net/ethernet/i825xx/lasi_82596.c | 24

Re: [Nouveau] [PATCH 09/28] MIPS/jazzdma: remove the unused vdma_remap function

On Wed, Aug 19, 2020 at 08:55:36AM +0200, Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > --- > arch/mips/include/asm/jazzdma.h | 2 - > arch/mips/jazz/jazzdma.c| 70 - > 2 files changed, 72 deletions(-) Acked-by: Thomas Bogendoerfer -- C

Re: [Nouveau] [PATCH 10/28] MIPS/jazzdma: decouple from dma-direct

On Wed, Aug 19, 2020 at 08:55:37AM +0200, Christoph Hellwig wrote: > The jazzdma ops implement support for a very basic IOMMU. Thus we really > should not use the dma-direct code that takes physical address limits > into account. This survived through the great MIPS DMA ops cleanup mostly > becau

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

On 01.09.20 18:21, Helge Deller wrote: > On 01.09.20 17:22, James Bottomley wrote: >> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: >>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: I think this looks mostly OK, except for one misnamed parameter below. Unfort

Re: [Nouveau] [PATCH 07/28] 53c700: improve non-coherent DMA handling

On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: > I think this looks mostly OK, except for one misnamed parameter below. > Unfortunately, the last non-coherent parisc was the 700 series and I no > longer own a box, so I can't test that part of it (I can fire up the > C360 to test

Re: [Nouveau] VAAPI on GeForce GT 620M

Hi, Try: DRI_PRIME=1 LIBVA_DRIVER_NAME=nouveau vainfo --display drm --device /dev/dri/renderD129 Also try with and without the --device option, the important one is --display drm Cheers Julien On Tue, Sep 1, 2020 at 10:49 AM Analabha Roy wrote: > > > On Tue, 1 Sep 2020 at 18:59, Ilia Mirkin

Re: [Nouveau] VAAPI on GeForce GT 620M

On Tue, 1 Sep 2020 at 18:59, Ilia Mirkin wrote: > On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy > wrote: > > Any suggestions on how to trace the config issues? Do I have to debug > the va_openDriver() function? > > My guess, without reading any code, is that DRI_PRIME isn't doing what > you want i

[Nouveau] [PATCH 3/3] drm/ttm: remove io_reserve_lru handling v2

From: Christian König That is not used any more. v2: keep the NULL checks in TTM. Signed-off-by: Christian König Acked-by: Daniel Vetter --- drivers/gpu/drm/ttm/ttm_bo.c | 34 + drivers/gpu/drm/ttm/ttm_bo_util.c | 113 +++-- drivers/gpu/drm/ttm/ttm_bo_

[Nouveau] [PATCH 2/3] drm/nouveau: move io_reserve_lru handling into the driver v5

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 patch moves the io_reserve_lru handling into Nouveau instead. v2: don't call ttm_bo_unmap_virtu

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

We are trying to remove the io_lru handling and depend on zero init base, offset and addr here. v2: init addr as well Signed-off-by: Christian König --- drivers/gpu/drm/ttm/ttm_bo.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/t

Re: [Nouveau] VAAPI on GeForce GT 620M

On Tue, Sep 1, 2020 at 9:10 AM Analabha Roy wrote: > Any suggestions on how to trace the config issues? Do I have to debug the > va_openDriver() function? My guess, without reading any code, is that DRI_PRIME isn't doing what you want it to, and the nouveau driver is being handed an intel device

Re: [Nouveau] VAAPI on GeForce GT 620M

> > It does indicate a config problem, but why do you want to use the > nvidia GPU for video accel? I'd rely on intel to provide acceleration > as this also reduces power consumption of the entire system. Also I > think vaapi on the secondary GPU is pretty much untested. Well you've got a point

Re: [Nouveau] VAAPI on GeForce GT 620M

On Tue, Sep 1, 2020 at 3:31 AM Analabha Roy wrote: > > Hi, > > If I am reading the featurematrix right, VAAPI is supported for nouveau on > the GeForce650M (my card). > > Here is the output of inxi -F > > System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64 > Console: tty 1 Dist

[Nouveau] [PATCH 4/5] drm_dp_cec: add plumbing in preparation for MST support

From: Hans Verkuil Signed-off-by: Hans Verkuil [sa...@chromium.org: - rebased - removed polling-related changes - moved the calls to drm_dp_cec_(un)set_edid() into the next patch ] Signed-off-by: Sam McNally --- .../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +- drivers/gpu/drm/drm_dp_

Re: [Nouveau] [PATCH 05/28] media/v4l2: remove V4L2-FLAG-MEMORY-NON-CONSISTENT

On Thu, Aug 20, 2020 at 07:33:48PM +0200, Tomasz Figa wrote: > > It wasn't meant to be too insulting, but I found this out when trying > > to figure out how to just disable it. But it also ends up using > > the actual dma attr flags for it's own consistency checks, so just > > not setting the flag

Re: [Nouveau] [PATCH v2 1/2] drm: allow limiting the scatter list size.

On Tue, Aug 18, 2020 at 11:20:16AM +0200, Gerd Hoffmann wrote: > Add max_segment argument to drm_prime_pages_to_sg(). When set pass it > through to the __sg_alloc_table_from_pages() call, otherwise use > SCATTERLIST_MAX_SEGMENT. > > Also add max_segment field to drm driver and pass it to > drm_pr

Re: [Nouveau] VAAPI on GeForce GT 620M

On Tue, Sep 1, 2020 at 9:31 AM Analabha Roy wrote: > > Hi, > > If I am reading the featurematrix right, VAAPI is supported for nouveau on > the GeForce650M (my card). > > Here is the output of inxi -F > > System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64 > Console: tty 1 Dist

[Nouveau] VAAPI on GeForce GT 620M

Hi, If I am reading the featurematrix right, VAAPI is supported for nouveau on the GeForce650M (my card). Here is the output of inxi -F System:Host: MediaServer Kernel: 5.4.0-42-generic x86_64 bits: 64 Console: tty 1 Distro: Ubuntu 18.04.

Re: [Nouveau] [v3] drm/nouveau: utilize subconnector property for DP

Hi Ben Skeggs, Gentle Reminder, Can you please take a look at the patch and provide your ack. Thanks Jeevan B >-Original Message- >From: B, Jeevan >Sent: Sunday, August 16, 2020 12:22 PM >To: nouveau@lists.freedesktop.org; intel-...@lists.freedesktop.org; dri- >de...@lists.freedeskt