search for: mga_crtc_cursor_set

...es changed, 36 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/mgag200/mgag200_cursor.c b/drivers/gpu/drm/mgag200/mgag200_cursor.c index cca3922f9f67..6c1a9d724d85 100644 --- a/drivers/gpu/drm/mgag200/mgag200_cursor.c +++ b/drivers/gpu/drm/mgag200/mgag200_cursor.c @@ -43,6 +43,7 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc, struct drm_gem_object *obj; struct drm_gem_vram_object *gbo = NULL; int ret = 0; + u8 *src, *dst; unsigned int i, row, col; uint32_t colour_set[16]; uint32_t *next_space = &colour_set[0]; @@ -126,18 +127,17 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc,...

...m_gem_vram_unpin(mdev->cursor.pixels_1); > + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_1); > if (mdev->cursor.pixels_2->pin_count) > - drm_gem_vram_unpin(mdev->cursor.pixels_2); > + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_2); > } > > int mga_crtc_cursor_set(struct drm_crtc *crtc, > @@ -96,26 +96,28 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc, > > /* Move cursor buffers into VRAM if they aren't already */ > if (!pixels_1->pin_count) { > - ret = drm_gem_vram_pin(pixels_1, DRM_GEM_VRAM_PL_FLAG_VRAM); > + ret = drm_ge...

...m_gem_vram_unpin(mdev->cursor.pixels_1); > + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_1); > if (mdev->cursor.pixels_2->pin_count) > - drm_gem_vram_unpin(mdev->cursor.pixels_2); > + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_2); > } > > int mga_crtc_cursor_set(struct drm_crtc *crtc, > @@ -96,26 +96,28 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc, > > /* Move cursor buffers into VRAM if they aren't already */ > if (!pixels_1->pin_count) { > - ret = drm_gem_vram_pin(pixels_1, DRM_GEM_VRAM_PL_FLAG_VRAM); > + ret = drm_ge...

...t; > Maybe we should also do a large-scale s/reserve/lock/ within ttm, to align > more with what we now have in dma-buf. Given that mgag200 is the only user I think the best way forward is to improve the mgag200 cursor handling so we can just drop the _reserved variants ... When looking at mga_crtc_cursor_set() I suspect the easierst way to do that would be to simply pin the cursor bo's at driver_load time, then we don't have to bother with pinning in mga_crtc_cursor_set() at all. Thomas, as you have test hardware, can you look into this? thanks, Gerd

...n_reserved(mdev->cursor.pixels_1); >>> if (mdev->cursor.pixels_2->pin_count) >>> - drm_gem_vram_unpin(mdev->cursor.pixels_2); >>> + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_2); >>> } >>> >>> int mga_crtc_cursor_set(struct drm_crtc *crtc, >>> @@ -96,26 +96,28 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc, >>> >>> /* Move cursor buffers into VRAM if they aren't already */ >>> if (!pixels_1->pin_count) { >>> - ret = drm_gem_vram_pin(pixel...

...ursor.pixels_1->pin_count) - drm_gem_vram_unpin(mdev->cursor.pixels_1); + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_1); if (mdev->cursor.pixels_2->pin_count) - drm_gem_vram_unpin(mdev->cursor.pixels_2); + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_2); } int mga_crtc_cursor_set(struct drm_crtc *crtc, @@ -96,26 +96,28 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc, /* Move cursor buffers into VRAM if they aren't already */ if (!pixels_1->pin_count) { - ret = drm_gem_vram_pin(pixels_1, DRM_GEM_VRAM_PL_FLAG_VRAM); + ret = drm_gem_vram_pin_reserved(pixels_1,...

...xels_1); > > + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_1); > > if (mdev->cursor.pixels_2->pin_count) > > - drm_gem_vram_unpin(mdev->cursor.pixels_2); > > + drm_gem_vram_unpin_reserved(mdev->cursor.pixels_2); > > } > > > > int mga_crtc_cursor_set(struct drm_crtc *crtc, > > @@ -96,26 +96,28 @@ int mga_crtc_cursor_set(struct drm_crtc *crtc, > > > > /* Move cursor buffers into VRAM if they aren't already */ > > if (!pixels_1->pin_count) { > > - ret = drm_gem_vram_pin(pixels_1, DRM_GEM_VRAM_PL_FLAG_VR...

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

A kernel test bot reported a problem with the locktorture testcase that was triggered by the GEM VRAM helpers. ... [ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm] ... [ 10.015669] ? kvm_sched_clock_read+0x5/0xd [ 10.016157] ? get_lock_stats+0x11/0x3f [ 10.016607] drm_gem_vram_pin+0x77/0xa2 [drm_vram_helper] [ 10.017229]

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same

Several simple framebuffer drivers copy most of the TTM code from each other. The implementation is always the same; except for the name of some data structures. As recently discussed, this patch set provides generic memory-management code for simple framebuffers with dedicated video memory. It further converts the respective drivers to the generic code. The shared code is basically the same