The names of the enum dss_clk_source's values are legacy names, only
correct for OMAP3 DSS. Rename the names to more generic ones.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that there is no "non-generic" version of the function to get the
clock source name, lets rename dss_get_generic_clk_source_name() to
dss_get_clk_source_name().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We have two functions to return a name for clock sources for debugging
purposes: dss_feat_get_clk_source_name() and
dss_get_generic_clk_source_name().

The former is supposed to return a DSS IP version specific name for the
clock source, and the latter is supposed to return a more generic name.

All this seems a bit pointless, so let's remove the former one.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

'enum omap_dss_clk_source' is internal to dss. Let's rename it to
'dss_clk_source' match our naming convention.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dispc_ovl_check() is not used anywhere, so it can be removed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We have removed all the uses of compat code from omapdrm and the
non-compat parts of omapdss, so now we can remove all the compat code
itself.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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>

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>

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>

Now that omapfb has its own copy of omapdss and display drivers, we can
move omapdss and display drivers which omapdrm uses to omapdrm's
directory.

We also need to change the main drm Makefile so that omapdrm directory
is always entered, because omapdss has a file that can't be built as a
module.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Acked-by: NRob Clark <robdclark@gmail.com>

Boolean tests do not need explicit comparison to true or false.
Signed-off-by: NLuis de Bethencourt <luisbg@osg.samsung.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

A bunch of dispc functions are only used inside dispc, so we can make
them static.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The functions dispc_ovl_set_fifo_threshold and
dispc_ovl_compute_fifo_thresholds are exported, but not declared in
public headers, and thus are not used outside omapdss. So we can remove
the EXPORT_SYMBOL()s.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

dispc_wb_setup() handles configuration only for mem-to-mem case. This
patch adds the necessary configuration to handle also display capture
mode.

We need to set CAPTUREMODE to 0 (continuous capture), and WBDELAYCOUNT
according to the vertical timings of the display, so that the WB FIFO
has time to flush before the next frame starts.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In mem-to-mem mode WB CAPTUREMODE needs to be set to 1 (capture one
frame).
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The color conversion coefficients for RGB to YUV conversion (used with
writeback) don't result in the correct result. This patch sets the
correct coefficients.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When doing mem-to-mem writeback, there's no pixelclock. However, the
code that calculates scaling factors check that there is a pixel clock.
We can just skip the check when doing mem-to-mem writeback.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Mflag thresholds for all pipelines are set in dispc_init_mflag(), but we
are missing that for WB pipeline. Add WB configuration.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Fifo thresholds for all pipelines are set in dispc_init_fifos(), but we
are missing it for WB pipeline. Add that.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Burst size for all pipelines is set in dispc_configure_burst_sizes(),
but we are missing WB pipe. So add that.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add handling of OMAP_DSS_CHANNEL_WB to dispc_ovl_set_channel_out() and
dispc_ovl_get_channel_out().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Refactor dispc_ovl_get_channel_out() to a bit cleaner form, which makes
it easier to add support for writeback in the following patch.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

At the moment we have a function to get the number of writeback
pipelines supported. However, the function is used in a wrong way,
causing a wrong pipeline to get configured when trying to use WB. Also,
we only have a single writeback pipeline on any of the DSS versions.

To fix and simplify this, create a 'has_writeback' flag into the dispc
driver, and after checking the flag, use OMAP_DSS_WB pipeline
explicitly when calling the configuration functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add dumping of the writeback registers to the register dump function.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

By default DISPC asserts hsync and vsync sequentially, i.e. there's
first hsync and that is immediately followed by vsync. This is the only
available behaviour on OMAP2/3, and default behaviour on OMAP4+.

OMAP4+ has ALIGN bit in POL_FREQ register, which makes DISPC assert both
syncs at the same time.

It has been observed that some panels don't like sequential syncs (AM5
EVM's panel). After studying the datasheets for multiple panels and
encoders, and MIPI DPI spec, it looks like there is no standard way to
handle this.

Sometimes the datasheets don't mention the required syncs behaviour at
all, sometimes the datasheets have images that hint towards simultaneous
syncs, and sometimes it is explicitly mentioned that simultaneous syncs
are needed. No panels or encoders requiring sequential sync was found.

It thus seems to be safe to default to simultaneous syncs when the ALIGN
bit is available. This fixed AM5 EVM's panel, and no side effects have
been observed on other panels or encoders.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Improve the DISPC debug print for scaling.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The current driver does both x and y decimation on OMAP3 DSS. Testing
shows that x decimation rarely works, leading to underflows.

The exact reason for this is unclear, as the underflows seem to happen
even with low pixel clock rates, and I would presume that if the DSS can
manage a display with 140MHz pixel clock, it could manage x decimation
with factor 2 with a low pixel clock (~30MHz).

So it is possible that there is a problem somewhere else, in memory
management, or DSS DMA, or similar. I have not found anything that would
help this.

So, to fix the downscaling scaling, this patch removes x decimation for
OMAP3. This will limit some of the more demanding downscaling scenarios,
but one could argue that using DSS to downscale such a large amount is
insane in the first place, as the produced image is rather bad quality.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DISPC's scaling code seems to presume that decimation always
succeeds, and so we always do find a suitable downscaling setup.
However, this is not the case, and the algorithm can fail.

When that happens, the code just proceeds with wrong results, causing
issues later.

Add the necessary checks to bail out if the scaling algorithm failed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DISPC driver uses 64 bit arithmetic to calculate the required clock
rate for scaling. The code does not seem to work correctly, and instead
calculates with 32 bit numbers, giving wrong result.

Fix the code by typecasting values to u64 first, so that the
calculations do happen in 64 bits.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

pixel_inc and row_inc work differently on OMAP2/3 and OMAP4+ DSS. On
OMAP2/3 DSS, the pixel_inc is _not_ added by the HW at the end of the
line, after the last pixel, whereas on OMAP4+ it is.

The driver currently works for OMAP4+, but does not handle OMAP2/3
correctly, which leads to tilted image when row_inc is used.

This patch adds a flag to DISPC driver so that the pixel_inc is added
when required.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

On OMAP3/AM43xx some scaling factors cause underflows/synclosts. After
studying this, I found that sometimes the driver uses three-tap scaling
with downscaling factor smaller than x0.5. This causes issues, as x0.5
is the limit for three-tap scaling.

The driver has FEAT_PARAM_DOWNSCALE parameter, but that seems to be for
five-tap scaling, which allows scaling down to x0.25.

This patch adds checks for both horizontal and vertical scaling. For
horizontal the HW always uses 5 taps, so the limit is x0.25.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

After calculating the required decimation for scaling, the dispc driver
checks once more if the resulting configuration is valid by calling
check_horiz_timing_omap3().

Earlier calls to this function have correctly used in_width and
in_height as parameters, but the last call uses width and height. This
causes the driver to possibly reject scaling that would work.

This patch fixes the parameters.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DISPC needs even input buffer width for YUV modes. The DISPC driver
doesn't check this at the moment (although omapdrm does), but worse,
when DISPC driver does x predecimation the result may be uneven. This
causes sometimes sync losts, underflows, or just visual errors.

This patch makes DISPC driver return an error if the user gives uneven
input width for a YUV buffer. It also makes the input width even in case
of predecimation.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Errata i631 description:

"When in YUV4:2:0 format in 1D burst, the DISPC DMA skips lines when
fetching Chroma sampling."

Workaround:

"If YUV4:2:0-1D burst is required: Set
DISPC_VIDp_ATTRIBUTES[22]DOUBLESTRIDE to 0x0 and
DISPC_VIDp_ATTRIBUTES[13:12]ROTATION to 0x1 or 0x3"

The description is somewhat confusing, but testing has shown that DSS
fetches extra rows from memory when using NV12 format in 1D mode. If the
memory after the framebuffer is inaccessible, this leads to OCP errors.

The driver always uses DOUBLESTRIDE=0 when using 1D mode, so we only
need to handle the ROTATION part.

The issue exist on all OMAP4 and OMAP5 based DSS IPs.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdss kernel module contains drivers for multiple devices, one for
each DSS submodule. The probing we have at the moment is a mess, and
doesn't give us proper deferred probing nor ensure that all the devices
are probed before omapfb/omapdrm start using omapdss.

This patch solves the mess by using the component system for DSS
submodules.

The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
venc) are the same: probe & remove functions are changed to bind &
unbind, and new probe & remove functions are added which call
component_add/del.

The dss_core driver (dss.c) acts as a component master. Adding and
matching the components is simple: all dss device's child devices are
added as components.

However, we do have some dependencies between the drivers. The order in
which they should be probed is reflected by the list in core.c
(dss_output_drv_reg_funcs). The drivers are registered in that order,
which causes the components to be added in that order, which makes the
components to be bound in that order. This feels a bit fragile, and we
probably should improve the code to manage binds in random order.
However, for now, this works fine.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The following patches will add component handling to omapdss, improving
the handling of deferred probing. However, at the moment we're using
quite a lot of __inits and __exits in the driver, which prevent normal
dynamic probing and removal.

This patch removes most of the uses of __init and __exit, so that we can
register drivers after module init, and so that we can unregister
drivers even if the module is built-in.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

It was found that having two displays enabled and having an NV12 overlay
on one of the displays will cause underflows/synclosts. Debugging this
pointed to some issue with MFLAG.

It is unclear why this issue is happening, but it looks like there is a
HW bug related to MFLAG and FIFO management. Disabling MFLAG makes this
issue go away, but then we lose the benefit of MFLAG. Also forcing MFLAG
always on makes the issue go away.

Also, using certain values for MFLAG_START, MFLAG thresholds and PRELOAD
makes the issue go away, but there was no obvious logic to which values
work and which don't.

As a workaround until more information about this is found, force MFLAG
always on to make NV12 usable.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

OMAP5 has support for MFLAG feature, which allows DSS to dynamically
increase the priority of DISPC's DMA traffic. At the moment we don't
have support for it.

It was noticed that on DRA7 with high bandwidth use cases we see FIFO
underflows. Implementing MFLAG support removed those underflows.
Interestingly, on OMAP5 uEVM no such overflows were seen.

This patch adds a simple MFLAG implementation, where we use a fixed
MFLAG threshold value based on the FIFO size. The thresholds are set to
4/8 of fifo size for low threshold, and 5/8 of fifo size for high
threshold.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

At the moment we don't setup FIFO thresholds by default in omapdss. It's
supposed to be done by the user of omapdss. And that is missing from
omapdrm, causing unoptimal thresholds to be used when using omapdrm.

While I believe it's in theory better to allow the user of omapdss to
setup the fifo thresholds, in practice we always use the same values,
and we could as well setup the thresholds in omapdss.

Furthermore, in omapdss init we always swap the FIFO used for GFX and WB
overlays, but we don't swap the FIFO thresholds for those overlays
(which is the reason for omapdrm using unoptimal HW reset values). So
it would make sense to setup the thresholds to account for the swapping
of the FIFOs.

So, this patch adds code to setup default FIFO tresholds at omapdss
init.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Dispc driver presumes that the callers handle locking for all normal
functions. However, omapdrm doesn't handle this, and presumes that all
overlay manager registers are private to that overlay manager, and thus
presumes that configurations for overlay managers can be written via
different threads freely.

For many registers the above is true. The exceptions are DISPC_CONTROL
and DISPC_CONFIG registers, which contain bits for both LCD and TV
overlay managers.

Fixing this properly in omapdrm means a big omapdrm rewrite. So, for
now, add locking to dispc for the problematic registers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NSomnath Mukherjee <somnath@ti.com>