On Mon, 2025-11-24 at 18:25 +0200, Jani Nikula wrote: > On Sun, 23 Nov 2025, Vinod Govindapillai > <[email protected]> wrote: > > One of the FBC instances can utilize the reserved area of SoC > > level cache for the fbc transactions to benefit reduced memory > > system power especially in idle scenarios. Reserved area of the > > system cache can be assigned to an fbc instance by configuring > > the cacheability configuration register with offset of the > > compressed frame buffer in stolen memoty of that fbc. There is > > a limit to this reserved area which is programmable and for > > xe3p_lpd the limit is defined as 2MB. > > > > v2: - better to track fbc sys cache usage from intel_display level, > > sanitize the cacheability config register on probe (Matt) > > - limit this for integrated graphics solutions, confirmed that > > no default value set for cache range by hw (Gustavo) > > > > v3: - changes related to the use of fbc substruct in intel_display > > - use intel_de_write() instead of intel_rmw() by hardcoding the > > default value fields > > Overall issue: The fbc mutexes are per fbc instance, but nothing > protects display->fbc.sys_cache_id.
The places where this sys_cache_id can be changed to a valid fbc instance id + fbc cfb offset are protected by the fbc mutex as part of intel_fbc_enable and intel_fbc_disable. That's is what I was mentioning in my prev reply. And the places where this sys cache usage register reset happens is outside the fbc context - where sanitize and remove module gets called. I don't see a need to update the fbc.sys_cache_id from anywhere else. BR Vinod > > BR, > Jani. > >
