All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <error27@gmail.com>
To: suokkos@gmail.com
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: questions about ttm_page_alloc.c
Date: Tue, 13 Jul 2010 00:39:05 +0200	[thread overview]
Message-ID: <20100712223905.GH5658@bicker> (raw)

I'm investigating: https://bugzilla.kernel.org/show_bug.cgi?id=16337

He is using the new radeon with the new ttm pool wc/uc page allocator.
I'm sort of over my head when it comes to mm stuff so forgive me if
these are dumb questions...  I'm looking at 
drivers/gpu/drm/ttm/ttm_page_alloc.c.

   230  static int set_pages_array_wc(struct page **pages, int addrinarray)
   231  {
   232  #ifdef TTM_HAS_AGP
   233          int i;
   234  
   235          for (i = 0; i < addrinarray; i++)
   236                  map_page_into_agp(pages[i]);
			^^^^^^^^^^^^^^^^^^^^^^^^^^^

	This actually sets the pages to uncached and not to write
	cached.  Is that deliberate?

   237  #endif
   238          return 0;
   239  }

[snip]

   327                  pages_to_free[freed_pages++] = p;
   328                  /* We can only remove NUM_PAGES_TO_ALLOC at a time. */
   329                  if (freed_pages >= NUM_PAGES_TO_ALLOC) {
   330                          /* remove range of pages from the pool */
   331                          __list_del(p->lru.prev, &pool->list);

	Why do we use p->lru.prev here when we use &p->lru in other
	places?

   332  
   333                          ttm_pool_update_free_locked(pool, freed_pages);
   334                          /**
   335                           * Because changing page caching is costly
   336                           * we unlock the pool to prevent stalling.

regards,
dan carpenter

             reply	other threads:[~2010-07-12 22:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-12 22:39 Dan Carpenter [this message]
2010-07-12 23:12 ` questions about ttm_page_alloc.c Jerome Glisse
2010-07-22 11:56   ` Dan Carpenter
2010-07-22 14:10     ` Jerome Glisse

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=20100712223905.GH5658@bicker \
    --to=error27@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=suokkos@gmail.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.