[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100712223905.GH5658@bicker>
Date: Tue, 13 Jul 2010 00:39:05 +0200
From: Dan Carpenter <error27@...il.com>
To: suokkos@...il.com
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: questions about ttm_page_alloc.c
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists