In case CONFIG_FB_PXA_OVERLAY is not defined, the pxafb_freq_transition()
function tests nonexistent member of pxafb_info (since the member is not
part of the structure).

Fix this by wraping the test in ifdef, even if I don't really like how the code
looks now. The check doesn't have to happen if overlays are disabled at all as
the check is always true then.

Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
Acked-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

It's not safe to disable controller if overlay(s) is enabled (results in
system hang). So we avoid to disable controller in this case. Userspace
should choose proper governor to avoid freq changing when overlay is in
use, otherwise LCD may blink.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

Sascha Hauer <s.hauer@pengutronix.de> pointed that
ypos takes value of xpos due to typo.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

pxafb_overlay_init is not right place to change Z-ordering,
move it to main plane initialization.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

PXAFB overlay memory management is something messy:
- it allocates memory dynamically on open/release, and it results
  in memory allocation failure after ~1h of uptime (system does not have
  115k of physically contiguous memory)
- in release callback it tries to free memory even if it was not
  allocated.

Also driver touches FDADR1 on main plane reconfiguration, and it can cause
problems if overlay1 is enabled.

This patch attempts to fix those issues.

Patch is based on Russell King's work.

Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

Commit "d2a34c1 drivers/video: Move dereference after NULL test" introduced
a build error of "fbi->dev->platform_data->smart_update" being unknown type
to the compiler, fix this by removing the unnecessary test of 'fbi'.

Cc: Julia Lawall <julia@diku.dk>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

If the NULL test on fbi is needed, then the dereference should be after the
NULL test.

A simplified version of the semantic match that detects this problem is as
follows (http://coccinelle.lip6.fr/):

// <smpl>
@match exists@
expression x, E;
identifier fld;
@@

* x->fld
  ... when != \(x = E\|&x\)
* x == NULL
// </smpl>

Signed-off-by: Julia Lawall <julia@diku.dk>
Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

This allows to select either RGB565 (transparency 0) or RGBT555
(transparency 1) from the mode info

Signed-off-by: Pieter Grimmerink <p.grimmerink@inepro.com>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>

pxafb_pan_display() used to ignore the fb_var_screeninfo parameter. Now
pass it to setup_base_frame() instead of pulling default values out of
fb_info.

And the original patch has an issue of pxafb_pan_display() paying only
attention to the 'var' parameter passed in, and Ville Syrjälä pointed
out, this is potentially dangerous as user could pass in any other
screeninfo parameters as well, and not only such that are relevant for
display panning. This is fixed by limiting the arguments actually used
to .xoffset, .yoffset and .vmode & FB_VMODE_YWRAP.

Signed-off-by: Sven Neumann <s.neumann@raumfeld.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Signed-off-by: Daniel Mack <daniel@caiaq.de>
Signed-off-by: Eric Miao <eric.y.miao@gmail.com>