drm: Document mode_config.max_width/height as the max fb dimensions
authorVille Syrjälä <ville.syrjala@linux.intel.com>
Fri, 15 Jun 2018 17:39:39 +0000 (20:39 +0300)
committerVille Syrjälä <ville.syrjala@linux.intel.com>
Thu, 21 Jun 2018 16:16:07 +0000 (19:16 +0300)
commit8d4f4b82155cc6774d0fd8aaafb882566f7fd5fb
treeab03c298f16f4bf3c67b755e63261fc6f0aad092
parentc612ae0503af753c062594dcd14aecea121fa414
drm: Document mode_config.max_width/height as the max fb dimensions

The meaning of the mode_config max_width/height fields has not been
entirely clear. They are used both as the max framebuffer dimensions,
and they are also used by drm_mode_getconnector() to filter out
any mode whose hdisplay/vdisplay exceed those limits.

Let's put it in writing that max_width/height only refrer to the max
framebuffer dimensions, and should those be higher than the hardware
limits for display timings the driver must validate the latter using
some other means.

We'll keep the max_width/height usage in drm_mode_getconnector()
because setcrtc treats hdisplay/vdisplay also as the primary plane
width, and having a plane bigger than the max fb size doesn't make
much sense (if we ignore scaling that is). It all works out fine
as long as the max fb dimensions are at least equal to the max
timing limits. If the opposite were true we may want to rethink
what drm_mode_getconnector() does. Maybe do the mode filtering
only for non-atomic userspace?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180615173939.11353-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
include/drm/drm_mode_config.h