lkml.org 
[lkml]   [2010]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: questions about ttm_page_alloc.c
On 07/12/2010 06:39 PM, Dan Carpenter wrote:
> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

No it's fine, this code is for non x86 CPU, and on such platform
we assume wc == uncached and wb is normal (ie cached).

Cheers,
Jerome


\
 
 \ /
  Last update: 2010-07-13 01:15    [W:0.037 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site