search for: ttm_bo_vmap

...t_info(struct drm_printer *p, unsigned int indent, > } > EXPORT_SYMBOL(drm_gem_ttm_print_info); > > +/** > + * drm_gem_ttm_vmap() - vmap &ttm_buffer_object > + * @gem: GEM object. > + * @map: [out] returns the dma-buf mapping. > + * > + * Maps a GEM object with ttm_bo_vmap(). This function can be used as > + * &drm_gem_object_funcs.vmap callback. > + * > + * Returns: > + * 0 on success, or a negative errno code otherwise. > + */ > +int drm_gem_ttm_vmap(struct drm_gem_object *gem, > + struct dma_buf_map *map) > +{ > + struct ttm_bu...

...t; > > EXPORT_SYMBOL(drm_gem_ttm_print_info); > > > +/** > > > + * drm_gem_ttm_vmap() - vmap &ttm_buffer_object > > > + * @gem: GEM object. > > > + * @map: [out] returns the dma-buf mapping. > > > + * > > > + * Maps a GEM object with ttm_bo_vmap(). This function can be used as > > > + * &drm_gem_object_funcs.vmap callback. > > > + * > > > + * Returns: > > > + * 0 on success, or a negative errno code otherwise. > > > + */ > > > +int drm_gem_ttm_vmap(struct drm_gem_object *gem, > &...

...and forward the call to TTM's vmap/vunmap. These helpers can be dropped into the rsp GEM object callbacks. v5: * use size_t for storing mapping size (Christian) * ignore premapped memory areas correctly in ttm_bo_vunmap() * rebase onto latest TTM interfaces (Christian) * remove BUG() from ttm_bo_vmap() (Christian) v4: * drop ttm_kmap_obj_to_dma_buf() in favor of vmap helpers (Daniel, Christian) Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> Acked-by: Daniel Vetter <daniel.vetter at ffwll.ch> Tested-by: Sam Ravnborg <sam at ravnborg.org> --- drivers/gpu/drm/drm...

...gt; unsigned int indent, >> ? } >> ? EXPORT_SYMBOL(drm_gem_ttm_print_info); >> ? +/** >> + * drm_gem_ttm_vmap() - vmap &ttm_buffer_object >> + * @gem: GEM object. >> + * @map: [out] returns the dma-buf mapping. >> + * >> + * Maps a GEM object with ttm_bo_vmap(). This function can be used as >> + * &drm_gem_object_funcs.vmap callback. >> + * >> + * Returns: >> + * 0 on success, or a negative errno code otherwise. >> + */ >> +int drm_gem_ttm_vmap(struct drm_gem_object *gem, >> +???????????? struct dma_buf_map...

...elper.c @@ -49,6 +49,44 @@ void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent, } EXPORT_SYMBOL(drm_gem_ttm_print_info); +/** + * drm_gem_ttm_vmap() - vmap &ttm_buffer_object + * @gem: GEM object. + * @map: [out] returns the dma-buf mapping. + * + * Maps a GEM object with ttm_bo_vmap(). This function can be used as + * &drm_gem_object_funcs.vmap callback. + * + * Returns: + * 0 on success, or a negative errno code otherwise. + */ +int drm_gem_ttm_vmap(struct drm_gem_object *gem, + struct dma_buf_map *map) +{ + struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem); +...

...signed int indent, > > } > > EXPORT_SYMBOL(drm_gem_ttm_print_info); > > +/** > > + * drm_gem_ttm_vmap() - vmap &ttm_buffer_object > > + * @gem: GEM object. > > + * @map: [out] returns the dma-buf mapping. > > + * > > + * Maps a GEM object with ttm_bo_vmap(). This function can be used as > > + * &drm_gem_object_funcs.vmap callback. > > + * > > + * Returns: > > + * 0 on success, or a negative errno code otherwise. > > + */ > > +int drm_gem_ttm_vmap(struct drm_gem_object *gem, > > + struct dma_buf_map...

...ryone just > >>>> immediately follows up with converting that full object map into a > >>>> pointer. > >>>> > >>>> So I think what we really want here is: > >>>> - new function > >>>> > >>>> int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); > >>>> > >>>> _vmap name since that's consistent with both dma_buf functions and > >>>> what's usually used to implement this. Outside of the ttm world kmap > >>>> us...

...ntire object. Only vmwgfx uses to map less than that. Also, everyone just >>> immediately follows up with converting that full object map into a >>> pointer. >>> >>> So I think what we really want here is: >>> - new function >>> >>> int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); >>> >>> _vmap name since that's consistent with both dma_buf functions and >>> what's usually used to implement this. Outside of the ttm world kmap >>> usually just means single-page mappings u...

Hi Thomas, [SNIP] >>> ? +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map) >>> +{ >>> +??? struct ttm_resource *mem = &bo->mem; >>> +??? int ret; >>> + >>> +??? ret = ttm_mem_io_reserve(bo->bdev, mem); >>> +??? if (ret) >>> +??????? return ret; &...

...callers of ttm_bo_kmap almost everyone maps the > entire object. Only vmwgfx uses to map less than that. Also, everyone just > immediately follows up with converting that full object map into a > pointer. > > So I think what we really want here is: > - new function > > int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); > > _vmap name since that's consistent with both dma_buf functions and > what's usually used to implement this. Outside of the ttm world kmap > usually just means single-page mappings using kmap() or it's iomem &...

...maps the > > entire object. Only vmwgfx uses to map less than that. Also, everyone just > > immediately follows up with converting that full object map into a > > pointer. > > > > So I think what we really want here is: > > - new function > > > > int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); > > > > _vmap name since that's consistent with both dma_buf functions and > > what's usually used to implement this. Outside of the ttm world kmap > > usually just means single-page mappings using kmap()...

...es to map less than that. Also, everyone just >>>> immediately follows up with converting that full object map into a >>>> pointer. >>>> >>>> So I think what we really want here is: >>>> - new function >>>> >>>> int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); >>>> >>>> _vmap name since that's consistent with both dma_buf functions and >>>> what's usually used to implement this. Outside of the ttm world kmap >>>> usually just means sin...

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

On Wed, Sep 30, 2020 at 2:34 PM Christian K?nig <christian.koenig at amd.com> wrote: > > Am 30.09.20 um 11:47 schrieb Daniel Vetter: > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian K?nig wrote: > >> Am 30.09.20 um 10:19 schrieb Thomas Zimmermann: > >>> Hi > >>> > >>> Am 30.09.20 um 10:05 schrieb Christian K?nig: >

...e callers of ttm_bo_kmap almost everyone maps the > entire object. Only vmwgfx uses to map less than that. Also, everyone just > immediately follows up with converting that full object map into a > pointer. > > So I think what we really want here is: > - new function > > int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map); > > _vmap name since that's consistent with both dma_buf functions and > what's usually used to implement this. Outside of the ttm world kmap > usually just means single-page mappings using kmap() or it's iomem...

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use