On 2/22/19 9:24 AM, John Stultz wrote:
On Fri, Feb 22, 2019 at 8:55 AM Andrew F. Davis afd@ti.com wrote:
On 2/21/19 1:40 AM, John Stultz wrote:
Here is a very early peek at my dmabuf pools patchset, which tries to destage a fair chunk of ION functionality.
This build and boots, but I've not gotten to testing the actual pool devices yet (need to write some kselftests)! I just wanted some early feedback on the overall direction.
The patchset implements per-pool devices (extending my ion per-heap devices patchset from last week), which can be opened directly and then an ioctl is used to allocate a dmabuf from the pool.
The interface is similar, but simpler then IONs, only providing an ALLOC ioctl.
Also, I've only destaged the system/system-contig and cma pools, since the ION carveout and chunk heaps depended on out of tree board files to initialize those heaps. I'll leave that to folks who are actually using those heaps.
Let me know what you think!
+1
Was this source not pulled from -next, I have some fixes in next that I don't see in this code, so I won't review the code itself just yet (it is and early RFC after all). For the concept itself I have a couple small suggestions:
Oh, no, I've missed those. I was working off -rc7. I'll try to re-integrate them in.
I'm not sure I like the name. "Pool" in the context of DMA-BUF feels like it means something else, like some new feature of DMA-BUFs exporters/importers can use for making buffer pools. How about just keep the "heap" terminology to prevent too much re-wording. Maybe just call this dma-buf/heaps/ ?
The name changing was mostly as Laura noted that the term heap has caused confusion historically. I'm not really particular, and I do worry about the naming overlap between dmabuf-pools and the pagepool code was problematic. Due to that overlap, renaming things back will be a small chore, but I've got only myself to blame there :)
Yeah I'm not set on changing the names. If everyone else finds heap to be descriptive enough, we can keep it.
Thanks, Laura