drm/i915/fbc: Rework cfb stride/size calculations
The code to calculate the cfb stride/size is a bit of mess. The cfb size is getting calculated based purely on the plane stride and plane height. That doesn't account for extra alignment we want for the cfb stride. The gen9 override stride OTOH is just calculated based on the plane width, and it does try to make things more aligned but any extra alignment added there is not considered in the cfb size calculations. So not at all convinced this is working as intended. Additionally the compression limit handling is split between the cfb allocation code and g4x_dpfc_ctl_limit() (for the 16bpp case), which is just confusing. Let's streamline the whole thing: - Start with the plane stride, convert that into cfb stride (cfb is always 4 bytes per pixel). All the calculations will assume 1:1 compression limit since that will give us the max values, and we don't yet know how much stolen memory we will be able to allocate - Align the cfb stride to 512 bytes on modern platforms. This guarantees the 4 line segment will be 512 byte aligned regardles of the final compression limit we choose later. The 512 byte alignment for the segment is required by at least some of the platforms, and just doing it always seems like the easiest option - Figure out if we need to use the override stride or not. For X-tiled it's never needed since the plane stride is already 512 byte aligned, for Y-tiled it will be needed if the plane stride is not a multiple of 512 bytes, and for linear it's apparently always needed because the hardware miscalculates the cfb stride as PLANE_STRIDE*512 instead of the PLANE_STRIDE*64 that it use with linear. - The cfb size will be calculated based on the aligned cfb stride to guarantee we actually reserved enough stolen memory and the FBC hw won't end up scribbling over whatever else is allocated in stolen - The compression limit handling we just do fully in the cfb allocation code to make things less confusing v2: Write the min cfb segment stride calculation in a more explicit way to make it clear what is going on v3: Remeber to update fbc->limit when changing to 16bpp Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v2 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210923042151.19052-1-ville.syrjala@linux.intel.com
Showing
Please register or sign in to comment