Use dma_alloc_attrs to allocate memory instead of omap specific vram
allocator. After this we can remove the omap vram allocator.

There are some downsides to this change:

1) dma_alloc_attrs doesn't let us allocate at certain physical address.
However, this should not be a problem as this feature of vram allocator
is only used when reserving the framebuffer that was initialized by the
bootloader, and we don't currently support "passing" a framebuffer from
the bootloader to the kernel anyway.

2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and
we don't need the ioremap when using VRFB. This patch uses
DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently
not operational.

3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I
changed the ioctl to return 64M for all the values, which, I hope, the
applications will interpret as "there's enough vram".

4) "vram" kernel parameter to define how much ram to reserve for video
use no longer works. The user needs to enable CMA and use "cma"
parameter.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

With the introduction of output entities, managers will now connect to outputs.
Use the helper op for overlays named get_device. This will abstract away the
information on how to get the device from an overlay.

Using the helper function will reduce the number of pointer dereferences a user
of OMAPDSS needs to do and reduce risk of a NULL dereference.
Signed-off-by: NArchit Taneja <archit@ti.com>

If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.

This patch fixes the warnings by initializing the variables and
returning properly after BUG() lines. However, the behaviour is still
undefined after the BUG, but this is the choice the user makes when
using CONFIG_BUG=n.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Overlays are currently enabled and disabled with a boolean in the struct
omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
and made into use with mgr->apply().

This doesn't work properly, as the enable/disable status may affect also
other overlays, for example when using fifo-merge. Thus the enabling and
disabling of the overlay needs to be done outside the normal overlay
configuration.

This patch achieves that by doing the following things:

1) Add function pointers to struct omap_overlay: enable(), disable() and
is_enabled(). These are used to do the obvious. The functions may block.

2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.

3) Add a new route for settings to be applied to the HW, called
"extra_info". The status of the normal info and extra_info are tracked
separately.

The point here is to allow the normal info to be changed and
applied in non-blocking matter, whereas the extra_info can only be
changed when holding the mutex. This makes it possible to, for example,
set the overlay enable flag, apply it, and wait until the HW has taken
the flag into use.

This is not possible if the enable flag would be in the normal info, as
a new value for the flag could be set at any time from the users of
omapdss.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Implement auto-update mode for manual-update displays. omapfb driver
uses a delayed work to update the display with a constant rate.

The update mode can be changed via OMAPFB_SET_UPDATE_MODE ioctl, which
previously called omapdss but is now handled inside omapfb, and a new
sysfs file, "update_mode".

The update interval is by default 20 times per second, but can be
changed via "auto_update_freq" module parameter. There is also a new
module parameter "auto_update", which will make omapfb start manual
update displays in auto-update mode.

This auto-update mode can be used for testing if the userspace does not
support manual update displays properly. However, it is a very
inefficient solution, and should be considered more as a hack for
testing than something that could be used as a long term solution.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Create a new struct omapfb_display_data to contain omapfb's private
per-display data. Move the bpp override there.

This struct will be used to hold auto/manual update state of a display
in the following patches.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When DBG() is used in a simple if-else, the resulting code path
currently depends on the definition of DBG(). Inserting the statement in
a "do { ... } while (0)" prevents this possible misuse.
Signed-off-by: NNiels de Vos <ndevos@redhat.com>
[tomi.valkeinen@ti.com: changed the title of the commit msg]
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

arch/arm/plat-omap/include/plat/display.h is an include for the OMAP DSS
driver. A more logical place for it is in include/video.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Trigger WARN_ON() messages from various places in the code in case the
memory region is not currently locked.
Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

When more than one memory region needs to be lockd at the same time use
the memory region id to fix the order in which the locks are taken. Also
one needs to use the _nested() versions of the locking primitives. The
memory region id can serve as the lock class there as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

R/W semaphore is a good fit for the memory region locking pattern.
So use it.
Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Add locking to the memory regions to make sure the memory region size
won't be changed while some other piece of code is performing some
checks or setup based on that information.
Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Separate the memory region from the framebuffer device a little bit.
It's now possible to select the memory region used by the framebuffer
device using the new mem_idx parameter of omapfb_plane_info. If the
mem_idx is specified it will be interpreted as an index into the
memory regions array, if it's not specified the framebuffer's index is
used instead. So by default each framebuffer keeps using it's own
memory region which preserves backwards compatibility.

This allows cloning the same memory region to several overlays and yet
each overlay can be controlled independently since they can be
associated with separate framebuffer devices.
Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

In omapfb_enable_overlay() if the overlay state is already what we want
skip the set_overlay_info().
Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Move get_recommended_bpp() from omap_dss_device to omap_dss_driver.

This is part of a larger patch-set, which moves the control from omapdss
driver to the display driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>