The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:

- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
  output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
  yet, we require some muxing at the DSS level, and we also need to configure
  the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
  don't support that yet.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This driver uses omap_dss_device that it gets from a board file through
SPI platfrom_data pointer to pass data from SPI to DSS portion of the
driver by using dev_set_drvdata(). However this trick no longer works,
as DSS core no longer uses omap_dss_device from a board file to create
the real device, so use a global pointer to accomplish this instead,
like other SPI panel drivers do.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

commit 195e672a
   OMAPDSS: DPI: Remove cpu_is_xxxx checks

made the mistake of assuming that cpu_is_omap34xx() is exclusive of
other cpu_is_* predicates whereas it includes cpu_is_omap3630().

So on an omap3630, code that was previously enabled by
  if (cpu_is_omap34xx())
is now disabled as
  dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
fails.

So add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list.

Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

As apollon board doesn't used anymore, remove it.
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
[tony@atomide.com: dropped uncompress.h changes, it's gone]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.

devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
markings need to be removed.

This change removes the use of __devinit, __devexit_p, __devinitdata,
__devinitconst, and __devexit from these drivers.

Based on patches originally written by Bill Pemberton, but redone by me
in order to handle some of the coding style issues better, by hand.

Cc: Bill Pemberton <wfp5p@virginia.edu>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

These devices are not available on other architectures, so
let's limit them to omap.

If the driver subsystem maintainers want to build test
system wide changes without building for each target,
it's easy to carry a test patch that just strips out the
depends entries from Kconfig files.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 0e8276ef (OMAPDSS: DPI: always
use DSI PLL if available) made dpi.c use DSI PLL for its clock. This
works fine, for DPI, but has a nasty side effect on OMAP3:

On OMAP3 the same clock is used for DISPC fclk and LCD output. Thus,
after the above patch, DSI PLL is used for DISPC and LCD output. If
TV-out is used, the TV-out needs DISPC. And if DPI is turned off, the
DSI PLL is also turned off, disabling DISPC.

For this to work, we'd need proper DSS internal clock handling, with
refcounts, which is a non-trivial project.

This patch fixes the issue for now by disabling the use of DSI PLL for
DPI on OMAP3.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This reverts commit b41deecb.

The simpler locking causes huge latencies when two processes use the
omapfb, even if they use different framebuffers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

fb2display() has a for loop which always returns at the first iteration.
Replace the loop with a simple if.

This removes the smatch warning:

drivers/video/omap2/omapfb/omapfb.h:153 fb2display() info: loop could be
replaced with if statement.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapfb_find_best_mode() doesn't check for the return value of kmalloc.
Fix this. This also removes the smatch warning:

drivers/video/omap2/omapfb/omapfb-main.c:2256 omapfb_find_best_mode()
error: potential null dereference 'specs'.  (kzalloc returns null)
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use devm_kzalloc to allocate omapfb2_device. This fixes possible memory
leak:

drivers/video/omap2/omapfb/omapfb-main.c:2553 omapfb_probe() warn:
possible memory leak of 'fbdev'
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The previous patch changes dispc to get the dispc fck rate from dss core
driver. This was the only use of the dispc fck in dispc, and thus we can
now remove the clock handling.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
to get the rate for scaling calculations. This causes a problem with
common clock framework, as omapdss uses the dispc functions inside a
spinlock, and common clock framework uses a mutex in clk_get_rate().

Looking at the DSS clock tree, the above use of the dispc fck is not
quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
a mux to select the clock for DISPC from various options, so the current
use of dispc fck bypasses that. Fortunately we never change the dispc
clock mux for now.

To fix the issue with clk_get_rate(), this patch caches the dss clock
rate in dss.c when it is set. Dispc will then ask for the clock rate
from dss. While this is not very elegant, it does fix the issue, and
it's not totally wrong when considering that the dispc fck actually
comes via dss.

In the future we should probably look into common clock framework and
see if that could be used to represent the DSS clock tree properly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdss_compat_init() and omapdss_compat_uninit() is called internally
by omapdss. This patch moves the calls to omapfb, omap_vout and omapdrm
drivers. omapdrm driver can later remove the call after non-compat
support has been implemented in omapdrm.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Export DISPC functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Export dss_features related functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Export dss_mgr_ops related functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Separate the core DSS files and compat layer files in the Makefile for
clarity.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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

dpi.c uses dss_mgr_check_timings() to verify video timings, but that
function is in the compat layer. Change dpi.c to use the dispc's check
instead.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch adds a new function, dispc_ovl_check(), which can be used to
verify scaling configuration for an overlay. The function gets both the
overlay and overlay manager as parameters, so that the caller does not
need to configure the hardware before using this function.
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>

We have two functions to wait for a dispc interrupt:

int omap_dispc_wait_for_irq_timeout(u32 irqmask, unsigned long timeout);
int omap_dispc_wait_for_irq_interruptible_timeout(u32 irqmask,

Of these, the former is not used at all, and can be removed. The latter
is only used by the compat layer, and can be moved to the compat layer
code.
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>

Commit 5d89bcc3 (OMAPDSS: remove initial
display code from omapdss) moved setting up the initial overlay, overlay
manager, output and display connections from omapdss to omapfb.

However, currently omapfb only handles the connection related to the
default display, which means that no overlay managers are connected to
other displays.

This patch changes omapfb to go through all dssdevs, and connect an
overlay manager to them.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently attach an output to a dssdev in the initialization code for
dssdevices in display.c. This works, but doesn't quite make sense: an
output entity represents (surprisingly) an output of DSS, which is
managed by an output driver. The output driver also handles adding new
dssdev's for that particular output.

It makes more sense to make the output-dssdev connection in the output
driver. This is also in line with common display framework.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapfb gives a WARN_ONCE if a predefined physical address is given for
allocating the framebuffer memory, as this is not currently supported.

However, the same warning happens if omapfb fails to allocate memory
during runtime, as when the allocation has failed, omapfb tries to
re-allocate the old memory with the physical address of the old memory
area.

Remove the warning from omapfb_alloc_fbmem, as it serves no purpose on
the failure case above, and move it to omapfb_parse_vram_param, so that
we only warn if physical address is given via omapfb module parameters.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Kernel lock verification code has lately detected possible circular
locking in omapfb. The exact problem is unclear, but omapfb's current
locking seems to be overly complex.

This patch simplifies the locking in the following ways:

- Remove explicit omapfb mem region locking. I couldn't figure out the
  need for this, as long as we take care to take omapfb lock.

- Get omapfb lock always, even if the operation is possibly only related
  to one fb_info. Better safe than sorry, and normally there's only one
  user for the fb so this shouldn't matter.

- Make sure fb_info lock is taken first, then omapfb lock.

With this patch the warnings about possible circular locking does not
happen anymore.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>

Currently omapfb_realloc_fbmem() calls dssdev->sync to ensure any
possible frame update is finished. This patch moves the call to
dssdev->sync from omapfb_realloc_fbmem to the callers of
omapfb_realloc_fbmem.

This keeps dssdev related calls out from omapfb_realloc_fbmem, which
makes sense as the function should only deal with fb memory. Also, this
seems to avoid a lockdep warning about possible circular locking.
However, the exact reason for that warning is still unclear.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapfb contains an exported omapfb_update_window function, which, at
some point in history, was used by a closed source SGX driver. This was
a hack even then, and should not be needed anymore. So remove it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The i2c_device_id table is supposed to be zero-terminated.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the register.

All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since
it's corresponding platform device is the parent platform device("omapdss_dss").
The dss_core hwmod updates it's context lost count correctly and clears the
register. When the hwmods corresponding to the children platform devices are
enabled, they see that the register is clear, and don't increment their context
lost count. Therefore, all the children platform devices never report a loss in
context.

The DISPC driver currently gets the context lost count for DSS power domain from
it's corresponding platform device instance("omapdss_dispc"). The DISPC platform
device is one of the child devices, and it's corresponding hwmod("dss_dispc")
doesn't report the context lost count correctly.

Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss"
platform device as it's input, move the function to dss.c so that it has access
to that platform device.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add dss_get_core_pdev() which returns the platform device for dss core
device. The following patches use the core pdev to register sysfs files
in the compat code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>