On Thu, Dec 10, 2020 at 12:15:15AM -0800, John Stultz wrote: > On Wed, Dec 9, 2020 at 3:53 PM Minchan Kim <minchan@xxxxxxxxxx> wrote: > > On Wed, Nov 18, 2020 at 07:19:07PM -0800, John Stultz wrote: > > > The CMA heap currently only registers the default CMA heap, as we > > > didn't want to expose all CMA regions and there's otherwise no way to > > > pick and choose. > > > > Yub. > > > > dma-buf really need a way to make exclusive CMA area. Otherwise, default > > CMA would be shared among drivers and introduce fragmentation easily > > since we couldn't control other drivers. In such aspect, I don't think > > current cma-heap works if userspace needs big memory chunk. > > Yes, the default CMA region is not always optimal. > > That's why I was hopeful for Kunihiko Hayashi's patch to allow for > exposing specific cma regions: > https://lore.kernel.org/lkml/1594948208-4739-1-git-send-email-hayashi.kunihiko@xxxxxxxxxxxxx/ > > I think it would be a good solution, but all we need is *some* driver > which can be considered the primary user/owner of the cma region which > would then explicitly export it via the dmabuf heaps. > > > Here, the problem is there is no in-kernel user to bind the specific > > CMA area because the owner will be random in userspace via dma-buf > > interface. > > Well, while I agree that conceptually the dmabuf heaps allow for > allocations for multi-device pipelines, and thus are not tied to > specific devices. I do think that the memory types exposed are likely > to have specific devices/drivers in the pipeline that it matters most > to. So I don't see a big issue with the in-kernel driver registering a > specific CMA region as a dmabuf heap. Then, I am worry about that we spread out dma_heap_add_cma to too many drivers since kernel doesn't how userspace will use it. For example, system 1 could have device A-B-C pipeline so they added it A driver. After that, system 2 could have device B-C-D pipeline so they add dma_heap_add_cma into B device. > > > > > Is there a reason to use dma-heap framework to add cma-area for specific device ? > > > > > > > > Even if some in-tree users register dma-heap with cma-area, the buffers could be allocated in user-land and these could be shared among other devices. > > > > For exclusive access, I guess, the device don't need to register dma-heap for cma area. > > > > > > > > > > It's not really about exclusive access. More just that if you want to > > > bind a memory reservation/region (cma or otherwise), at least for DTS, > > > it needs to bind with some device in DT. > > > > > > Then the device driver can register that region with a heap driver. > > > This avoids adding new Linux-specific software bindings to DT. It > > > becomes a driver implementation detail instead. The primary user of > > > the heap type would probably be a practical pick (ie the display or > > > isp driver). > > > > If it's the only solution, we could create some dummy driver which has > > only module_init and bind it from there but I don't think it's a good > > idea. > > Yea, an un-upstreamable dummy driver is maybe what it devolves to in > the worst case. But I suspect it would be cleaner for a display or ISP > driver that benefits most from the heap type to add the reserved > memory reference to their DT node, and on init for them to register > the region with the dmabuf heap code. As I mentioned above, it could be a display at this moment but it could be different driver next time. If I miss your point, let me know. Thanks for the review, John. > > > > > The other potential solution Rob has suggested is that we create some > > > tag for the memory reservation (ie: like we do with cma: "reusable"), > > > which can be used to register the region to a heap. But this has the > > > problem that each tag has to be well defined and map to a known heap. > > > > Do you think that's the only solution to make progress for this feature? > > Then, could you elaborate it a bit more or any other ideas from dma-buf > > folks? > > I'm skeptical of that DT tag approach working out, as we'd need a new > DT binding for the new tag name, and we'd have to do so for each new > heap type that needs this (so non-default cma, your chunk heap, > whatever other similar heap types that use reserved regions folks come > up with). Having *some* driver take ownership for the reserved region > and register it with the appropriate heap type seems much > cleaner/flexible and avoids mucking with the DT ABI. > > thanks > -john
