- 03 Mar, 2016 40 commits
-
-
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>
-
Tomi Valkeinen authored
We need double-pixel mode (pixel repetition) for interlace modes. This patch adds the necessary support to HDMI to double the pixel clock when double-pixel mode is used. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
We need double-pixel mode (pixel repetition) for interlace modes. This patch adds the necessary support to omapdrm to output double-pixel mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
We need double-pixel mode (pixel repetition) for interlace modes. This patch adds the necessary support to DISPC to output double-pixel mode. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
omap_crtc_wait_pending() waits until the config changes have been taken into use, usually at next vblank. The wait-timeout used is 50ms, which usually is enough, but in some rare cases not. As time wait-timeout is just a safety measure for cases where something is broken, we can just as well increase the timeout considerably. This patch makes the timeout 250ms. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
We no longer have the omapdrm plugin system for SGX, and we can thus remove the support for external memory and sync objects from omap_gem.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Laurent Pinchart authored
OMAP GEM objects backed by dma_buf reuse the current OMAP GEM object support as much as possible. If the imported buffer is physically contiguous its physical address will be used directly, reusing the OMAP_BO_MEM_DMA_API code paths. Otherwise it will be mapped through the TILER using a pages list created from the scatterlist instead of the shmem backing storage. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
Split the individual steps of GEM object allocation and initialization clearly. This improves readability and prepares for dma_buf import support. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Laurent Pinchart authored
The driver assumes that only objects backed by shmem need to be mapped through DMM. While this is true with the current code, the assumption won't hold with dma_buf import support. Condition the mapping based on whether the buffer has been allocated using the DMA mapping API instead and clean up the flags to avoid having to check both flags and GEM object filp field to decide how to process buffers. Flags are not the authoritative source of information regarding where the buffer memory comes from, and are renamed to make that clearer. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
If the panel's enable fails, omap_encoder silently ignores the failure. omapdrm should really handle the failure, but unfortunately the whole encoder enable codepath is expected to always succeed. So for now, catch the enable failure and print an error. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
omap_gem_dma_sync() calls dma_map_page() but does not check the possible error with dma_mapping_error(). If DMA-API debugging is enabled, the debug layer will give a warning if dma_mapping_error() has not been used. This patch adds proper error handling to omap_gem_dma_sync(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
omap_gem_attach_pages() calls dma_map_page() but does not check the possible error with dma_mapping_error(). If DMA-API debugging is enabled, the debug layer will give a warning if dma_mapping_error() has not been used. This patch adds proper error handling to omap_gem_attach_pages(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
OMAP4+ DSS has WBUNCOMPLETEERROR irq, which was not defined in the irq list. Add the define. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Manisha Agrawal authored
tpd12s015 HW has LS_OE, CT_CP_HPD and HPD gpios. Out of these gpios, driver only handled LS_OE as optional. The CT_CP_HPD gpio should also be treated as optional gpio as it is just a power saving feature. Some boards hardwire this gpio to be always enable. In this patch, all access to CT_CP_HPD gpio is made optional. Signed-off-by: Manisha Agrawal <manisha.agrawal@ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Manisha Agrawal authored
Migrated the gpio APIs to descriptor-interface based. Signed-off-by: Manisha Agrawal <manisha.agrawal@ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Manisha Agrawal authored
All devices using tpd12s015 driver are doing DT boot. No need of further supporting the platform data. This patch removes support for platform data. Signed-off-by: Manisha Agrawal <manisha.agrawal@ti.com> [tomi.valkeinen@ti.com: minor adjustments] Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Jyri Sarha authored
drm_atomic_get_plane_state() may return ERR_PTR. Handle drm_atomic_get_plane_state() return values right in omap_crtc_atomic_set_property(). Signed-off-by: Jyri Sarha <jsarha@ti.com> Acked-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
This patch adds wrapper functions for readl() and writel(), dmm_read() and dmm_write(), so that we can implement workaround for DRA7 errata i878. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
The current driver uses non-blocking DMM fill when releasing memory. This gives us a small performance increase as we don't have to wait for the fill operation to finish. However, the driver does not have any error handling for non-blocking fill. In case of an error, the fill operation may silently fail, leading to leaking DMM engines, which may eventually lead to deadlock if we run out of DMM engines. This patch makes the DMM driver always use blocking fills, so that we can catch the errors. A more complex option would be to allow non-blocking fills, and implement proper error handling, but that is left for the future. This patch is a HACK, as the proper fix is to either decide to always use sync fills and remove all the async related code, or fix the async code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
Tomi Valkeinen authored
We occasionally see DISPC sync-lost errors when enabling and disabling HDMI. Sometimes we get only a few, which get handled (ignored) by the driver, but sometimes there's a flood of the errors which doesn't seem to stop. The HW team has root caused this to the order in which HDMI and DISPC are enabled/disabled. Currently we enable HDMI first, and then DISPC, and vice versa when disabling. HW team's suggestion is to do it the other way around. This patch changes the order, but this has two side effects as the pixel clock is produced by HDMI, and the clock is not running when we enable/disable DISPC: * When enabling DISPC first, we don't get vertical sync events * When disabling DISPC last, we don't get FRAMEDONE event At the moment we use both of those to verify that DISPC has been enabled/disabled properly. Thus this patch also needs to change the omapdrm and omapdss which handle the DISPC side. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-