search for: writecombining

virtio-gpu uses cached mappings. shmem helpers use writecombine though. So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak vm_page_prot accordingly. Reported-by: Gurchetan Singh <gurchetansingh at chromium.org> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+),

virtio-gpu uses cached mappings. shmem helpers use writecombine though. So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak vm_page_prot accordingly. Reported-by: Gurchetan Singh <gurchetansingh at chromium.org> Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_object.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+),

Hi Lucas, On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach <l.stach at pengutronix.de> wrote: > Hi Alexandre, > > Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot: >> Hi everyone, > [...] >> >> A few lines of hacks (not included here) are still needed to deal with cached >> mappings triggering external aborts and CPU/GPU memory coherency

Hi Konrad, Sometime ago i reported this one at boot up: [ 3009.778974] mcelog:16842 map pfn expected mapping type write-back for [mem 0x0009f000-0x000a0fff], got uncached-minus [ 3009.788570] ------------[ cut here ]------------ [ 3009.798175] WARNING: at arch/x86/mm/pat.c:774 untrack_pfn+0xa1/0xb0() [ 3009.807966] Hardware name: MS-7640 [ 3009.817677] Modules linked in: [ 3009.827524] Pid:

On Wed, Aug 28, 2013 at 02:00:47AM +0200, Lucas Stach wrote: > Signed-off-by: Lucas Stach <dev at lynxeye.de> > --- > drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++++ > drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++++ > 2 files changed, 9 insertions(+) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c > index

Hi Alexandre, Am Mittwoch, den 26.03.2014, 15:33 +0900 schrieb Alexandre Courbot: > Hi Lucas, > > On Mon, Mar 24, 2014 at 10:19 PM, Lucas Stach <l.stach at pengutronix.de> wrote: > > Hi Alexandre, > > > > Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot: > >> Hi everyone, > > [...] > >> > >> A few lines of hacks

Hi Am 10.12.19 um 09:57 schrieb Gerd Hoffmann: > virtio-gpu uses cached mappings. shmem helpers use writecombine though. > So roll our own mmap function, wrapping drm_gem_shmem_mmap(), to tweak > vm_page_prot accordingly. > > Reported-by: Gurchetan Singh <gurchetansingh at chromium.org> > Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> > --- >

...;bo.ttm && nvbo->bo.ttm->caching_state == tt_cached) > > You don't want to do it also for tt_wc ? > No the point of using writecombined memory for BOs is to explicitly avoid the need for this cache sync. An uncached MMIO read from the device should already flush out all writecombining buffers and this read is always happening when submitting a pushbuf. > > + ttm_dma_tt_cache_sync_for_device((struct ttm_dma_tt *)nvbo->bo.ttm, > > + &nouveau_bdev(nvbo->bo.ttm->bdev)->dev->pdev->dev); > > + > > ret = ttm_bo_validate(&nvbo->...

Hi Alexandre, Am Montag, den 24.03.2014, 17:42 +0900 schrieb Alexandre Courbot: > Hi everyone, [...] > > A few lines of hacks (not included here) are still needed to deal with cached > mappings triggering external aborts and CPU/GPU memory coherency issues, but I > hope to understand and address these issues next. For the coherency issue part you may want to look at my Nouveau on

Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel > address space. The mapping's address is returned as struct dma_buf_map. > Each function is a simplified version of TTM's existing kmap code. Both > functions respect the memory's location ani/or writecombine flags. > > On top TTM's

Hi On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian K?nig wrote: > > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > > > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in > > > kernel address space. The mapping's address is returned as struct > > >

The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's location ani/or writecombine flags. On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), two helpers that convert

The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel address space. The mapping's address is returned as struct dma_buf_map. Each function is a simplified version of TTM's existing kmap code. Both functions respect the memory's location ani/or writecombine flags. On top TTM's functions, GEM TTM helpers got drm_gem_ttm_{vmap,vunmap}(), two helpers that convert

On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian K?nig wrote: > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: > > The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel > > address space. The mapping's address is returned as struct dma_buf_map. > > Each function is a simplified version of TTM's existing kmap code. Both > > functions

Hi everyone, Here is the second batch of patches to add GK20A support to Nouveau. This time we are adding the actual chip support, and this series brings the driver to a point where a slightly-tweaked Mesa successfully runs shaders and renders triangles on GBM! Many thanks to Thierry Reding and the people on the #nouveau IRC channel for their help without which we would not have reached this

When using Xen Hypervisor, the video goes very slow after module load in console. Xorg does not run. My boot process (in kernel 3.7.1 from elrepo, my default kernel.): 1. Hypervisor is loaded (from here, the screen resolution is 640x480 - text scrolling fast) 2. Kernel is loaded 3. mgag200 module is loaded 4. Screens enter native resolution (from here, the screen resolution is 1280x768 - text

Hi Christian On 15.10.20 16:08, Christian K?nig wrote: > Am 15.10.20 um 14:38 schrieb Thomas Zimmermann: >> The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel >> address space. The mapping's address is returned as struct dma_buf_map. >> Each function is a simplified version of TTM's existing kmap code. Both >> functions respect the

virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4:

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