- 03 Mar, 2016 40 commits
-
-
Tomi Valkeinen authored
We are removing uses of 'struct omap_overlay_manager'. This patch changes dss_mgr_disable() to accept 'enum omap_channel' instead of 'struct omap_overlay_manager'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We are removing uses of 'struct omap_overlay_manager'. This patch changes dss_mgr_enable() to accept 'enum omap_channel' instead of 'struct omap_overlay_manager'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We are removing uses of 'struct omap_overlay_manager'. This patch changes dss_mgr_set_lcd_config() to accept 'enum omap_channel' instead of 'struct omap_overlay_manager'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We are removing uses of 'struct omap_overlay_manager'. This patch changes dss_mgr_set_timings() to accept 'enum omap_channel' instead of 'struct omap_overlay_manager'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We are removing uses of 'struct omap_overlay_manager'. This patch changes dss_mgr_disconnect() to accept 'enum omap_channel' instead of 'struct omap_overlay_manager'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We are removing uses of 'struct omap_overlay_manager'. This patch changes dss_mgr_connect() to accept 'enum omap_channel' instead of 'struct omap_overlay_manager'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Use 'out->dispc_channel_connected' to check if the device is connected to an overlay manager or not, instead of using 'out->manager'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We want to remove the 'struct omap_overlay_manager' from omap_dss_device. At the moment that field is used, among some other uses, to see if the omap_dss_device is connected to an overlay manager. To make it possible to remove the 'struct omap_overlay_manager' field, this patch adds 'bool dispc_channel_connected' field to track the connected-or-not status. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We are removing the use of 'struct omap_overlay_manager' from omapdrm. This patch changes the function pointers in 'dss_mgr_ops' to get 'enum omap_channel' parameter instead of 'struct omap_overlay_manager'. The change is very straightforward, as we still use 'struct omap_overlay_manager' inside the function implementations where needed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
In order to remove uses of 'struct omap_overlay_manager' we need to get rid of using omapdss_find_mgr_from_display() when initializing omapdrm. Instead of using omapdss_find_mgr_from_display() and mgr->id to find the dispc channel used for the given display, we can instead use omapdss_find_output_from_display(), and get the output->dispc_channel from there. We can also remove omapdss_find_mgr_from_display() as it's no longer used. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
In order to remove uses of 'struct omap_overlay_manager' from omapdrm, this patch removes the crtc->mgr field. To accomplish that, a new static array is added along the current 'omap_crtcs' static array, which is used to store the output device connected to a crtc. Optimally we'd use the struct omap_crtc to store this information, but at the time when omap_crtc_dss_connect() is called, we don't yet have the omap_crtc instances. This might possibly be fixed later, but for now the static array does the job. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We are removing the use of the 'struct omap_overlay_manager' from omapdrm, and one part of that is removing the use of mgr->supported_outputs field. This patch adds dispc_mgr_get_supported_outputs() function which can be used instead of mgr->supported_outputs. omap_crtc.c is changed to use the new function. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
This patch continues the work to create private versions of the omapdss.h header for omapdrm and omapfb. This one moves the dss_mgr_* function declarations. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
This patch continues the work to create private versions of the omapdss.h header for omapdrm and omapfb. This one moves 'struct dss_mgr_ops'. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
omapdrm and omapfb still share the same include/video/omapdss.h. We need to change that so that we can proceed with omapdrm work. However, it's not trivial to make separate omapfb and omapdrm versions of omapdss.h, as that file is also included in other places like arch code, audio code and omap_vout code. So we'll do it piece by piece. This patch makes private versions of all the dispc function declarations that are in omapdss.h. For omapdrm we create a new file, drivers/gpu/drm/omapdrm/dss/omapdss.h, which will contain headers meant to be visible outside omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the panel, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the panel, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the panel, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the panel, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the panel, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the connector, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the connector, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the encoder, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
We no longer have any boards that require the platform data support from the panel, so we can remove the related code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
omap_hdmi_init() function does not exist anymore, so we can remove the declaration. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
'struct omap_dss_hdmi_data' is not used anywhere, so we can remove it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
core.c is the only caller of dss_disable_all_devices(). We can thus move the function from display.c to core.c and make it static. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
For legacy reasons omapdss handles system suspend/resume via PM notifier callback, where the driver disables/resumes all the outputs. This doesn't work well with omapdrm. What happens on suspend is that the omapdss disables the displays while omapdrm is still happily continuing its work, possibly waiting for an vsync irq, which will never come if the display output is disabled, leading to timeouts and errors sent to userspace. This patch moves the suspend/resume handling to omapdrm, and the suspend/resume is now done safely inside modeset lock. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
omapdrm is missing a check on the validity of the rotation property. This leads to omapdrm possibly trying to use rotation on non-rotateable framebuffer, which causes the overlay setup to fail. This patch adds the necessary check to omap_plane_atomic_check(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
Before universal planes we had to have plane specific properties for the crtc too, as on the hardware level a crtc uses a plane. In other words, e.g. 'zorder' property was added to both planes and crtcs, and omap_crtc.c would delegate the property set/get to the primary plane. However, the delegation was a bit too generic, delegating all property set/get calls to planes. Thus it's possible to set, say, FB_ID, on a crtc, which gets redirected to the primary plane. This is not standard, and shouldn't be allowed. To keep backward compatibility, we still need to redirect the properties we supported earlier for crtcs, namely 'zorder' and 'rotation'. This patch redirects only the allowed properties from crtcs to planes. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Rob Clark authored
Subsequent threads returning EBUSY from vm_insert_pfn() was not handled correctly. As a result concurrent access from new threads to mmapped data caused SIGBUS. See e79e0fe3 ("drm/i915: EBUSY status handling added to i915_gem_fault()"). Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
The DSS hardware uses the same ROW_INC value for both Y and UV planes for NV12 format. This means that the pitches of the Y and UV planes have to match. omapdrm doesn't check this at the moment, and this can lead into a broken NV12 fb on the screen. This patch adds the check. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
DISPC requires the x resolution to be divisible by 8 when stall mode is not used. Add a check to the DPI driver to verify this. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
Now that interlace support has been added, we can remove the check that prevents interlace. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
Add the missing bits for interlace: * Set VBLANK_OSC if the videomode's vblank is fractional * Halve the vertical timings for interlace * Double the horizontal timings for double-pixel mode * Set FC_PRCONF properly for double-pixel mode Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
The HDMI driver copies the timing values one by one. Instead we can just copy the whole struct. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
For some reason the HDMI FC's HSW value is programmed to hsw-1. There's no indication in the documentation that this would be correct, and no other blanking value needs -1 either. So remove the -1. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
Interlace field order is different between VENC and HDMI. The driver currently sets the field order for VENC. This patch adds the code to set the field order for HDMI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
The HDMI WP timings are not programmed correctly for interlace. We need to halve the vertical timings when interlace is used, and double the horizontal timings when pixel doubling is used. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
On OMAP4 and OMAP5 ES1.0 the HDMI_WP_VIDEO_TIMING_H:HSW field is set directly to the HSW value. On later SoCs the field needs to be programmed with the value of HSW-1. Currently the driver always programs the field with the HSW value. Most videomodes seem to work fine with that, but at least low resolution interlaced modes don't work at all. This patch fixes the HSW for OMAP5 ES2.0+ SoCs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-