aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_framebuffer.c
AgeCommit message (Collapse)AuthorFilesLines
2016-12-15drm: Nuke fb->bits_per_pixelVille Syrjälä1-1/+1
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8. Less duplicated information is a good thing. Note that I didn't put parens around the cpp*8 in the below cocci script, on account of not wanting spurious parens all over the place. Instead I did the unsafe way, and tried to look over the entire diff to spot if any dangerous expressions were produced. I didn't see any. There are some cases where previously the code did X*bpp/8, so the division happened after the multiplication. Those are now just X*cpp so the division effectively happens before the multiplication, but that is perfectly fine since bpp is always a multiple of 8. @@ struct drm_framebuffer *FB; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ i9xx_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ ironlake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ skylake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer FB; expression E; @@ ( - E * FB.bits_per_pixel / 8 + E * FB.format->cpp[0] | - FB.bits_per_pixel / 8 + FB.format->cpp[0] | - E * FB.bits_per_pixel >> 3 + E * FB.format->cpp[0] | - FB.bits_per_pixel >> 3 + FB.format->cpp[0] | - (FB.bits_per_pixel + 7) / 8 + FB.format->cpp[0] | - FB.bits_per_pixel + FB.format->cpp[0] * 8 | - FB.format->cpp[0] * 8 != 8 + FB.format->cpp[0] != 1 ) @@ struct drm_framebuffer *FB; expression E; @@ ( - E * FB->bits_per_pixel / 8 + E * FB->format->cpp[0] | - FB->bits_per_pixel / 8 + FB->format->cpp[0] | - E * FB->bits_per_pixel >> 3 + E * FB->format->cpp[0] | - FB->bits_per_pixel >> 3 + FB->format->cpp[0] | - (FB->bits_per_pixel + 7) / 8 + FB->format->cpp[0] | - FB->bits_per_pixel + FB->format->cpp[0] * 8 | - FB->format->cpp[0] * 8 != 8 + FB->format->cpp[0] != 1 ) @@ struct drm_plane_state *state; expression E; @@ ( - E * state->fb->bits_per_pixel / 8 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel / 8 + state->fb->format->cpp[0] | - E * state->fb->bits_per_pixel >> 3 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel >> 3 + state->fb->format->cpp[0] | - (state->fb->bits_per_pixel + 7) / 8 + state->fb->format->cpp[0] | - state->fb->bits_per_pixel + state->fb->format->cpp[0] * 8 | - state->fb->format->cpp[0] * 8 != 8 + state->fb->format->cpp[0] != 1 ) @@ @@ - (8 * 8) + 8 * 8 @@ struct drm_framebuffer FB; @@ - (FB.format->cpp[0]) + FB.format->cpp[0] @@ struct drm_framebuffer *FB; @@ - (FB->format->cpp[0]) + FB->format->cpp[0] @@ @@ struct drm_framebuffer { ... - int bits_per_pixel; ... }; v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent) v3: Adjusted the semantic patch a bit and regenerated due to code changes Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Alex Deucher <[email protected]> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-15drm: Nuke fb->depthVille Syrjälä1-1/+1
Replace uses of fb->depth with fb->format->depth. Less duplicate information is a good thing. @@ struct drm_framebuffer *fb; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - fb->depth = E; ... } @@ struct nouveau_framebuffer *fb; @@ - fb->base.depth + fb->base.format->depth @@ struct drm_framebuffer fb; @@ - fb.depth + fb.format->depth @@ struct drm_framebuffer *fb; @@ - fb->depth + fb->format->depth @@ struct drm_framebuffer fb; @@ - (fb.format->depth) + fb.format->depth @@ struct drm_framebuffer *fb; @@ - (fb->format->depth) + fb->format->depth @@ @@ struct drm_framebuffer { ... - unsigned int depth; ... }; v2: Drop the vmw stuff (Daniel) Rerun spatch due to code changes Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-15drm: Add drm_framebuffer_plane_{width,height}()Ville Syrjälä1-0/+44
Add variants of drm_format_plane_{width,height}() that take an entire fb object instead of just the format. These should be more efficent as they can just look up the format info from the fb->format pointer rather than having to look it up (using a linear search based on the format). Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-15drm: Reject fbs w/o format info in drm_framebuffer_init()Ville Syrjälä1-1/+1
Any framebuffer that doesn't have proper format information when drm_framebuffer_init() is called is a bug. Let's warn and return an error to avoid oopsing the kernel later due to dereferencing the NULL fb->format pointer. Cc: Laurent Pinchart <[email protected]> Suggested-by: Laurent Pinchart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Laurent Pinchart <[email protected]>
2016-12-15drm: Populate fb->dev from drm_helper_mode_fill_fb_struct()Ville Syrjälä1-1/+4
Populating fb->dev before drm_framebuffer_init() allows us to use fb->dev already while validating the framebuffer. Let's have drm_helper_mode_fill_fb_struct() do that for us. Also make drm_framebuffer_init() warn us if a different device pointer is passed to it than was passed to drm_helper_mode_fill_fb_struct(). v2: Reject fbs with invalid fb->dev (Laurent) Cc: Laurent Pinchart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Alex Deucher <[email protected]> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-17drm: Nuke modifier[1-3]Ville Syrjälä1-0/+7
It has been suggested that having per-plane modifiers is making life more difficult for userspace, so let's just retire modifier[1-3] and use modifier[0] to apply to the entire framebuffer. Obviosuly this means that if individual planes need different tiling layouts and whatnot we will need a new modifier for each combination of planes with different tiling layouts. For a bit of extra backwards compatilbilty the kernel will allow non-zero modifier[1+] but it require that they will match modifier[0]. This in case there's existing userspace out there that sets modifier[1+] to something non-zero with planar formats. Mostly a cocci job, with a bit of manual stuff mixed in. @@ struct drm_framebuffer *fb; expression E; @@ - fb->modifier[E] + fb->modifier @@ struct drm_framebuffer fb; expression E; @@ - fb.modifier[E] + fb.modifier Cc: Kristian Høgsberg <[email protected]> Cc: Ben Widawsky <[email protected]> Cc: Rob Clark <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Tomeu Vizoso <[email protected]> Cc: [email protected] Suggested-by: Kristian Høgsberg <[email protected]> Acked-by: Ben Widawsky <[email protected]> Acked-by: Daniel Stone <[email protected]> Acked-by: Rob Clark <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-12drm: move allocation out of drm_get_format_name()Eric Engestrom1-3/+4
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 <[email protected]> Cc: Christian König <[email protected]> Acked-by: Christian König <[email protected]> Acked-by: Rob Clark <[email protected]> Acked-by: Sinclair Yeh <[email protected]> (vmwgfx) Reviewed-by: Jani Nikula <[email protected]> Suggested-by: Ville Syrjälä <[email protected]> Signed-off-by: Eric Engestrom <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-08drm: update the documentation of drm_framebuffer_unregister_privateRongrong Zou1-0/+5
Add obvious description to drm_framebuffer_unregister_private() to explain it is deprecated. Signed-off-by: Rongrong Zou <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-10-18drm: WARN when calling drm_format_info() for an unsupported formatLaurent Pinchart1-1/+1
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 <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-5-git-send-email-laurent.pinchart@ideasonboard.com
2016-10-18drm: Use drm_format_info() in DRM core codeLaurent Pinchart1-90/+12
Replace calls to the drm_format_*() helper functions with direct use of the drm_format_info structure. This improves efficiency by removing duplicate lookups. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Eric Engestrom <[email protected]> Signed-off-by: Archit Taneja <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-4-git-send-email-laurent.pinchart@ideasonboard.com
2016-09-22drm: Extract drm_plane.[hc]Daniel Vetter1-0/+26
Just pure code movement, cleanup and polish will happen in later patches. v2: Don't forget all the ioctl! To extract those cleanly I decided to put check_src_coords into drm_framebuffer.c (and give it a drm_framebuffer_ prefix), since that just checks framebuffer constraints. v3: rebase over PAGE_FLIP_TARGET. Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> [seanpaul] This patch as posted on the list was rebased on: commit 6f00975c619064a18c23fd3aced325ae165a73b9 Author: Daniel Vetter <[email protected]> Date: Sat Aug 20 12:22:11 2016 +0200 drm: Reject page_flip for !DRIVER_MODESET so as a result of moving the page_flip ioctl, this fix has been rolled into this patch. Signed-off-by: Sean Paul <[email protected]>
2016-08-16drm/doc: Update drm_framebuffer docsDaniel Vetter1-0/+35
- Move the intro section into a DOC comment, and update it slightly. - kernel-doc for struct drm_framebuffer! v2: - Copypaste fail (Sean). - Explain the linear @offsets clearer (Ville). Cc: Sean Paul <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-08-16drm: Extract drm_framebuffer.[hc]Daniel Vetter1-0/+796
Also start with drm_modeset.h with the core bits, since we need to untangle this mess somehow. That allows us to move the drm_modes.h include to the right spot, except for the temporary connector status enum. That will get fixed as soon as drm_connector.h exists. v2: Rebase. v3: Move drm_crtc_force_disable_all back again, that wasn't meant to be moved (Sean). v4: Rebase. Cc: Sean Paul <[email protected]> Reviewed-by: Sean Paul <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.