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>

This fixes a sparse warning.

Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Following commits:

50e244cc fb: rework locking to fix lock ordering on takeover
e93a9a86 fb: Yet another band-aid for fixing lockdep mess
054430e7 fbcon: fix locking harder

reworked locking to fix related lock ordering on takeover, and introduced console_lock
into fbmem, but it seems that the new lock sequence(fb_info->lock ---> console_lock)
is against with the one in console_callback(console_lock ---> fb_info->lock), and leads to
a potential dead lock as following:

[  601.079000] ======================================================
[  601.079000] [ INFO: possible circular locking dependency detected ]
[  601.079000] 3.11.0 #189 Not tainted
[  601.079000] -------------------------------------------------------
[  601.079000] kworker/0:3/619 is trying to acquire lock:
[  601.079000]  (&fb_info->lock){+.+.+.}, at: [<ffffffff81397566>] lock_fb_info+0x26/0x60
[  601.079000]
but task is already holding lock:
[  601.079000]  (console_lock){+.+.+.}, at: [<ffffffff8141aae3>] console_callback+0x13/0x160
[  601.079000]
which lock already depends on the new lock.

[  601.079000]
the existing dependency chain (in reverse order) is:
[  601.079000]
-> #1 (console_lock){+.+.+.}:
[  601.079000]        [<ffffffff810dc971>] lock_acquire+0xa1/0x140
[  601.079000]        [<ffffffff810c6267>] console_lock+0x77/0x80
[  601.079000]        [<ffffffff81399448>] register_framebuffer+0x1d8/0x320
[  601.079000]        [<ffffffff81cfb4c8>] efifb_probe+0x408/0x48f
[  601.079000]        [<ffffffff8144a963>] platform_drv_probe+0x43/0x80
[  601.079000]        [<ffffffff8144853b>] driver_probe_device+0x8b/0x390
[  601.079000]        [<ffffffff814488eb>] __driver_attach+0xab/0xb0
[  601.079000]        [<ffffffff814463bd>] bus_for_each_dev+0x5d/0xa0
[  601.079000]        [<ffffffff81447e6e>] driver_attach+0x1e/0x20
[  601.079000]        [<ffffffff81447a07>] bus_add_driver+0x117/0x290
[  601.079000]        [<ffffffff81448fea>] driver_register+0x7a/0x170
[  601.079000]        [<ffffffff8144a10a>] __platform_driver_register+0x4a/0x50
[  601.079000]        [<ffffffff8144a12d>] platform_driver_probe+0x1d/0xb0
[  601.079000]        [<ffffffff81cfb0a1>] efifb_init+0x273/0x292
[  601.079000]        [<ffffffff81002132>] do_one_initcall+0x102/0x1c0
[  601.079000]        [<ffffffff81cb80a6>] kernel_init_freeable+0x15d/0x1ef
[  601.079000]        [<ffffffff8166d2de>] kernel_init+0xe/0xf0
[  601.079000]        [<ffffffff816914ec>] ret_from_fork+0x7c/0xb0
[  601.079000]
-> #0 (&fb_info->lock){+.+.+.}:
[  601.079000]        [<ffffffff810dc1d8>] __lock_acquire+0x1e18/0x1f10
[  601.079000]        [<ffffffff810dc971>] lock_acquire+0xa1/0x140
[  601.079000]        [<ffffffff816835ca>] mutex_lock_nested+0x7a/0x3b0
[  601.079000]        [<ffffffff81397566>] lock_fb_info+0x26/0x60
[  601.079000]        [<ffffffff813a4aeb>] fbcon_blank+0x29b/0x2e0
[  601.079000]        [<ffffffff81418658>] do_blank_screen+0x1d8/0x280
[  601.079000]        [<ffffffff8141ab34>] console_callback+0x64/0x160
[  601.079000]        [<ffffffff8108d855>] process_one_work+0x1f5/0x540
[  601.079000]        [<ffffffff8108e04c>] worker_thread+0x11c/0x370
[  601.079000]        [<ffffffff81095fbd>] kthread+0xed/0x100
[  601.079000]        [<ffffffff816914ec>] ret_from_fork+0x7c/0xb0
[  601.079000]
other info that might help us debug this:

[  601.079000]  Possible unsafe locking scenario:

[  601.079000]        CPU0                    CPU1
[  601.079000]        ----                    ----
[  601.079000]   lock(console_lock);
[  601.079000]                                lock(&fb_info->lock);
[  601.079000]                                lock(console_lock);
[  601.079000]   lock(&fb_info->lock);
[  601.079000]
 *** DEADLOCK ***

so we reorder the lock sequence the same as it in console_callback() to
avoid this issue. And following Tomi's suggestion, fix these similar
issues all in fb subsystem.
Signed-off-by: NGu Zheng <guz.fnst@cn.fujitsu.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Turn clk_enable() and clk_disable() calls into clk_prepare_enable() and
clk_disable_unprepare() to get ready for the migration to the common
clock framework.

Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The lcdc B side horizon output is shifted
if sh_mobile_lcdc_pan() was called.
This patch fixup this issue.
It is tested on R8A7740 Armadillo800eva HDMI output.
Special thanks to Fukushima-san, and Sano-san
Reported-by: NOsamu Fukushima <osamu.fukushima.wr@renesas.com>
Signed-off-by: NHideyuki Sano <hideyuki.sano.dn@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

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>

The structure isn't used outside of its compilation unit, make it
static.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

There's no need to query the hardware for the currenty brightness value
through a platform data callback when we can cache the value internally
in the LCDC driver.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The channel and overlay init functions operate on a channel and an
overlay, don't pass the priv parameter explicitly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The sh_mobile_lcdc_channel_fb_init() mode argument is used to pass a
list of modes, rename it to modes.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Get the display dimensions directly from the channel structure instead
of recomputing them from the monitor specs or accessing the platform
data.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

fb_mmap() implemented in fbmem.c uses smem_start as the physical
address of the frame buffer.  In the sh_mobile_lcdc driver, the
smem_start is a dma_addr_t that is not a physical address when IOMMU is
enabled.  dma_mmap_coherent() maps the address correctly.
Signed-off-by: NHideki EIRAKU <hdk@igel.co.jp>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Commit 15dede88 added support for
horizontal panning but accidentally computes the Y pan step value
incorrectly for NV12/21 and NV16/61 formats. Fix this.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The chroma plane offset in memory is equal to the luma plane maximum
size. Fix offset computations.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Updating overlay registers require switching to overlay update mode.
This was correctly done when configuring the overlay format and size,
but not when updating the base address registers during pan operation.
Fix it.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Copy the x and y virtual resolutions from the channel information
instead of recomputing them.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Line pitch depends on the virtual horizontal resolution, compute it
accordingly.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Add a missing mutex_destroy() call when the driver is unbound from the
device.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

There's no reason to use abstract operation pointers to implement the
MERAM API. Replace them by direct function calls.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The MERAM operations meram_register, meram_unregister and meram_update
handle LCDC cache. In preparation for "raw" MERAM allocation, rename
them to more appropriate names.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Make all fb operation handlers start with sh_mobile_lcdc_ in preparation
for the multi-plane support.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The structure is only read, make it const.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

When using the MERAM the LCDC line size needs to be programmed with a
MERAM-specific value different than the real frame buffer pitch. Fix it.
Reported-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: stable@vger.kernel.org  # for 3.4
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The meram_register(), meram_unregister() and meram_update() operations
check that the pointers they get from the caller are not NULL. Those
checks can be remove, as the caller already ensures that the pointers
are valid.

The platform sanity checks can also be removed, as the operations can't
be accessed without valid platform data anyway.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Remove the RGB or Y/C base address update from the meram_register()
operation, as this belongs to the meram_update() operation.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Instead of copying the whole platform data structure to struct
sh_mobile_lcdc_chan, store a const pointer to the channel platform data.

MERAM configuration information needs to be changed at runtime, so copy
it to struct sh_mobile_lcdc_chan.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Instead of manually specifying the ICBs to use in platform data,
allocate them automatically at runtime. The range of reserved ICBs (for
instance to be used through UIO), if any, is passed in the platform data
reserved_icbs field as a bitmask.

The MERAM registration function now returns a pointer to an opaque MERAM
object, which is passed to the update and unregistration functions.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The sh_mobile_wait_for_vsync() function isn't related to the fbdev API,
make it generic by passing a channel pointer instead of an fb_info
pointer.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Store the frame buffer configuration (colorspace, visible/virtual
horizontal and vertical resolutions and line pitch) in the
sh_mobile_lcdc_chan structure, and use it instead of accessing fb_info.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The dma_map_sg() and dma_unmap_sg() functions need a pointer to the
physical device.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Store the active format in the channel structure, and use it instead of
parsing info->var all over the place when the format is needed.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The function returns a pointer to a structure describing a format based
on its fourcc. Use the function where applicable instead of hardcoded
switch-case statements.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The struct sh_mobile_lcdc_chan_cfg platform data contains a list of
video modes. Name the lcd_cfg and num_cfg fields to reflect that they
describe video modes.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Embed struct fb_videomode instead of struct fb_var_screeninfo in struct
sh_mobile_lcdc_chan to store the display mode.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The LCDC fb_info structure is only used to retrieve the default video
mode in case none of the modes advertised by EDID information is
acceptable. Pass a pointer to the default mode through the
sh_mobile_lcdc_entity structure instead.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Pass pointers to struct fb_videomode and struct fb_monspecs instead of
struct fb_var_screeninfo to the notify callback.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The callback implements 3 notification events:

- SH_MOBILE_LCDC_EVENT_DISPLAY_CONNECT notifies the LCDC that the
  display has been connected
- SH_MOBILE_LCDC_EVENT_DISPLAY_DISCONNECT notifies the LCDC that the
  display has been disconnected
- SH_MOBILE_LCDC_EVENT_DISPLAY_MODE notifies that LCDC that a display
  mode has been detected
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>