This patch makes a copy of the omapdss driver and the omap panel &
encoder drivers for omapfb. The purpose is to separate omapdrm and
omapfb drivers from each other.

Note that this patch only does a direct copy of the files without any
other modifications. The files are not yet used.

The original files are in:

drivers/video/fbdev/omap2/dss/
drivers/video/fbdev/omap2/displays-new/

Here's a more detailed explanation about this and the following patches,
from the introduction mail of the patch series:

A short background on the current status. We have the following
entities:

* omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for the
  display subsystem IPs used on OMAP (and related) SoCs. It offers only a
  kernel internal API, and does not implement anything for fbdev or drm.

* omapdss panels and encoders, located in
  drivers/video/fbdev/omap2/displays-new/. These are panel and external encoder
  drivers, which use APIs offered by omapdss driver. These also don't implement
  anything for fbdev or drm.

* omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
  uses omapdss and the panel/encoder drivers to operate the hardware.

* omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
  driver, which uses omapdss and the panel/encoder drivers to operate the
  hardware.

* omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
  which uses omapdss and omapfb to implement a v4l2 API for the video overlays.

So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
those use the same low level drivers. Without going to the historical details
why the architecture is like that, I think it's finally time to change that.

The situation with omapfb+omap_vout is that it still works, but no new features
have been added for a long time, and I want to keep it working as it's still
being used.  At some point in the future I'd like to remove omapfb and
omap_vout altogether.

Omapdrm, on the other hand, is being actively developed. Sharing the low level
parts with omapfb makes that development more difficult than it should be. It
also "hides" half of the development, as everything happening in the low level
parts resides under fbdev directory, not in the drm directory.

I've been wanting to clean this up for a long time, but I haven't figured out a
very good way to do it. I still haven't, but here's the best way I have come up
with.

This series makes a full copy of the low level parts, omapdss and panel/encoder
drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is just
the current files moved. This way git will associate the omapdrm version with
the old files.

The omapfb+omap_vout versions won't be touched unless there are some big issues
there.

The omapdrm versions can be refactored and cleaned up, as the omapfb support
code is no longer needed. We can perhaps also merge omapdss and omapdrm into
the same kernel module.

This series only does the copy, and the absolutely necessary parts. No further
cleanups are done yet.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Acked-by: NRob Clark <robdclark@gmail.com>

Replace the use of nested functions where a normal function will suffice.

Nested functions are not liked by upstream kernel developers in general. Their
use breaks the use of clang as a compiler, and doesn't make the code any
better.

This code now works for both gcc and clang.
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
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>

The code handling 'alpha_blending_enabled' sysfs file contains WARN_ONs
in case the feature is not supported on the current platform. Even
though only root can write to the file, anyone can read it, thus causing
the kernel to get tainted and printing an ugly warning.

Instead of having WARN_ONs, return a proper error if the feature is not
supported.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NRussell King - ARM Linux <linux@arm.linux.org.uk>

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>

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>

Add two helper functions that can be used to find either the DSS output
or the overlay manager that is connected to the given display.

This hides how the output and the manager are actually connected, making
it easier to change the connections in the future.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The display sysfs attribute's store function needs to be changed with the
introduction of outputs.

The DSS driver ensures that there is one display per output, and that a
registered omap_dss_device will have an output connected to it. The display
sysfs store function unsets the current output connected to the manager, and
sets it with the output connected to the new display. If the new display doesn't
have an output for some reason, we just bail out. The function doesn't set/unset
output->device links. These remain the same as when the omap_dss_device was
registered.
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>

Separate sysfs code for managers to a separate file. This is a bit
cleaner, and will allow us later to easily switch off the sysfs support
via Kconfig option.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The LCD related manager configurations are a part of the manager's private data
in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function
to check the validity of some of the configurations.

To check some of the configurations, we require information of interface to
which the manager output is connected. These can be added once interfaces are
represented as an entity.
Signed-off-by: NArchit Taneja <archit@ti.com>

The support for LCD3 manager has been added into the manager module. LCD3 panel
has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and
LCD2 panels. These registers control the Display Controller (DISPC) module for
LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame
Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can
be connected through parallel output interface using DISPC and RFBI or DPI. For
serial interface DSS uses DSI.

The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
register which has been enabled. The clock switch chooses between DSS_CLK and
DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
been added specific to the new manager.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The current implementation of LCD channels and managers consists of a number of
if-else construct which has been replaced by a simpler interface. A constant
structure mgr_desc has been created in Display Controller (DISPC) module. The
mgr_desc contains for each channel its name, irqs and  is initialized one time
with all registers and their corresponding fields to be written to enable
various features of Display Subsystem. This structure is later used by various
functions of DISPC which simplifies the further implementation of LCD channels
and its corresponding managers.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.

Pass the manager's timings in private data to dss_mgr_check(). Remove the need
to pass omap_dss_device structs in the functions which check for the validity
of overlay and manager parameters.
Signed-off-by: NArchit Taneja <archit@ti.com>

Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.

dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the omap_dss_device struct. This would be later
replaced by the timings stored in the manager's private data.

Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
omap_video_timings pointer since these functions just check the timings.
Signed-off-by: NArchit Taneja <archit@ti.com>

If DSS suspends within the functions dss_mgr_wait_for_go(),
dss_mgr_wait_for_go_ovl() or dss_mgr_wait_for_vsync(). It may lose it's clock
and lead to a register access failure.

Request runtime_pm around these functions.

[archit@ti.com: Moved runtime_pm calls to wait_for_go/vsync functions rather
then calling them from omap_dispc_wait_for_irq_interruptible_timeout()]
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The functions dss_ovl_simple_check() and dss_mgr_simple_check() are not
really part of the apply mechanism, and can be moved to overlay.c and
manager.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The functions dss_ovl_check, dss_mgr_check_zorder, dss_mgr_check in
apply.c are not really part of the apply mechanism, and can be moved to
overlay.c and manager.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

struct omap_overlay_manager contains info and info_dirty fields, both of
which should be internal to apply.c.

This patch moves those fields into mgr_priv data, and names them
user_info and user_info_dirty.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DSS currently tries to check that the given overlay and overlay manager
settings are acceptable, but the code does not work quite properly.
Things may change between the check and the actual use of the settings.

Furthermore, the following patches will rewrite how settings are
configured and managed, and trying to keep the (broken) settings
checking working during the rewrite would be very difficult.

This patch removes the checking code, and a working version of checking
will be added back after the settings rewrite has been done.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

apply.c will handle the management of dispc in the future patches. This
patch moves overlay manager related functions to apply.c so that they
will have access to the private data and functions of apply.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Current way of handling overlay-manager links is a bit strange: each
manager has a static array, containing pointers to all the overlays
(even those used by other managers). The overlays contain a pointer to
the manager being used.

This patch makes the system a bit saner: each manager has a linked list
of overlays, and only the overlays linked to that manager are in the
list.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Overlay managers are stored in a linked list. There's no need for this
list, as an array would do just as fine.

This patch changes the code to use an array for overlay managers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_overlay_manager struct contains enable() and disable() functions.
However, these are only meant to be used from inside omapdss, and thus
it's bad to expose the functions.

This patch adds dss_mgr_enable() and dss_mgr_disable() functions to
apply.c, which handle enabling and disabling the output.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Create a new file, apply.c, and move code about handling the
apply-mechanism and configuration of the managers and overlays from
manager.c to apply.c.

Not all related code is moved in this patch, but only the core
apply/configure functions. The later patches move rest of the code from
overlay.c and manager.c, adding necessary locking at the same time.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_dss_mgr_apply currently applies settings to all overlays and
overlay managers. The reason for this was to support cases where
configuration changes affecting multiple managers are made. However, the
current code doesn't support changing such configurations, so the
functionality is not needed.

Change the apply to affect only the manager given as an argument, and
the overlays attached to that manager.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Split omap_dss_mgr_apply() into smaller functions for clarity.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add helper functions ovl_manual_update() and mgr_manual_update() which
return whether the overlay or manager is used with a manual update
display.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Change manager configuration to be similar to overlay configuration by
creating dispc_mgr_setup() which takes omap_overlay_manager_info as
parameter.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Overlay channel is configured with ovl_setup, with all the other overlay
attriutes. This patch separates overlay channel setup so that we can
later configure the channel only when needed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Overlay FIFO thresholds are configured with ovl_setup, with all the
other overlay attributes. This patch separates FIFO threshold setup so
that we can later configure FIFO thresholds only when needed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Move the configuration of interlace and replication from
omap_dss_mgr_apply() to configure_overlay(). This removes the need to
store the values into the cache data.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dss_start_update() takes currently the dss device as a parameter. Change
the parameter to ovl manager, as that is what the dss_start_update()
actually needs. Change the name of the function to
dss_mgr_start_update() to reflect the change.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Partial update for manual update displays has never worked quite well:
* The HW has limitations on the update area, and the x and width need to
  be even.
* Showing a part of a scaled overlay causes artifacts.
* Makes the management of dispc very complex

Considering the above points and the fact that partial update is not
used anywhere, this and the following patches remove the partial update
support. This will greatly simplify the following re-write of the apply
mechanism to get proper locking and additional features like fifo-merge.

This patch removes the partial update from the manager.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Once in a time omapdss had basic support for fifomerge. Fifomerge was
removed as the implementation didn't work properly, and a proper
implementation is a complex problem.

However, some unused fifo-merge related code was left behind. This patch
removes those.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are set,
we switch to an OMAP3 compatibility mode where the zorder values in the pipeline
attribute registers are ignored and a fixed priority is configured.

Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled" for
more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4
alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is
expected to check for the ZORDER cap, if an overlay doesn't have this cap, the
user is expected to set the parameter partial_alpha_enabled. If the overlay has
ZORDER cap, the DSS2 user can assume that alpha blending is already enabled.

Don't support OMAP3 compatibility mode for now. Trying to read/write to
alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not
set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.

Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use
overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports alpha
blending or not. Replace this with checks for VIDEO1 pipeline.

Cc: linux-media@vger.kernel.org
Cc: Lajos Molnar <molnar@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
Acked-by: NVaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dispc_ovl_enable_replication() and dispc_ovl_set_fifo_threshold() are currently
called in configure_overlay(). These are the only functions which cause DISPC
register writes of overlay parameters outside of dispc_ovl_setup().

Move these to dispc_ovl_setup() and pass replication, fifo_low and fifo_high
thresholds as arguments to dispc_ovl_setup() in order to be aligned with other
overlay parameters. No functional changes are made.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dispc_ovl_setup() currently takes a large number of overlay arguments, most of
these are members of the overlay_info struct. Replace these arguments by
passing a overlay_info pointer instead.

In configure_overlay(), we create an overlay_info struct called new_oi, this is
a copy of the overlay cache's overlay_info member. Update the new_oi parameters
which could have been possibly changed in configure_overlay(). Pass its pointer
pointer to dispc_ovl_setup().
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Rename dispc's manager related functions as follows:

- Remove prepending underscores, which were originally used to inform
  that the clocks needs to be enabled. This meaning is no longer valid.
- Prepend the functions with dispc_mgr_*
- Remove "channel" from the name, e.g. dispc_enable_channel ->
  dispc_mgr_enable

The idea is to group manager related functions so that it can be deduced
from the function name that it writes to manager spesific registers.

All dispc_mgr_* functions have enum omap_channel as the first parameter.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Rename dispc's overlay related functions as follows:

- Remove prepending underscores, which were originally used to inform
  that the clocks needs to be enabled. This meaning is no longer valid.
- Prepend the functions with dispc_ovl_*
- Remove "plane" from the name, e.g. dispc_set_plane_ba0 ->
  dispc_ovl_set_ba0

The idea is to group overlay related functions so that it can be deduced
from the function name that it writes to overlay spesific registers.

All dispc_ovl_* functions have enum omap_plane as the first parameter.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>