linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jerome Glisse <j.glisse@gmail.com>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	thellstrom@vmware.com, thomas@shipmail.org, airlied@redhat.com,
	xen-devel@lists.xensource.com, j.glisse@redhat.com,
	bskeggs@redhat.com
Subject: Re: [PATCH 08/11] ttm: Provide DMA aware TTM page pool code.
Date: Tue, 1 Nov 2011 09:51:39 -0400	[thread overview]
Message-ID: <20111101135139.GC22652@phenom.dumpdata.com> (raw)
In-Reply-To: <20111031193722.GB3036@homer.localdomain>

> > +static struct dma_page *__ttm_dma_alloc_page(struct dma_pool *pool)
> > +{
> > +	struct dma_page *d_page;
> > +
> > +	d_page = kmalloc(sizeof(struct dma_page), GFP_KERNEL);
> > +	if (!d_page)
> > +		return NULL;
> > +
> > +	d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size,
> > +					   &d_page->dma,
> > +					   pool->gfp_flags);
> > +	d_page->p = virt_to_page(d_page->vaddr);
> > +	if (!d_page->vaddr) {
> > +		kfree(d_page);
> > +		d_page = NULL;
> > +	}
> 
> Move d_page->p = virt_to_page(d_page->vaddr); after if (!d_page->vaddr)
> block.

Duh! Yes.

.. snip..
> > +#if 0
> > +	if (nr_free > 1) {
> > +		pr_debug("%s: (%s:%d) Attempting to free %d (%d) pages\n",
> > +			pool->dev_name, pool->name, current->pid,
> > +			npages_to_free, nr_free);
> > +	}
> > +#endif

What is your feeling on those #if 0? I was not sure to keep them - they are useful
when debugging, but not so much during run-time? Rip them out and I can just
keep them in my 'debug' patch queue in case things go wrong?

Or perhas do it (rip 'em out) in 3 months time-frame?

.. snip..
> > +static struct dma_pool *ttm_dma_find_pool(struct device *dev,
> > +					  enum pool_type type)
> > +{
> > +	struct dma_pool *pool, *tmp, *found = NULL;
> > +
> > +	if (type == IS_UNDEFINED)
> > +		return found;
> > +	/* NB: We iterate on the 'struct dev' which has no spinlock, but
> > +	 * it does have a kref which we have taken. */
> 
> I fail to see where we kref dev.

Ah, I should document that more extensivly. That is done way way
earlier. As in in the path of the initialization of the driver:

drm_pci_init
  for non-KMS calls pci_dev_get()

  for KMS calls pci_register_driver..
      which calls 'driver_register' which called 'device_register'

And then during teardown (so unbind on sysfs), it ends up calling the devres
deconstructors which cleans up the 'struct device' dev_res, - in our case
ttm_dma_pool_release. However the nice thing is at that point of time all of
the calls to the TTM have quiseced so nobody is calling ttm for this device
anymore.

Let me stick this in the comment section.

> See comment above, otherwise:
> Reviewed-by: Jerome Glisse <jglisse@redhat.com>

Great! Thank you! 

  reply	other threads:[~2011-11-01 13:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-19 22:19 [PATCH] TTM DMA pool v2.1 Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 01/11] swiotlb: Expose swiotlb_nr_tlb function to modules Konrad Rzeszutek Wilk
2011-10-22  4:49   ` FUJITA Tomonori
2011-10-19 22:19 ` [PATCH 02/11] nouveau/radeon: Set coherent DMA mask Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 03/11] ttm/radeon/nouveau: Check the DMA address from TTM against known value Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 04/11] ttm: Wrap ttm_[put|get]_pages and extract GFP_* and caching states from 'struct ttm_tt' Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 05/11] ttm: Get rid of temporary scaffolding Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 06/11] ttm/driver: Expand ttm_backend_func to include two overrides for TTM page pool Konrad Rzeszutek Wilk
2011-10-22  9:40   ` Thomas Hellstrom
2011-10-24 17:27     ` Konrad Rzeszutek Wilk
2011-10-24 17:42       ` Thomas Hellstrom
2011-10-24 18:18         ` Konrad Rzeszutek Wilk
2011-11-01 14:37     ` Jerome Glisse
2011-11-01 14:48       ` Thomas Hellstrom
2011-10-19 22:19 ` [PATCH 07/11] ttm: Do not set the ttm->be to NULL before calling the TTM page pool to free pages Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 08/11] ttm: Provide DMA aware TTM page pool code Konrad Rzeszutek Wilk
2011-10-31 19:37   ` Jerome Glisse
2011-11-01 13:51     ` Konrad Rzeszutek Wilk [this message]
2011-10-19 22:19 ` [PATCH 09/11] ttm: Add 'no_dma' parameter to turn the TTM DMA pool off during runtime Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 10/11] nouveau/ttm/dma: Enable the TTM DMA pool if device can only do 32-bit DMA Konrad Rzeszutek Wilk
2011-10-19 22:19 ` [PATCH 11/11] radeon/ttm/dma: Enable the TTM DMA pool if the device can only do 32-bit Konrad Rzeszutek Wilk
2011-10-20  1:38 ` [PATCH] TTM DMA pool v2.1 Konrad Rzeszutek Wilk
2011-10-31 22:05 ` Jerome Glisse
  -- strict thread matches above, loose matches on Subject: below --
2011-11-01 18:47 [PATCH] TTM DMA pool v2.2 or [GIT PULL] (stable/ttm.dma_pool.v2.3) for 3.3 Konrad Rzeszutek Wilk
2011-11-01 18:47 ` [PATCH 08/11] ttm: Provide DMA aware TTM page pool code Konrad Rzeszutek Wilk

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=20111101135139.GC22652@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=airlied@redhat.com \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=j.glisse@gmail.com \
    --cc=j.glisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thellstrom@vmware.com \
    --cc=thomas@shipmail.org \
    --cc=xen-devel@lists.xensource.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).