All of lore.kernel.org
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	John Stultz <john.stultz@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: ion: Add a default struct device for cma heap
Date: Thu, 6 Aug 2015 23:25:15 +0800	[thread overview]
Message-ID: <20150806152515.GA30274@shbuild888> (raw)
In-Reply-To: <xa1t8u9owspf.fsf@mina86.com>

Hi Michal,

Thanks for the review!

On Thu, Aug 06, 2015 at 01:40:28PM +0200, Michal Nazarewicz wrote:
> On Thu, Aug 06 2015, Feng Tang wrote:
> > When trying to use several cma heaps on our platforms,
> > we met a memory issue due to that the several cma_heaps
> > are sharing the same "struct device *".
> >
> > As in current code base, the normal cma heap creating
> > process is, one platform device is created during boot,
> > and it will sequentially create cma heaps (usually passing
> > its own struct device * as a parameter)
> >
> > For the multiple cma heaps case, there will be one "struct
> > cma" created for each cma heap, and this "struct cma *" is
> > saved in dev->cma_area. So the single platform device can't
> > meet the requirement here.
> >
> > So this patch add one default device for a cma heap to avoid
> > sharing the same "struct device", thus fix the issue. And it
> > doesn't break existing code by only using that default device
> > when no "struct device *" is passed in.
> >
> > Also, since the cma framework has been cleaned up, this patch
> > also add a platform data member to pass the "struct cma*" to
> > ion_cma_heap_create().
> >
> > Signed-off-by: Feng Tang <feng.tang@intel.com>
> 
> >From CMA’s point of view:
> 
> Acked-by: Michal Nazarewicz <mina86@mina86.com>
> 
> > ---
> >  drivers/staging/android/ion/ion.h          |    4 ++++
> >  drivers/staging/android/ion/ion_cma_heap.c |   20 +++++++++++++++++---
> >  2 files changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/android/ion/ion.h b/drivers/staging/android/ion/ion.h
> > index 443db84..e9af17e 100644
> > --- a/drivers/staging/android/ion/ion.h
> > +++ b/drivers/staging/android/ion/ion.h
> > @@ -45,6 +45,9 @@ struct ion_buffer;
> >   * @size:	size of the heap in bytes if applicable
> >   * @align:	required alignment in physical memory if applicable
> >   * @priv:	private info passed from the board file
> > + * @priv2:	when creating CMA heap, platform device should better also
> > + *		pass the "struct cma *" info, so that the cma buffer request
> > + *		know where to go for the buffer
> >   *
> >   * Provided by the board file.
> >   */
> > @@ -56,6 +59,7 @@ struct ion_platform_heap {
> >  	size_t size;
> >  	ion_phys_addr_t align;
> >  	void *priv;
> > +	void *priv2;
> 
> Why are those void pointers anyway? Perhaps just make them struct device
> *dev and struct cma *cma? Especially since priv2 is a bit awkward name.
 
My initial thought is the same, but as there are several other kinds of ion
heaps which are also using this structure for their own
ion_xxx_heap_create(struct ion_platform_heap *), I gave up using the
explicit "struct cma *", in case other kinds of heaps may need to use
this additional priv2 in future

> > +	 * data->priv for cma heap is currently supposed to point
> > +	 * to a "struct device *"
> > +	 */
> > +	if (data->priv) {
> > +		cma_heap->dev = data->priv;
> > +	} else {
> > +		cma_heap->dev = &cma_heap->default_dma_dev;
> > +		cma_heap->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> > +		cma_heap->dev->dma_mask = &dev->coherent_dma_mask;
> > +	}
> > +
> > +	/* data->priv2 contains a pointer to struct cma */
> > +	dev_set_cma_area(cma_heap->dev, data->priv2);
> 
> Perhaps:
> 
> +	if (data->priv2)
> +		dev_set_cma_area(cma_heap->dev, data->priv2);

Yes, this looks more logical, even though the cma_heap structure is
kzalloced.

Thanks,
Feng

  reply	other threads:[~2015-08-06 15:16 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06 10:24 [PATCH] staging: ion: Add a default struct device for cma heap Feng Tang
2015-08-06 11:40 ` Michal Nazarewicz
2015-08-06 15:25   ` Feng Tang [this message]
2015-08-06 16:57     ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150806152515.GA30274@shbuild888 \
    --to=feng.tang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=john.stultz@linaro.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mina86@mina86.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.