On Thu, May 12, 2016 at 05:00:06PM +0300, Imre Deak wrote:
On Thu, 2016-05-12 at 16:52 +0300, Ville Syrjälä wrote:
On Thu, May 12, 2016 at 04:43:05PM +0300, Imre Deak wrote:
On Thu, 2016-05-12 at 16:10 +0300, Ville Syrjälä wrote:
On Thu, May 12, 2016 at 04:00:38PM +0300, Imre Deak wrote:
Returning a 0 bpp/cpp value from these functions isn't ever valid. In many cases it can also lead to a div-by-zero possibly at some later point in time, so make sure we catch such errors as soon as possible via louder error reporting.
CC: Dave Airlie airlied@redhat.com Signed-off-by: Imre Deak imre.deak@intel.com
drivers/gpu/drm/drm_crtc.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 70f9c68..3a32606 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -5610,8 +5610,8 @@ void drm_fb_get_bpp_depth(uint32_t format, unsigned int *depth, *bpp = 32; break; default:
DRM_DEBUG_KMS("unsupported pixel format %s\n",drm_get_format_name(format));
WARN(1, "unsupported pixel format %s\n",drm_get_format_name(format));NAK. This will happen every time drm_helper_mode_fill_fb_struct() is called with a non-RGB format.
Yep, missed that. So how about handling here those formats explicitly, and emitting a warning only for truly unsupported formats?
More work to keep this list updated, and it wouldn't prevent any div-by-zero with those formats. So I don't really see a point in that.
It would avoid the incorrect 'unsupported pixel format' message for those.
If that's the entire concern, delete it. New drivers shouldn't use these functions any more anyway. -Daniel