search for: config_drm_legaci

Hi Am 25.02.20 um 18:44 schrieb Daniel Vetter: > On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote: >> This patchset moves legacy, non-KMS driver state from struct drm_driver >> into struct drm_legacy_state. Only non-KMS drivers provide an instance >> of the latter structure. One special case is nouveau, which supports >> legacy interfaces. It also

On Tue, May 12, 2020 at 3:10 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi Alex > > Am 12.05.20 um 20:32 schrieb Alex Deucher: > > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > >> > >> Hi > >> > >> Am 11.05.20 um 19:17 schrieb Christian K?nig: > >>> Hi guys, >

On Tue, Feb 25, 2020 at 04:58:59PM +0100, Thomas Zimmermann wrote: > This patchset moves legacy, non-KMS driver state from struct drm_driver > into struct drm_legacy_state. Only non-KMS drivers provide an instance > of the latter structure. One special case is nouveau, which supports > legacy interfaces. It also provides an instance of the legacy state if > the legacy interfaces

On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 11.05.20 um 19:17 schrieb Christian K?nig: > > Hi guys, > > > > Well let's face it AGP is a total headache to maintain and dead for at least 10+ years. > > > > We have a lot of x86 specific stuff in the architecture independent graphics memory

On Tue, 12 May 2020 at 20:48, Alex Deucher <alexdeucher at gmail.com> wrote: > > >> > > >> There's some AGP support code in the DRM core. Can some of that declared > > >> as legacy? > > >> > > >> Specifically, what about these AGP-related ioctl calls? Can they be > > >> declared as legacy? It would appear to me that

Hi Alex Am 12.05.20 um 20:32 schrieb Alex Deucher: > On Tue, May 12, 2020 at 2:29 PM Thomas Zimmermann <tzimmermann at suse.de> wrote: >> >> Hi >> >> Am 11.05.20 um 19:17 schrieb Christian K?nig: >>> Hi guys, >>> >>> Well let's face it AGP is a total headache to maintain and dead for at least 10+ years. >>> >>> We

This patchset moves legacy, non-KMS driver state from struct drm_driver into struct drm_legacy_state. Only non-KMS drivers provide an instance of the latter structure. One special case is nouveau, which supports legacy interfaces. It also provides an instance of the legacy state if the legacy interfaces have been enabled (i.e., defines the config option CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT) I

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_prime_pages_to_sg() calls in drivers and helpers. v2: place max_segment in drm driver not gem object. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> ---

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_prime_pages_to_sg() calls in drivers and helpers. > > v2: place max_segment in

Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled

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 (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrj?l? came up

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

On 1/21/20 1:29 PM, akpm at linux-foundation.org wrote: > The mm-of-the-moment snapshot 2020-01-21-13-28 has been uploaded to > > http://www.ozlabs.org/~akpm/mmotm/ > > mmotm-readme.txt says > > README for mm-of-the-moment: > > http://www.ozlabs.org/~akpm/mmotm/ > > This is a snapshot of my -mm patch queue. Uploaded at random hopefully > more than once

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1)

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 24e700e291d52bd200212487e2b654c0aa3f07a2 Merge: f57091767add2 c6ef89421e236 Author: Linus Torvalds <torvalds at linux-foundation.org> AuthorDate: Mon Sep 4 17:43:56 2017 -0700 Commit: Linus Torvalds <torvalds at

Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master commit 24e700e291d52bd200212487e2b654c0aa3f07a2 Merge: f57091767add2 c6ef89421e236 Author: Linus Torvalds <torvalds at linux-foundation.org> AuthorDate: Mon Sep 4 17:43:56 2017 -0700 Commit: Linus Torvalds <torvalds at

Hello, syzkaller hit the following crash on 28f50eb20931f32a2ceeb6aba8fa2cd5ca96ad9f git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master compiler: gcc (GCC) 7.1.1 20170620 .config is attached Raw console output is attached. C reproducer is attached syzkaller reproducer is attached. See https://goo.gl/kgGztJ for information about syzkaller reproducers IP: read_pnet

Hello, syzkaller hit the following crash on 28f50eb20931f32a2ceeb6aba8fa2cd5ca96ad9f git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master compiler: gcc (GCC) 7.1.1 20170620 .config is attached Raw console output is attached. C reproducer is attached syzkaller reproducer is attached. See https://goo.gl/kgGztJ for information about syzkaller reproducers IP: read_pnet

On Tue, Oct 24, 2017 at 08:14:01AM -0700, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 28f50eb20931f32a2ceeb6aba8fa2cd5ca96ad9f > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is attached. > C reproducer is attached > syzkaller reproducer is