search for: gfp_dma32

While I have a patch queued to address related issues in intel-agp, a quick scan of the Linux tree seems to reveal several more cases where assumptions are being made on GFP_DMA{,32} allocations - either the result (even properly passed through virt_to_bus()) is put into hardware registers (with no guarantee that it fits the width required by those registers or fields thereof), or page-crossing

Some graphics APIs differentiate between out-of-graphics-memory and out-of-host-memory (system memory). Add a device init flag to have -ENOSPC propagated from the resource managers instead of being converted to -ENOMEM, to aid driver stacks in determining what error code to return or whether corrective action can be taken at the driver level. The first patch deals with a ttm_device_init()

...ref->object; int ret; unsigned i; mutex_init(&glob->device_list_mutex); spin_lock_init(&glob->lru_lock); - glob->mem_glob = bo_ref->mem_glob; + glob->mem_glob = mem_glob; glob->mem_glob->bo_glob = glob; glob->dummy_read_page = alloc_page(__GFP_ZERO | GFP_DMA32); @@ -1564,7 +1560,7 @@ int ttm_bo_global_ref_init(struct drm_global_reference *ref) kfree(glob); return ret; } -EXPORT_SYMBOL(ttm_bo_global_ref_init); +EXPORT_SYMBOL(ttm_bo_global_init); int ttm_bo_device_release(struct ttm_bo_device *bdev) diff --git a/include/drm/ttm/ttm_bo_driver.h...

...; > > allocations. > > > ?? * @mapping: The address space to use for this bo. > > > ?? * @vma_manager: A pointer to a vma manager. > > > - * @use_dma_alloc: If coherent DMA allocation API should be > > > used. > > > - * @use_dma32: If we should use GFP_DMA32 for device memory > > > allocations. > > > + * @flags: Flags governing the device behaviour. > > > ?? * > > > ?? * Initializes a struct ttm_device: > > > ?? * Returns: > > > @@ -184,7 +183,7 @@ EXPORT_SYMBOL(ttm_device_swapout); > > > ?...

...> > > > ?? * @mapping: The address space to use for this bo. > > > > ?? * @vma_manager: A pointer to a vma manager. > > > > - * @use_dma_alloc: If coherent DMA allocation API should be > > > > used. > > > > - * @use_dma32: If we should use GFP_DMA32 for device memory > > > > allocations. > > > > + * @flags: Flags governing the device behaviour. > > > > ?? * > > > > ?? * Initializes a struct ttm_device: > > > > ?? * Returns: > > > > @@ -184,7 +183,7 @@ EXPORT_SYMBOL(ttm_dev...

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code

Hi Konrad, The following patch causes fairly large packet loss when transmitting from dom0 to the physical network, at least with my tg3 hardware, but I assume it can impact anything which uses this interface. I suspect that the issue is that the compound pages allocated in this way are not backed by contiguous mfns and so things fall apart when the driver tries to do DMA. However I

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. As a follow up I

Hi all, this series replaced the DMA_ATTR_NON_CONSISTENT flag to dma_alloc_attrs with a separate new dma_alloc_pages API, which is available on all platforms. In addition to cleaning up the convoluted code path, this ensures that other drivers that have asked for better support for non-coherent DMA to pages with incurring bounce buffering over can finally be properly supported. I'm still a