Re: [PATCH] CMA: Don't return a valid cma for non-cma dev

[Feng Tang <feng.tang@intel.com>]

On Fri, Jul 31, 2015 at 07:46:30PM +0200, Michal Nazarewicz wrote:
> On Fri, Jul 31 2015, Feng Tang wrote:
> > Maybe I didn't make my problem clear, for our platform, we do need to
> > use cma as we have camera ISP which has no IOMMU, so we cannot set
> > "cma=0".
> 
> Then specify a CMA region for the camera in platform initialisation code
> or device trees or whatever else is the rave nowadays.
> 
> I’m assuming that you have a piece of code (or configuration of some
> sort) that assigns a CMA region to the device (otherwise ‘dev->cma_area’
> would be NULL and your patch would just always get you NULL CMA area).
> Simply create a CMA area there and assign it to the device.

Your suggestion remind me one more thing, that for a system which needs
multiple cma heaps (like for security reason), they may have to share
one struct device *dev, as in ion_cma_heap_create()

struct ion_heap *ion_cma_heap_create(struct ion_platform_heap *data)
{
	struct ion_cma_heap *cma_heap;

	cma_heap = kzalloc(sizeof(struct ion_cma_heap), GFP_KERNEL);

	if (!cma_heap)
		return ERR_PTR(-ENOMEM);

	cma_heap->heap.ops = &ion_cma_ops;
	/* get device from private heaps data, later it will be
	 * used to make the link with reserved CMA memory */
	cma_heap->dev = data->priv;
	cma_heap->heap.type = ION_HEAP_TYPE_DMA;
	return &cma_heap->heap;
}

Usually the platform data's priv points to the same ion platform device,
so the several heap's dev will be same.

Then when the time comes to allocate for each cma heap, the "dev->cma_area"
may have to be dynamically switched, and casue many syncing trouble.

I'm working on a patch for this. 

Thanks,
Feng