search for: dma_alloc

...ng.com> --- arch/h8300/kernel/dma.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/h8300/kernel/dma.c b/arch/h8300/kernel/dma.c index eeb13d3f2424..3651da045806 100644 --- a/arch/h8300/kernel/dma.c +++ b/arch/h8300/kernel/dma.c @@ -12,7 +12,7 @@ static void *dma_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t gfp, - struct dma_attrs *attrs) + unsigned long attrs) { void *ret; @@ -32,7 +32,7 @@ static void *dma_alloc(struct device *dev, size_t size, static void dma_free(struct device *dev, size_t size,...

Hi Folks, I need some large chunk of physical memory, so I allocate it early using alloc_bootmem_low_pages and use it later (akin to bigphysarea patch). The trouble I am having is the following. Suppose the virtual address for the memory area is 0xc14d6000. After xen_create_contiguous_region call, I do a virt_to_bus and the bus address comes out to be 0x18000000. So far so good. However,

...to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n"); >> + > > is there a chance it actually still might work? If we're not actually using the DMA API, we may still get away with it, otherwise it's a fairly sure bet that the subsequent dma_map/dma_alloc calls will fail and we'll get nowhere. If I change this to be a probe failure condition (and correspondingly in the PCI drivers too), would you rather that be predicated on vring_use_dma_api(), or always (given the TODO in virtio_ring.c)? Robin. >> platform_set_drvdata(pdev, vm_dev);...

...to enable 64-bit or 32-bit DMA. Trying to continue, but this might not work.\n"); >> + > > is there a chance it actually still might work? If we're not actually using the DMA API, we may still get away with it, otherwise it's a fairly sure bet that the subsequent dma_map/dma_alloc calls will fail and we'll get nowhere. If I change this to be a probe failure condition (and correspondingly in the PCI drivers too), would you rather that be predicated on vring_use_dma_api(), or always (given the TODO in virtio_ring.c)? Robin. >> platform_set_drvdata(pdev, vm_dev);...

...r of DMA mapping is normal ? > > > > Yeah seems perfectly fine for a gpu. > > Note that it never go down and when I terminate my X session, it stays the same. > So without any "real" GPU work, does it is still normal to have so many active mapping ? Might just be the dma_alloc cache. It should go down under memory pressure I think. Otherwise might also be a leak. > For example, when doing some transfer, the ahci mapping number changes and then always go down to 6. gpu drivers tend to cache everything, all the time ... -Daniel -- Daniel Vetter Software Engineer, Int...

On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote: > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote: > > Hello > > > > Since lot of release (at least since 4.19), I hit the following error message: > > DMA-API: cacheline tracking ENOMEM, dma-debug disabled > > > > After hitting that, I try to check who is creating so many DMA

...e "WIP" (work-in-progress) branch at the usual git repo, git://et.redhat.com/linux-2.6-dom0-pvops.git with gitweb at http://git.et.redhat.com/?p=linux-2.6-dom0-pvops.git New since the last drop are some MTRR cleanups from Mark McLoughlin, a number of dma-mapping cleanups, and full dma_alloc/free_coherent support, including xen contiguous mapping support. I've also updated it to Linus' final v2.6.24. The APIC code is still non-pvops-friendly, but other than that, all the new code is completely pvops-friendly and will work happily on baremetal as well as Xen. So next job is t...

...e "WIP" (work-in-progress) branch at the usual git repo, git://et.redhat.com/linux-2.6-dom0-pvops.git with gitweb at http://git.et.redhat.com/?p=linux-2.6-dom0-pvops.git New since the last drop are some MTRR cleanups from Mark McLoughlin, a number of dma-mapping cleanups, and full dma_alloc/free_coherent support, including xen contiguous mapping support. I've also updated it to Linus' final v2.6.24. The APIC code is still non-pvops-friendly, but other than that, all the new code is completely pvops-friendly and will work happily on baremetal as well as Xen. So next job is t...

...e "WIP" (work-in-progress) branch at the usual git repo, git://et.redhat.com/linux-2.6-dom0-pvops.git with gitweb at http://git.et.redhat.com/?p=linux-2.6-dom0-pvops.git New since the last drop are some MTRR cleanups from Mark McLoughlin, a number of dma-mapping cleanups, and full dma_alloc/free_coherent support, including xen contiguous mapping support. I've also updated it to Linus' final v2.6.24. The APIC code is still non-pvops-friendly, but other than that, all the new code is completely pvops-friendly and will work happily on baremetal as well as Xen. So next job is t...

...cc: Linus Walleij <linus.walleij at linaro.org> cc: virtualization at lists.linux-foundation.org --- Hi Amit, Changes since v2: Fixes for Rustys review comments. The only "unresolved" issue (unless I missed something) is the quirky handling of finding device grandparent when doing dma_alloc. [Rusty wrote:] >OK, I'll let Amit comment on the console changes, but some minor style >comments below. Amit, any chance that you might find time to review this? Note: This patch is based on v3.6 so this patch is will conflict with "virtio: console: fix error handling in init() f...

...cc: Linus Walleij <linus.walleij at linaro.org> cc: virtualization at lists.linux-foundation.org --- Hi Amit, Changes since v2: Fixes for Rustys review comments. The only "unresolved" issue (unless I missed something) is the quirky handling of finding device grandparent when doing dma_alloc. [Rusty wrote:] >OK, I'll let Amit comment on the console changes, but some minor style >comments below. Amit, any chance that you might find time to review this? Note: This patch is based on v3.6 so this patch is will conflict with "virtio: console: fix error handling in init() f...

Once DMA API usage is enabled, it becomes apparent that virtio-mmio is inadvertently relying on the default 32-bit DMA mask, which leads to problems like rapidly exhausting SWIOTLB bounce buffers. Ensure that we set the appropriate 64-bit DMA mask whenever possible, with the coherent mask suitably limited for the legacy vring as per a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for

Once DMA API usage is enabled, it becomes apparent that virtio-mmio is inadvertently relying on the default 32-bit DMA mask, which leads to problems like rapidly exhausting SWIOTLB bounce buffers. Ensure that we set the appropriate 64-bit DMA mask whenever possible, with the coherent mask suitably limited for the legacy vring as per a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for

...ue, vq->num_free); + spin_lock(&vgdev->winsrv_txq.qlock); + goto retry; + } + + virtqueue_kick(vq); + + spin_unlock(&vgdev->winsrv_txq.qlock); + + if (!ret) + ret = vq->num_free; + return ret; +} + /* just create gem objects for userspace and long lived objects, just use dma_alloced pages for the queue objects? */ @@ -890,3 +1076,100 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +int virtio_gpu_cmd_winsrv_connect(struct virtio_gpu_device *vgdev...

...ue, vq->num_free); + spin_lock(&vgdev->winsrv_txq.qlock); + goto retry; + } + + virtqueue_kick(vq); + + spin_unlock(&vgdev->winsrv_txq.qlock); + + if (!ret) + ret = vq->num_free; + return ret; +} + /* just create gem objects for userspace and long lived objects, just use dma_alloced pages for the queue objects? */ @@ -890,3 +1076,100 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +int virtio_gpu_cmd_winsrv_connect(struct virtio_gpu_device *vgdev...

...ue, vq->num_free); + spin_lock(&vgdev->winsrv_txq.qlock); + goto retry; + } + + virtqueue_kick(vq); + + spin_unlock(&vgdev->winsrv_txq.qlock); + + if (!ret) + ret = vq->num_free; + return ret; +} + /* just create gem objects for userspace and long lived objects, just use dma_alloced pages for the queue objects? */ @@ -890,3 +1076,100 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +int virtio_gpu_cmd_winsrv_connect(struct virtio_gpu_device *vgdev...

Hi, this work is based on the virtio_wl driver in the ChromeOS kernel by Zach Reizner, currently at: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-4.4/drivers/virtio/virtio_wl.c There's one feature missing currently, which is letting clients write directly to the host part of a resource, so the extra copy in TRANSFER_TO_HOST isn't needed. Have pushed the

...ue, vq->num_free); + spin_lock(&vgdev->winsrv_txq.qlock); + goto retry; + } + + virtqueue_kick(vq); + + spin_unlock(&vgdev->winsrv_txq.qlock); + + if (!ret) + ret = vq->num_free; + return ret; +} + /* just create gem objects for userspace and long lived objects, just use dma_alloced pages for the queue objects? */ @@ -890,3 +1076,100 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +int virtio_gpu_cmd_winsrv_connect(struct virtio_gpu_device *vgdev...

...ue, vq->num_free); + spin_lock(&vgdev->winsrv_txq.qlock); + goto retry; + } + + virtqueue_kick(vq); + + spin_unlock(&vgdev->winsrv_txq.qlock); + + if (!ret) + ret = vq->num_free; + return ret; +} + /* just create gem objects for userspace and long lived objects, just use dma_alloced pages for the queue objects? */ @@ -890,3 +1076,100 @@ void virtio_gpu_cursor_ping(struct virtio_gpu_device *vgdev, memcpy(cur_p, &output->cursor, sizeof(output->cursor)); virtio_gpu_queue_cursor(vgdev, vbuf); } + +int virtio_gpu_cmd_winsrv_connect(struct virtio_gpu_device *vgdev...

...ddr, + cfv->alloc_dma); + + if (!cfv->genpool) + return; + gen_pool_free(cfv->genpool, cfv->reserved_mem, + cfv->reserved_size); + gen_pool_destroy(cfv->genpool); + cfv->genpool = NULL; +} + +static int cfv_create_genpool(struct cfv_info *cfv) +{ + int err; + + /* dma_alloc can only allocate whole pages, and we need a more + * fine graned allocation so we use genpool. We ask for space needed + * by IP and a full ring. If the dma allcoation fails we retry with a + * smaller allocation size. + */ + err = -ENOMEM; + cfv->allocsz = (virtqueue_get_vring_size(cfv-&gt...