On Mon, 2009-04-20 at 14:50 +0200, Thomas Hellström wrote: > Jerome Glisse wrote: > > On Mon, 2009-04-20 at 14:02 +0200, Jerome Glisse wrote: > > > >> On Mon, 2009-04-20 at 12:13 +0200, Thomas Hellstrom wrote: > >> > >>> If there was an erratum causing PAT not to be enabled on your processor, > >>> then definitely that > >>> may have cause strange inconsistencies. > >>> > >>> Thanks, > >>> Thomas. > >>> > >> I think ttm_tt caching stuff does follow kernel policies outlined > >> in Documentation/x86/pat.txt well at least from understanding of > >> code i have right now through (call chains being sometimes hard > >> to fully follow). As also have another issue it seems that calling > >> set_memory_(uc|wc) while suspending lockup the cpu or at least doesn't > >> return, is this somethings i should expect ? > >> > >> Cheers, > >> Jerome > >> > >> > > > > Speaking about caching i think we should only call > > ttm_tt_set_placement_caching in mmap function as otherwise it's > > useless to waste time changing cache policy, > > > Jerome, > The current code should never change caching policy when it's not > strictly needed. > If you hit such a case, it's probably a bug. > > Could you illustrate a case where you're seeing this? > > /Thomas >
My problem is on vram eviction on suspend, vram memory is flag as WC so it allocate a ttm and try to set it to wc which fails badly. This why i was thinking of setting cache properties in mmap and not in validate or a path hit by bo_move. Btw i think set_memory_wb is fine only wc|uc isn't i will try to take a look at kernel code see if i see anythings obvious or then ask on lkml what to know if it should work or not. Cheers, Jerome ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
