[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190315090649.GD4470@infradead.org>
Date: Fri, 15 Mar 2019 02:06:49 -0700
From: Christoph Hellwig <hch@...radead.org>
To: John Stultz <john.stultz@...aro.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
Laura Abbott <labbott@...hat.com>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Greg KH <gregkh@...uxfoundation.org>,
Sumit Semwal <sumit.semwal@...aro.org>,
Liam Mark <lmark@...eaurora.org>,
Brian Starkey <Brian.Starkey@....com>,
"Andrew F . Davis" <afd@...com>, Chenbo Feng <fengc@...gle.com>,
Alistair Strachan <astrachan@...gle.com>,
dri-devel@...ts.freedesktop.org
Subject: Re: [RFC][PATCH 3/5 v2] dma-buf: heaps: Add system heap to dmabuf
heaps
> + i = sg_alloc_table(table, npages, GFP_KERNEL);
> + if (i)
> + goto err1;
> + for_each_sg(table->sgl, sg, table->nents, i) {
> + struct page *page;
> +
> + page = alloc_page(GFP_KERNEL);
> + if (!page)
> + goto err2;
> + sg_set_page(sg, page, PAGE_SIZE, 0);
> + }
Given that one if not the primary intent here is to DMA map the memory
this is a bad idea, as it might require bounce buffering.
What we really want here is something like this:
http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/dma-noncoherent-allocator.3
And I wonder if the S/G building should also move into common code
instead of being duplicated everywhere.
> +static int system_heap_create(void)
> +{
> + struct system_heap *sys_heap;
> +
> + sys_heap = kzalloc(sizeof(*sys_heap), GFP_KERNEL);
> + if (!sys_heap)
> + return -ENOMEM;
> + sys_heap->heap.name = "system_heap";
> + sys_heap->heap.ops = &system_heap_ops;
> +
> + dma_heap_add(&sys_heap->heap);
Why is this dynamically allocated?
Powered by blists - more mailing lists