Jerome Glisse wrote: > 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. > > Ah, OK. You could adjust this behavior in bo_driver::evict_flags. For VRAM eviction, you can do:
return (cur_placement &~TTM_PL_MASK_CACHING) | TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED; Looks like openChrome may also benefit from this... /Thomas ------------------------------------------------------------------------------ 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
