similar to: [PATCH 1/5] drm/qxl: drop qxl_ttm_fault

Not sure what this hook is supposed to do. vmf->vma->vm_private_data should never be NULL, so the extra check in qxl_ttm_fault should have no effect. Drop it. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_ttm.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c

Three^W Two of the TTM drivers intercept the pagefault handler in a rather un-Linuxy and racy way. If they really must intercept the fault call (and it's not clear to me that they need to), I'd rather see them do it like this. The QXL driver seems least likely to need it; as the virtio driver has exactly the same code in it, only commented out. The radeon driver takes its own lock ...

Wire up the new drm_gem_ttm_mmap() helper function. Use generic drm_gem_mmap() and remove qxl_mmap(). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 1 - drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/qxl/qxl_object.c | 1 + drivers/gpu/drm/qxl/qxl_ttm.c | 16 ---------------- 4 files changed, 2 insertions(+), 18 deletions(-)

... using the use drm_gem_ttm_mmap() helper function. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 1 - drivers/gpu/drm/qxl/qxl_drv.c | 2 +- drivers/gpu/drm/qxl/qxl_object.c | 1 + drivers/gpu/drm/qxl/qxl_ttm.c | 16 ---------------- 4 files changed, 2 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_drv.h

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

Hi Colin, On 12 September 2017 at 10:45, Colin King <colin.king at canonical.com> wrote: > From: Colin Ian King <colin.king at canonical.com> > > Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel > log with qxl_mmap information messages. The following example code > illustrates this: > > int main(void) > { > int fd =

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

From: Colin Ian King <colin.king at canonical.com> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel log with qxl_mmap information messages. The following example code illustrates this: int main(void) { int fd = open("/dev/dri/card0", O_RDONLY); if (fd == -1) err(1, "open failed"); for (;;) { void *m = mmap(NULL, 4096, PROT_READ, MAP_SHARED,

Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it instead of its own embedded struct. This makes some gem functions (specifically drm_gem_object_lookup) work on ttm objects. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_ttm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c

Without that ttm offsets are not unique, they can refer to objects in both VRAM and PRIV memory (aka main and surfaces slot). One of those "why things didn't blow up without this" moments. Probably offset conflicts are rare enough by pure luck. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 5 ++++- drivers/gpu/drm/qxl/qxl_kms.c | 5

> > The ttm_mem_io_* functions are actually internal to TTM and shouldn't be > used in a driver. > As far as I can see by your second patch QXL is just using exported (that is not internal) functions. Not that the idea of making them internal is bad but this comment is a wrong statement. > Instead call the qxl_ttm_io_mem_reserve() function directly. > I would add that

> > Am 27.09.19 um 18:31 schrieb Frediano Ziglio: > >> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be > >> used in a driver. > >> > > As far as I can see by your second patch QXL is just using exported > > (that is not internal) functions. > > Not that the idea of making them internal is bad but this comment is >

The ttm_mem_io_* functions are actually internal to TTM and shouldn't be used in a driver. Instead call the qxl_ttm_io_mem_reserve() function directly. Signed-off-by: Christian K?nig <christian.koenig at amd.com> --- drivers/gpu/drm/qxl/qxl_drv.h | 2 ++ drivers/gpu/drm/qxl/qxl_object.c | 11 +---------- drivers/gpu/drm/qxl/qxl_ttm.c | 4 ++-- 3 files changed, 5 insertions(+),

Am 30.09.19 um 11:51 schrieb Frediano Ziglio: >> Am 27.09.19 um 18:31 schrieb Frediano Ziglio: >>>> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be >>>> used in a driver. >>>> >>> As far as I can see by your second patch QXL is just using exported >>> (that is not internal) functions. >>> Not that the

Am 27.09.19 um 18:31 schrieb Frediano Ziglio: >> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be >> used in a driver. >> > As far as I can see by your second patch QXL is just using exported > (that is not internal) functions. > Not that the idea of making them internal is bad but this comment is > a wrong statement. See the history of

Am 27.09.19 um 18:31 schrieb Frediano Ziglio: >> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be >> used in a driver. >> > As far as I can see by your second patch QXL is just using exported > (that is not internal) functions. > Not that the idea of making them internal is bad but this comment is > a wrong statement. See the history of

ttm_place are not supposed to change at runtime. All functions working with ttm_place provided by <drm/ttm/ttm_placement.h> work with const ttm_place. So mark the non-const structs as const. File size before: text data bss dec hex filename 3485 184 264 3933 f5d drivers/gpu/drm/qxl/qxl_ttm.o File size After adding 'const': text data bss

ttm_place are not supposed to change at runtime. All functions working with ttm_place provided by <drm/ttm/ttm_placement.h> work with const ttm_place. So mark the non-const structs as const. File size before: text data bss dec hex filename 3485 184 264 3933 f5d drivers/gpu/drm/qxl/qxl_ttm.o File size After adding 'const': text data bss

qxl device will not dma, so we don't need ttm_dma_tt. Go use ttm_tt instead, to avoid wasting resources (swiotlb bounce buffers for example). Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/qxl/qxl_ttm.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c index