This reverts commit cfeff354f70bb1d0deb0279506e3f7989bc16e28. A core design consideration with legacy cursor updates is that the cursor must not touch any other plane, even if we were to force it to take the slow path. That is the real reason why the cursor uses a fixed ddb allocation, not because bspec says so. Treating cursors as any other plane during ddb allocation violates that, which means we can now pull other planes into fully unsynced legacy cursor mailbox commits. That is definitely not something we've ever considered when designing the rest of the code. The noarm+arm register write split in particular makes that dangerous as previous updates can get disarmed pretty much at any random time, and not necessarily in an order that is actually safe (eg. against ddb overlaps). So if we were to do this then: - someone needs to expend the appropriate amount of brain cells thinking through all the tricky details - we should do it for all skl+ platforms since all of those have double buffered wm/ddb registers. The current arbitrary mtl+ cutoff doesn't really make sense For the moment just go back to the original behaviour where the cursor's ddb alloation does not change outside of modeset/fastset. As of now anything else isn't safe. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231213102519.13500-10-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com>