linux-toradex.git/include/drm/drm_fourcc.h, branch v4.11

drm: move allocation out of drm_get_format_name()

2016-11-12T13:19:38+00:00

The function's behaviour was changed in 90844f00049e, without changing
its signature, causing people to keep using it the old way without
realising they were now leaking memory.
Rob Clark also noticed it was also allocating GFP_KERNEL memory in
atomic contexts, breaking them.

Instead of having to allocate GFP_ATOMIC memory and fixing the callers
to make them cleanup the memory afterwards, let's change the function's
signature by having the caller take care of the memory and passing it to
the function.
The new parameter is a single-field struct in order to enforce the size
of its buffer and help callers to correctly manage their memory.

Fixes: 90844f00049e ("drm: make drm_get_format_name thread-safe")
Cc: Rob Clark 
Cc: Christian König 
Acked-by: Christian König 
Acked-by: Rob Clark 
Acked-by: Sinclair Yeh  (vmwgfx)
Reviewed-by: Jani Nikula 
Suggested-by: Ville Syrjälä 
Signed-off-by: Eric Engestrom 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20161112011309.9799-1-eric@engestrom.ch

drm: Don't export the drm_fb_get_bpp_depth() function

2016-10-18T09:54:08+00:00

The function is only used by the drm_helper_mode_fill_fb_struct() core
function to fill the drm_framebuffer bpp and depth fields, used by
drivers that haven't been converted to use pixel formats directly yet.
It should not be used by new drivers, so inline it in its only caller.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen 
Signed-off-by: Archit Taneja 
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-14-git-send-email-laurent.pinchart@ideasonboard.com

drm: WARN when calling drm_format_info() for an unsupported format

2016-10-18T09:51:38+00:00

The format helpers have historically treated unsupported formats as part
of the default case, returning values that are likely wrong. We can't
change this behaviour now without risking breaking drivers in difficult
to detect ways, but we can WARN on unsupported formats to catch faulty
callers.

The only exception is the framebuffer_check() function that calls
drm_format_info() to validate the format passed from userspace. This is
a valid use case that shouldn't generate a warning.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Tomi Valkeinen 
Signed-off-by: Archit Taneja 
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-5-git-send-email-laurent.pinchart@ideasonboard.com

drm: Centralize format information

2016-10-18T09:50:34+00:00

Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to multiple lookups.

Centralize all format information in a data structure and create a
function to look up information based on the format 4CC.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Daniel Vetter 
Reviewed-by: Eric Engestrom 
Signed-off-by: Archit Taneja 
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-2-git-send-email-laurent.pinchart@ideasonboard.com

drm: move drm_mode_legacy_fb_format to drm_fourcc.c

2016-08-29T13:37:28+00:00

It's part of the drm fourcc handling code, mapping the old depth/bpp
values to new fourcc codes.

Cc: Laurent Pinchart 
Reviewed-by: Archit Taneja 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-6-daniel.vetter@ffwll.ch

drm: remove `const` attribute to hint at caller that they now own the memory

2016-08-16T12:06:53+00:00

Signed-off-by: Eric Engestrom 
Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter

drm: make drm_get_format_name thread-safe

2016-08-15T07:25:12+00:00

Signed-off-by: Eric Engestrom 
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter

drm: Move format-related helpers to drm_fourcc.c

2016-06-09T09:58:50+00:00

The drm_crtc.c file is a mess, making the ABI documentation confusing
since all functions are in the same bag. Split the format-related
helpers to a new drm_fourcc.c file.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1465466048-2020-1-git-send-email-laurent.pinchart@ideasonboard.com

UAPI: (Scripted) Disintegrate include/drm

2012-10-04T17:21:50+00:00

Signed-off-by: David Howells 
Acked-by: Arnd Bergmann 
Acked-by: Thomas Gleixner 
Acked-by: Michael Kerrisk 
Acked-by: Paul E. McKenney 
Acked-by: Dave Jones

Merge tag 'v3.6-rc7' into drm-intel-next-queued

2012-09-24T16:17:12+00:00

Manual backmerge of -rc7 to resolve a silent conflict leading to
compile failure in drivers/gpu/drm/i915/intel_hdmi.c.

This is due to the bugfix in -rc7:

commit b98b60167279df3acac9422c3c9820d9ebbcf9fb
Author: Wang Xingchao 
Date:   Thu Sep 13 07:43:22 2012 +0800

    drm/i915: HDMI - Clear Audio Enable bit for Hot Plug

Since this code moved around a lot in -next git put that snippet at
the wrong spot. I've tried to fix this by making the conflict explicit
by merging a version for next with:

commit 3cce574f0190dd149472059fb69267cf83d290f9
Author: Wang Xingchao 
Date:   Thu Sep 13 11:19:00 2012 +0800

    drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally

But that failed to solve the entire problem. To avoid pushing out
further -nightly branch to our QA where this is broken, do the
backmerge and manually add the stuff git adds to -next from the patch
in -fixes.

Note that this doesn't show up in git's merge diff (and hence is also
not handled by git rerere), which adds to the reasons why I'd like to
fix this with a verbose backmerge. The git merge diff only shows a
bunch of trivial conflicts of the "code changed in lines next to each
another" kind.

Signed-off-by: Daniel Vetter