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>

We should wait for any pending updates when an overlay manager is
about to be disabled, because the updates will never be finished if the
manager is disabled too early.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.

Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.

No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NRob Clark <robdclark@gmail.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When omapfb does ovl->get_overlay_info, ovl->set_overlay_info, the set
function may fail even if the info has not been changed. This is because
omapdss doesn't initialize the info, but expect the caller to set valid
values.

Normally that is the case, but there is at least one corner case: if
omapfb has not allocated memory for the overlay yet, and the user uses
ioctl to disable the overlay to make sure it's disabled. In this case
get_overlay_info returns invalid data, but the user is only interested
in setting the overlay to disabled, not configuring it, and
set_overlay_info fails.

The issue is made possible by the omapfb's setup_plane ioctl, which
groups overlay configuration and overlay enable/disable bit into the
same struct. Thus, when you are disabling an overlay, you are also
configuring it.

This is a bit counter intuitive, so I think it's better to initialize
the info to some valid values.

The fields requiring initialization are color_mode and rotation_type,
and also we need to remove the check for (paddr == 0), as paddr is 0 for
unallocated overlay (but it's still fine to disable the overlay).
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Fix debug prints all over omapdss:
* add missing linefeeds
* change pr_err/pr_debug to DSSERR/DSSDBG
* add missing DSS_SUBSYS_NAMEs
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In the old panel device model we had omap_dss_output entities,
representing the encoders in the DSS block. This entity had "device"
field, which pointed to the panel that was using the omap_dss_output.

With the new panel device model, the omap_dss_output is integrated into
omap_dss_device, which now represents a "display entity". Thus the "device"
field, now in omap_dss_device, points to the next entity in the display
entity-chain.

This patch renames the "device" field to "dst", which much better tells
what the field points to.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

In the future will have arbitrarily long video pipeline chains, instead
of the current two-entities-per-pipeline model.

This patch changes the affected get/find style functions so that they
properly go through the video pipeline chain, for example when getting
the overlay manager connected to a given display.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have omap_dss_device, which represents an external display
device, sometimes an external encoder, sometimes a panel. Then we have
omap_dss_output, which represents DSS's output encoder.

In the future with new display device model, we construct a video
pipeline from the display blocks. To accomplish this, all the blocks
need to be presented by the same entity.

Thus, this patch combines omap_dss_output into omap_dss_device. Some of
the fields in omap_dss_output are already found in omap_dss_device, but
some are not. This means we'll have DSS output specific fields in
omap_dss_device, which is not very nice. However, it is easier to just
keep those output specific fields there for now, and after transition to
new display device model is made, they can be cleaned up easier than
could be done now.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We aim to remove the custom omapdss bus totally, as it's quite a strange
construct and won't be compatible with common display framework. One
problem on the road is that we have sysfs files for each display, and
they depend on the omapdss bus.

This patch creates the display sysfs files independent of the omapdss
bus. This gives us backwards compatibility without using the omapdss bus
for the sysfs files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.

This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.

To support that kind of scenarios, we need to add new step to the
initialization: connect.

This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.

One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.

This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Currently omapdrm creates crtcs, which map directly to DSS overlay
managers, only on demand at init time. This would make it difficult to
manage connecting the display entities in the future, as the code cannot
just search for a suitable overlay manager.

We cannot fix this the sane way, which would be to create crtcs for each
overlay manager, because we need an overlay for each crtc. With limited
number of overlays, that's not possible.

So the solution for now is to detach the overlay manager from the crtc.
crtcs are still created on demand at init time, but all overlay managers
are always initialized by the omapdss.

This way we can create and connect whole display pipelines from the
overlay manager to the display, regardless of which crtcs omapdrm would
create.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Split the function that creates overlay manager structs into two: one
that creates just the structs, and one that creates the sysfs files for
the manager.

This will help us use the overlay manager structs with omapdrm in the
following patches, while still leaving the sysfs files out.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Minor cleanup for the dss_[ovl|mgr]_get_device() functions to make them
more readable.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dss_mgr_wait_for_vsync() uses dssdev->type to find out if the output is
going to VENC, HDMI, or something else. This creates a dependency on
dssdev, which we want to remove. The task is more logically done by
looking at the output to which the overlay manager in question is
connected to.

This patch changes the code to use output->id to find out which kind of
output we use.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

Move creation of the sysfs files for displays to the compat layer.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The whole dispc irq handling system we currently have is only needed for
compat layer, and thus can be moved from dispc.c to the compat layer.

This is quite straigtforward, but we need to add new dispc functions to
request and free the actual hardware irq: dispc_request_irq() and
dispc_free_irq().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dispc_mgr_enable_sync and dispc_mgr_disable_sync are only used with the
compat mode. Non-compat will use the simpler enable and disable
functions.

This patch moves the synchronous enable/disable code to the compat
layer. A new file is created, dispc-compat.c, which contains low level
dispc compat code (versus apply.c, which contains slightly higher level
compat code).
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Some of the output drivers need to handle FRAMEDONE interrupt from
DISPC. This creates a direct dependency to dispc code, and we need to
avoid this to make the compat code to work.

Instead of the output drivers registering for dispc interrupts, we
create new mgr-ops that are used to register a framedone handler. The
code implementing the mgr-ops is responsible for calling the handler
when DISPC FRAMEDONE interrupt happens. The compat layer is improved
accordingly to do the call to the framedone handler.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The output drivers need some operations from the overlay managers, like
enable and set_timings. These will affect the dispc registers, and need
to be synchronized with the composition-side changes with overlays and
overlay managers.

We want to handle these calls in the apply.c in the compatibility mode,
but when in non-compat mode, the calls need to be handled by some other
component (e.g. omapdrm).

To make this possible, this patch creates a set of function pointers in
a dss_mgr_ops struct, that is used to redirect the calls into the
correct destination.

The non-compat users can install their mgr ops with
dss_install_mgr_ops() function.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Most of the functions that are assigned to the fields in ovl struct are
in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Most of the functions that are assigned to the fields in ovl-mgr struct
are in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Overlay and overlay_manager structs will only be needed in the compat
mode.

This patch moves initialization of overlay and overlay_manager structs
to apply.c, so that they are handled in omapdss_compat_init().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add two new exported functions, omapdss_compat_init and
omapdss_compat_uninit, which are to be used by omapfb, omap_vout to
enable compatibility mode for omapdss. The functions are called by
omapdss internally for now, and moved to other drivers later.

The compatibility mode is implemented fully in the following patches.
For now, enabling compat mode only sets up the private data in apply.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When doing a manual update in dss_mgr_start_update, we clear the shadow dirty
flags. Although there isn't any harm in clearing them. The need to clear them
out here should never arrive.

When applying configurations for a manual update manager, we never do any
register writes, i.e, calls to dss_mgr_write_regs and dss_mgr_write_regs_extra
never happen while applying. We do all these writes only when we call
dss_mgr_start_update. Hence, there is never a time when the shadow registers
are dirty.

Remove the call to mg_clear_shadow_dirty.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The bool was_updating is never really used for anything. It is set to the
current value of mp->updating, but not used anywhere. Remove this variable.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

An overlay's channel out field isn't a shadow register. The TRM says that it's
taken into effect immediately. This understanding was missing and channel out
was treated as a shadow parameter, and in overlay's private data as extra info.

Program channel out bits directly in dss_ovl_set_manager(). In order to do this
safely, we need to be totally sure that the overlay is disabled in hardware. For
auto update managers, we can assume that the overlay was truly disabled at
dss_ovl_unset_manager() through the wait_pending_extra_info_updates() call.
However, when unsetting manager for an overlay that was previously connected to
a manager in manual update, we can't be sure if the overlay is truly disabled.
That is, op->enabled might not reflect the actual state of the overlay in
hardware. The older manager may require a manual update transfer to truly
disable the overlay. We expect the user of OMAPDSS to take care of this, in
OMAPDSS, we make sure that an overlay's manager isn't unset if there if
extra_info is still dirty for that overlay.

The wrong understanding of channel out bits also explains the reason why we see
sync lost when changing an overlay's manager which was previously connected to a
manual update manager. The following sequence of events caused this:

- When we disable the overlay, no register writes are actually done since the
  manager is manual update, op->enabled is set to false, and the
  extra_info_dirty flag is set. However, in hardware, the overlay is still
  enabled in both shadow and working registers.

- When we unset the manager, the software just configures the overlay's manager
  to point to NULL.

- When we set the overlay to a new manager(which is in auto update) through
  dss_ovl_set_manager, the check  for op->enabled passes, the channel field in
  extra info is set to the new manager. When we do an apply on this manager,
  the new channel out field is set in the hardware immediately, and since the
  overlay enable bit is still set in hardware, the new manager sees that the
  overlay is enabled, and tries to retrieve pixels from it, this leads to sync
  lost as it might be in the middle of processing a frame when we set the
  channel out bit.

The solution to this was to ensure that user space does another update after
disabling the overlay, this actually worked because the overlay was now truly
disabled, and an immediate write to channel out didn't impact since the manager
saw the new overlay as disabled, and doesn't try to retrieve pixels from it.

Remove channel as an extra_info field. Make dss_ovl_unset_manager more strict
about the overlay being disabled when detaching the manager. For overlays
connected to a manual update manager, unset_manager fails if we need another
update to disable the overlay.

We still need to a manual update to ensure the overlay is disabled to get change
the overlay's manager. We could work on doing a dummy update by using DISPC's
capability to gate the different video port signals. This is left for later.

Remove the comment about the sync lost issue.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The return value of wait_for_completion_timeout() is always
>= 0 with unsigned int type.

So the condition "ret < 0" or "ret >= 0" is pointless.
Signed-off-by: Nliu chuansheng <chuansheng.liu@intel.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The current dispc_mgr_enable/disable function are blocking, and do a bit
too much for omapdrm. We'll expose new enable & disable functions that
will just set the bits in the registers in the following patches.

This patch renames the current functions to *_sync, to make it clear
that they are blocking, and also to free up the dispc_mgr_enable/disable
names for these new functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have a single function to enable and disable the manager
output for LCD and DIGIT. The functions are a bit complex, as handling
both enable and disable require some extra steps to ensure that the
output is enabled or disabled properly without errors before exiting the
function.

The code can be made simpler to understand by splitting the functions
into separate enable and disable functions. We'll also clean up the
comments and some parameter names at the same time.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Dispc has a bunch of functions used to configure output related
parameters:

- dispc_mgr_set_io_pad_mode
- dispc_mgr_enable_stallmode
- dispc_mgr_enable_fifohandcheck
- dispc_mgr_set_clock_div
- dispc_mgr_set_tft_data_lines
- dispc_lcd_enable_signal_polarity
- dispc_mgr_set_lcd_type_tft

These are all called together, and the configuration values are taken
from struct dss_lcd_mgr_config.

Instead of exposing those individual dispc functions, create a new one,
dispc_mgr_set_lcd_config(), which is used to configure the above
parameters from values in struct dss_lcd_mgr_config.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When we enable an output we don't check if we need to register the vsync
isr. This causes us to miss vsync interrupts until somebody changes the
configuration of an overlay or an overlay manager.

Add the registration to dss_mgr_enable to fix the problem.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The printk in DSSDBG function definition is replaced with dynamic debug enabled
pr_debug(). The use of dynamic debugging provides more flexibility as each debug
statement can be enabled or disabled dynamically on basis of source filename,
line number, module name etc., by writing to a control file in debugfs
filesystem. For better understanding please refer to
Documentation/dynamic-debug-howto.txt.

The DSSDBGF() differs from DSSDBG() by providing function name. However,
function name, line number, module name and thread ID can be printed through
dynamic debug by setting appropriate flags 'f','l','m' and 't' in the debugfs
control file. So, DSSDBGF instances are replaced with DSSDBG.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The scalers of overlays and writeback do not have any constraints on downscale
ratio when operating in memory to memory mode.

This is because in memory to memory mode, we aren't connected to a display which
needs data output at the rate of pixel clock. The scalers can perform as much
downscaling as needed, the rate at which the scaler outputs is adjusted
accordingly.

Relax constraints related to downscaling based on whether the input overlays are
connected to writeback in memory to memory mode. We pass a mem_to_mem boolean
parameter to dispc_ovl_setup() from APPLY. This is currently set to false, this
will later be configured to the correct value based on whether the overlay is
connected to writeback or not. Do the same later for writeback when writeback is
configured.

In the scaling calculation code, we calculate the minimum amount of core clock we
need to achieve the required downscaling. If we are in memory to memory mode, we
set this to a very small value(1 in this case), this value would always be
lesser than the actual DISPC core clock value, and hence the scaling checks
would succeed.

We take care that pixel clock isn't calculated for writeback and the overlays
connected to it when in memory to memory mode. A pixel clock in such cases
doesn't make sense.
Signed-off-by: NArchit Taneja <archit@ti.com>

Now that an omap_dss_output can be used to link between managers and devices, we
can remove the old way of setting manager and device links. This involves
removing the device and manager pointers from omap_overlay_manager and
omap_dss_device respectively, and removing the set_device/unset_device ops from
omap_overlay_manager.
Signed-off-by: NArchit Taneja <archit@ti.com>

An overlay isn't allowed to be enabled/disabled if it isn't connected to an
omap_dss_device. This requirement isn't needed any more. An overlay can be
enabled/disabled as long as it has an output connected to it. The output may
not be connected to a device, but we can be assured that the connected
manager's output is in use by an output interface.
Signed-off-by: NArchit Taneja <archit@ti.com>

With the introduction of output entities, managers will now connect to outputs.
Create helper ops for overlays and managers named get_device. This will abstract
away the information on how to get the device from an overlay or an overlay
manager. The get_device ops currently retrieve the output via a
ovl->manager->device reference. This will be later replaced by
ovl->manager->output->device references.
Signed-off-by: NArchit Taneja <archit@ti.com>

Add set_output/unset_output ops for overlay managers, these form links between
managers and outputs. Create a function in dss features which tell all the
output instances that connect to a manager, use it when a manager tries to set
an output. Add a constraint of not unsetting an output when the manager is
enabled.

Keep the omap_dss_device pointer and set/unset_device ops in overlay_manager for
now to not break things. Keep the dss feature function get_supported_displays
as it's used in some places. These will be removed later.
Signed-off-by: NArchit Taneja <archit@ti.com>

The functions dss_mgr_wait_for_go() and dss_mgr_wait_for_go_ovl() check if there
is an enabled display connected to the manager before trying to see the state of
the GO bit.

The checks related to the display can be replaced by checking the state of the
manager, i.e, whether the manager is enabled or not. This makes more sense than
checking with the connected display as the GO bit behaviour is more connected
with the manager state rather than the display state. A GO bit can only be set
if the manager is enabled. If a manager isn't enabled, we can safely assume that
the GO bit is not set.
Signed-off-by: NArchit Taneja <archit@ti.com>

When we removed fifomerge support, we also changed dss_ovl_disable so
that it doesn't wait for the hardware to be finished with the overlay.
This may cause a problem when changing the overlay's manager, as
changing the manager is an immediate change. Thus if the overlay is
still being used by the HW when the manager is changed, there may be
glitches on the screen.

This patch adds a wait into dss_ovl_unset_manager, which ensures the
overlays are disabled in the HW.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This reverts commit fb011974.

Adding fifo merge feature as an omapdss internal configuration was a
mistake. We cannot hide from the users of omapdss the complexities of
fifo merge.

The previous commit removed fifo merge itself, and this removes the
remaining fifo merge support functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>