From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752064AbbHEJKI (ORCPT ); Wed, 5 Aug 2015 05:10:08 -0400 Received: from mga02.intel.com ([134.134.136.20]:38767 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751343AbbHEJKG (ORCPT ); Wed, 5 Aug 2015 05:10:06 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,615,1432623600"; d="scan'208";a="742541815" Date: Wed, 5 Aug 2015 17:19:17 +0800 From: Feng Tang To: Michal Nazarewicz Cc: "linux-kernel@vger.kernel.org" , "m.szyprowski@samsung.com" , "kyungmin.park@samsung.com" , "akpm@linux-foundation.org" , "iamjoonsoo.kim@lge.com" , "john.stultz@linaro.org" Subject: Re: [PATCH] CMA: Don't return a valid cma for non-cma dev Message-ID: <20150805091917.GA27241@shbuild888> References: <1438223828-26140-1-git-send-email-feng.tang@intel.com> <1438311070.4299.1.camel@intel.com> <20150731151816.GA18347@shbuild888> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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