How about I don't export "reserve" APIs in the next version? The "reserve" stuff is totally for init and keeping current logic unchanged. I'm scared of regression. :(
-----Original Message----- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Tuesday, August 22, 2017 9:08 PM To: Wang, Zhi A <zhi.a.w...@intel.com>; intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org Cc: joonas.lahti...@linux.intel.com; zhen...@linux.intel.com; Wang, Zhi A <zhi.a.w...@intel.com> Subject: Re: [RFCv2 2/3] drm/i915: Introduce private PAT management Quoting Chris Wilson (2017-08-22 19:01:11) > Quoting Zhi Wang (2017-08-23 02:44:12) > > The private PAT management is to support both static and dynamic > > PPAT entry manipulation. During the initialization, the PPAT indexes > > with specific PPAT values could be reserved and set by intel_ppat_reserve. > > The unused PPAT entries can be allocated/freed later at runtime. Two > > APIs are introduced for dynamically managing PPAT entries: > > intel_ppat_get and intel_ppat_set. > > What's the use case for reserved? Once assigned, a new allocation > doesn't evict, so reservation is just another form of assignment. Or rather, I can see the differentiation you want for init, but I can't see why you want to export it (since it ignores the ppat controller) or why you need to have a reserved bit, since you can just elevate the refcount. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
