aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/omapdrm
AgeCommit message (Collapse)AuthorFilesLines
2016-12-19drm: omapdrm: Use sizeof(*var) instead of sizeof(type) for structuresLaurent Pinchart5-8/+7
By linking the sizeof to a variable type the code will be less prone to bugs due to future type changes of variables. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Remove global variablesLaurent Pinchart2-21/+24
Move the list of pending IRQ wait instances to the omap_drm_private structure and the wait queue head to the IRQ wait structure. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Simplify IRQ wait implementationLaurent Pinchart2-74/+37
Now that the IRQ list is used for IRQ wait only we can merge omap_drm_irq and omap_irq_wait and simplify the implementation. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Inline the pipe2vbl functionLaurent Pinchart3-11/+3
The function is only used in omap_irq.c and is just a wrapper around dispc_mgr_get_vsync_irq(). Remove it and call the dispc function directly. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Don't call DISPC power handling in IRQ wait functionsLaurent Pinchart1-4/+0
The IRQ wait functions are called from the DSS enable and disable operations only, where the DISPC is guaranteed to be enabled. There's no need for manual DISPC power management there. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Remove unused parameter from omap_drm_irq handlerLaurent Pinchart2-3/+3
The only omap_drm_irq handler doesn't use the irqstatus parameter passed to the function. Remove it. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Don't expose the omap_irq_(un)register() functionsLaurent Pinchart2-22/+5
The IRQ registration functions are not used outside of their compilation unit, make them static. As the __omap_irq_(un)register() functions are only called by their omap_irq_(un)register() counterparts, merge them together. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Keep vblank interrupt enabled while CRTC is activeLaurent Pinchart3-47/+37
Instead of going through a complicated private IRQ registration mechanism, handle the vblank interrupt activation with the standard drm_crtc_vblank_get() and drm_crtc_vblank_put() mechanism. This will let the DRM core keep the vblank interrupt enabled as long as needed to update the frame counter. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Use a spinlock to protect the CRTC pending flagLaurent Pinchart1-11/+22
The CRTC pending flag will need to be accessed atomically in the vblank interrupt handler, memory barriers won't be enough to protect it. Use a spinlock instead. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Prevent processing the same event multiple timesLaurent Pinchart1-8/+15
The vblank interrupt is disabled after one occurrence, preventing the atomic update event from being processed twice. However, this also prevents the software frame counter from being updated correctly that would require vblank interrupts to be kept enabled while the CRTC is active. In preparation for vblank interrupt fixes, make sure that the atomic update event will be processed once only when the vblank interrupt will be kept enabled. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Check the CRTC software state at enable/disable timeLaurent Pinchart3-18/+16
The omapdrm DSS manager enable/disable operations check the DSS manager state to avoid double enabling/disabling. Check the CRTC software state instead to decrease the dependency of the DRM layer to the DSS layer. The dispc_mgr_is_enabled() function then be turned into a static function, but needs to be moved up in its compilation unit to avoid a forward declaration. Add a WARN_ON to catch double enable or disable that should be prevented by the DRM core and would be a clear sign of a bug. The warning should eventually be removed. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Let the DRM core skip plane commit on inactive CRTCsLaurent Pinchart2-2/+9
The DRM core supports skipping plane update for inactive CRTCs for hardware that don't need it or can't cope with it. That's our case, and the driver already skips flushing planes on inactice CRTCs. We can't remove the check from the driver, as active CRTCs are disabled at the hardware level when an atomic flush is performed if a mode set is pending. There's however no need to forward the plane commit calls to the driver, so use the DRM core infrastructure to skip them with a detailed comment to explain why the check must still be kept in the driver. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Replace DSS manager state check with omapdrm CRTC stateLaurent Pinchart1-9/+13
Instead of conditioning planes update based on the DSS manager hardware state, use the enabled field newly added to the omap_crtc structure. This reduces the dependency from the DRM layer to the DSS layer. The enabled field is a transitory measure, the implementation should use the CRTC atomic state instead. However, given that CRTCs are currently not enabled/disabled through their .enable() and .disable() operations but through a convoluted code paths starting at the associated encoder operations, there is not clear guarantee that the atomic state always matches the hardware state. This will be refactored later, at which point the enabled field will be removed. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Handle OCP error IRQ directlyLaurent Pinchart2-19/+10
Instead of going through a complicated registration mechanism, just call the OCP error IRQ handler directly from the main IRQ handler. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Handle CRTC error IRQs directlyLaurent Pinchart3-10/+11
Instead of going through a complicated registration mechanism, just expose the CRTC error IRQ function and call it directly from the main IRQ handler. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: Handle FIFO underflow IRQs internallyLaurent Pinchart4-30/+67
As the FIFO underflow IRQ handler just prints an error message to the kernel log, simplify the code by not registering one IRQ handler per plane but print the messages directly from the main IRQ handler. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: fb: Turn framebuffer creation error messages into debugLaurent Pinchart1-5/+5
Don't print userspace parameters validation failures as error messages to avoid giving userspace the ability to flood the kernel log. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: fb: Simplify mode command checks when creating framebufferLaurent Pinchart1-27/+23
The hardware requires all planes to have an identical pitch in number of pixels. Given that all supported formats use the same number of bytes per pixel in all planes, framebuffer creation checks can be simplified. The implementations assumes that no format use more than two planes which is true with the existing hardware. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: fb: Simplify objects lookup when creating framebufferLaurent Pinchart2-36/+18
Merge the single-user objects_lookup inline function into its caller, allowing reuse of the error code path. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: fb: Use format information provided by the DRM coreLaurent Pinchart1-45/+46
The driver stores in a custom structure named format several pieces of information about the format that are available in the DRM core. Remove them and get the information from the DRM core instead. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-19drm: omapdrm: fb: Limit number of planes per framebuffer to twoLaurent Pinchart1-2/+2
The only multi-planar format supported by the driver is NV12, there will thus never be more than two planes per framebuffer. Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]>
2016-12-15drm: Nuke fb->pixel_formatVille Syrjälä1-1/+1
Replace uses of fb->pixel_format with fb->format->format. Less duplicated information is a good thing. Note that coccinelle failed to eliminate the "/* fourcc format */" comment from drm_framebuffer.h, so I had to do that part manually. @@ struct drm_framebuffer *FB; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - FB->pixel_format = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ i9xx_get_initial_plane_config(...) { ... - FB->pixel_format = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ ironlake_get_initial_plane_config(...) { ... - FB->pixel_format = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ skylake_get_initial_plane_config(...) { ... - FB->pixel_format = E; ... } @@ struct drm_framebuffer *a; struct drm_framebuffer b; @@ ( - a->pixel_format + a->format->format | - b.pixel_format + b.format->format ) @@ struct drm_plane_state *a; struct drm_plane_state b; @@ ( - a->fb->pixel_format + a->fb->format->format | - b.fb->pixel_format + b.fb->format->format ) @@ struct drm_crtc *CRTC; @@ ( - CRTC->primary->fb->pixel_format + CRTC->primary->fb->format->format | - CRTC->primary->state->fb->pixel_format + CRTC->primary->state->fb->format->format ) @@ struct drm_mode_set *set; @@ ( - set->fb->pixel_format + set->fb->format->format | - set->crtc->primary->fb->pixel_format + set->crtc->primary->fb->format->format ) @@ @@ struct drm_framebuffer { ... - uint32_t pixel_format; ... }; v2: Fix commit message (Laurent) Rebase due to earlier removal of many fb->pixel_format uses, including the 'fb->format = drm_format_info(fb->format->format);' snafu v3: Adjusted the semantic patch a bit and regenerated due to code changes Cc: Laurent Pinchart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Alex Deucher <[email protected]> (v1) Reviewed-by: Laurent Pinchart <[email protected]> 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: Replace drm_format_num_planes() with fb->format->num_planesVille Syrjälä1-4/+4
Replace drm_format_num_planes(fb->pixel_format) with just fb->format->num_planes. Avoids the expensive format info lookup. @@ struct drm_framebuffer *a; struct drm_framebuffer b; @@ ( - drm_format_num_planes(a->pixel_format) + a->format->num_planes | - drm_format_num_planes(b.pixel_format) + b.format->num_planes ) @@ struct drm_plane_state *a; struct drm_plane_state b; @@ ( - drm_format_num_planes(a->fb->pixel_format) + a->fb->format->num_planes | - drm_format_num_planes(b.fb->pixel_format) + b.fb->format->num_planes ) @@ struct drm_framebuffer *a; identifier T; @@ T = a->pixel_format <+... - drm_format_num_planes(T) + a->format->num_planes ...+> @@ struct drm_framebuffer b; identifier T; @@ T = b.pixel_format <+... - drm_format_num_planes(T) + b.format->num_planes ...+> v2: Rerun spatch due to code changes Cc: Laurent Pinchart <[email protected]> Suggested-by: Laurent Pinchart <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-15drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()Ville Syrjälä1-1/+1
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can populate fb->dev early. Will make it easier to use the fb before we register it. @@ identifier fb, mode_cmd; @@ void drm_helper_mode_fill_fb_struct( + struct drm_device *dev, struct drm_framebuffer *fb, const struct drm_mode_fb_cmd2 *mode_cmd ); @@ identifier fb, mode_cmd; @@ void drm_helper_mode_fill_fb_struct( + struct drm_device *dev, struct drm_framebuffer *fb, const struct drm_mode_fb_cmd2 *mode_cmd ) { ... } @@ function func; identifier dev; expression E1, E2; @@ func(struct drm_device *dev, ...) { ... drm_helper_mode_fill_fb_struct( + dev, E1, E2); ... } @@ expression E1, E2; @@ drm_helper_mode_fill_fb_struct( + dev, E1, E2); v2: 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]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-12-14mm: use vmf->address instead of of vmf->virtual_addressJan Kara1-12/+8
Every single user of vmf->virtual_address typed that entry to unsigned long before doing anything with it so the type of virtual_address does not really provide us any additional safety. Just use masked vmf->address which already has the appropriate type. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jan Kara <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Cc: Dan Williams <[email protected]> Cc: Ross Zwisler <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2016-12-08drm/omap: tpd12s015: fix error handlingTomi Valkeinen1-4/+9
tpd12s015 driver is missing error value handling for gpio initialization, causing 0 to be returned as an error if gpiod_get_* fails. This may cause deferred probing to fail. Signed-off-by: Tomi Valkeinen <[email protected]>
2016-12-08drm/omap: fix primary-plane's possible_crtcsTomi Valkeinen3-9/+17
We set the possible_crtc for all planes to "(1 << priv->num_crtcs) - 1", which is fine as the HW planes can be used fro all crtcs. However, when we're doing that, we are still incrementing 'num_crtcs', and we'll end up with bad possible_crtcs, preventing the use of the primary planes. This patch passes a possible_crtcs mask to plane init function so that we get correct possible_crtc. Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-14drm/omapdrm: use DRM_FB_HELPER_DEFAULT_OPS for fb_opsStefan Christ1-4/+1
Cc: Tomi Valkeinen <[email protected]> Signed-off-by: Stefan Christ <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-11-02drm/omap: panel-lgphilips-lb035q02: Add note for incorrect data drive edge ↵Peter Ujfalusi1-0/+5
and DE level According to the datasheet of the panel, both data, DEN and sync signals are expected to be driven on the falling edge of the DOTCLK. The DE is active low according to the documentation. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: panel-sharp-ls037v7dw01: Add note for incorrect data drive edgePeter Ujfalusi1-0/+4
According to the datasheet of the panel, both data, DEN and sync signals are expected to be driven on the falling edge of the DOTCLK. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: panel-tpo-td028ttec1: Add note for incorrect sync drive edgePeter Ujfalusi1-0/+4
According to the datasheet of the panel, both data, DEN and sync signals are expected to be driven on the falling edge of the DOTCLK. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: panel-tpo-td043mtea1: Add note for incorrect sync drive edgePeter Ujfalusi1-0/+4
According to the datasheet of the panel, both data, DEN and sync signals are expected to be driven on the falling edge of the DOTCLK. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: Use consistent name for struct videomodePeter Ujfalusi33-535/+527
Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or something else. The code will be easier to follow if we use consistent names. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: Replace struct omap_video_timings with videomodePeter Ujfalusi34-317/+178
omap_video_timings can be replaced with the generic videomode in omapdrm and the omap_video_timings can be removed. This patch will replace the omap_video_timings with videomode. With the change we no longer need the functions to convert to/from videomode and drm_display_mode to omap_video_timings, these can be removed as well. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: Change the types of struct omap_video_timings membersPeter Ujfalusi5-14/+15
omap_video_timings struct have the same members as struct videomode, but their types are different. As first step change the types of the omap_video_timings struct members to match their counterpart in struct videomode to catch any type cast related issues. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: Use display_flags for sync edgePeter Ujfalusi16-54/+35
In preparation to move the stack to use the generic videmode struct for display timing information use display_flags for sync edge. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: Use display_flags for pixel data edgePeter Ujfalusi16-46/+24
In preparation to move the stack to use the generic videmode struct for display timing information use display_flags for pixel data edge. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: Use display_flags for double_pixel modePeter Ujfalusi7-13/+11
In preparation to move the stack to use the generic videmode struct for display timing information use display_flags for double_pixel mode. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: Use display_flags for DE levelPeter Ujfalusi15-44/+29
In preparation to move the stack to use the generic videmode struct for display timing information use display_flags for DE level. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: Use display_flags for h/vsync levelPeter Ujfalusi18-83/+52
In preparation to move the stack to use the generic videmode struct for display timing information use display_flags for h/vsync level. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: dispc: Simplify _dispc_mgr_set_lcd_timings() parametersPeter Ujfalusi1-24/+14
Instead of passing the omap_video_timings structure's members individually, use the pointer to the struct. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: Use display_flags for interlace modePeter Ujfalusi10-22/+21
Remove the interlace member and add display_flags to omap_video_timings to configure the interlace mode. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: HDMI5: Use pointer to cfg->v_fc_config.timings in ↵Peter Ujfalusi1-27/+20
hdmi_core_video_config By using a pointer to the omap_mode_timings struct we can unwrap lines to make the code easier to follow. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: rename vbp to vback_porchPeter Ujfalusi18-32/+33
In preparation to move the stack to use the generic videmode struct for display timing information rename the vbp member to vback_porch. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: rename vfp to vfront_porchPeter Ujfalusi18-32/+33
In preparation to move the stack to use the generic videmode struct for display timing information rename the vfp member to vfront_porch. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: rename vsw to vsync_lenPeter Ujfalusi18-31/+31
In preparation to move the stack to use the generic videmode struct for display timing information rename the vsw member to vsync_len. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: rename hbp to hback_porchPeter Ujfalusi18-36/+38
In preparation to move the stack to use the generic videmode struct for display timing information rename the hbp member to hback_porch. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: rename hfp to hfront_porchPeter Ujfalusi18-45/+47
In preparation to move the stack to use the generic videmode struct for display timing information rename the hfp member to hfront_porch. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
2016-11-02drm/omap: omap_display_timings: rename hsw to hsync_lenPeter Ujfalusi18-52/+53
In preparation to move the stack to use the generic videmode struct for display timing information rename the hsw member to hsync_len. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.