[PATCH 0/4] Fix memory limits for STDU

[Zack Rusin]

On Thu, Apr 11, 2024 at 5:27 PM Ian Forbes <ian.forbes at broadcom.com> wrote:
>
> Fixes a bug where modes that are too large for the device are exposed
> and set causing a black screen on boot.
>
> Resending as Patchwork did not like my last submission.
>
> Ian Forbes (4):
>   drm/vmwgfx: Filter modes which exceed graphics memory
>   drm/vmwgfx: 3D disabled should not effect STDU memory limits
>   drm/vmwgfx: Remove STDU logic from generic mode_valid function
>   drm/vmwgfx: Standardize use of kibibytes when logging
>
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c           | 19 ++++-------
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h           |  3 --
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  4 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c           | 26 ++++++---------
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c          | 32 ++++++++++++++++++-
>  5 files changed, 48 insertions(+), 36 deletions(-)
>

In general that looks great! Two questions:
- with stdu what happens when the mode selected is close to our
limits, the guest is using a hardware cursor and we allocate cursor
mobs?
- with legacy du, is general mode selection with modes close to vram
size working?

And one comment: in series like those, be careful with fixes tags if
the patches depend on each other, i.e. the third one depends on the
first but they have different fixes tags so they're disconnected. It's
a good idea to keep distro kernel maintainers in mind with those and
try to organize the patches in a way that makes it a bit more clearer
that #3 depends on #1. It should be fine in this case though.

z