[Intel-gfx] [RFCv2 2/3] drm/i915: Introduce private PAT management

[Wang, Zhi A]

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:chris at chris-wilson.co.uk] 
Sent: Tuesday, August 22, 2017 9:08 PM
To: Wang, Zhi A <zhi.a.wang at intel.com>; intel-gfx at lists.freedesktop.org; intel-gvt-dev at lists.freedesktop.org
Cc: joonas.lahtinen at linux.intel.com; zhenyuw at linux.intel.com; Wang, Zhi A <zhi.a.wang at 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