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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_hdmi_init() function does not exist anymore, so we can remove the
declaration.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

'struct omap_dss_hdmi_data' is not used anywhere, so we can remove it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NRob Clark <robdclark@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Now that interlace support has been added, we can remove the check that
prevents interlace.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The HDMI driver copies the timing values one by one. Instead we can just
copy the whole struct.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Split the individual steps of GEM object allocation and initialization
clearly. This improves readability and prepares for dma_buf import
support.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

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: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>