* 'fbdev-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/fbdev-2.6:
  fbdev: sh_mobile_lcdc: increase maximum framebuffer size to support 1080p
  video: imxfb: Fix the maximum value for yres
  fb: fix overlapping test off-by-one.
  fbdev: sh-mobile: retrieve and propagate display sizes from EDID
  fbdev: sh-mobile: restore display size configuration

LCDC hardware can support 1920x1080 formats, adjust the driver to cover them.
Besides, instead of guessing some "reasonable" validity checks, only verify
values in .fb_check_var(), that we are sure, we cannot support.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

MX27 and MX25 have 10 bits in the YMAX field of LCDC Size Register.

Fix the maximum value for yres.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

On my system with a radeon x2, the first GPU was not overlapping vesa
but the test decided it was.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Thomas Hellstrom <thomas@tungstengraphics.com>
Cc: Alan Hourihane <alanh@tungstengraphics.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Monitor EDID contains information about physical display sizes. Retrieve
it and propagate to the framebuffer driver.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

An earlier patch replaced open-coded video-mode configuration from
platform data by a call to fb_videomode_to_var(), thereby setting
ofdisplay sizes have been accidentally lost. Restore them.

Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>

* 'for-paul-rc' of git://gitorious.org/linux-omap-dss2/linux:
  OMAP: OMAPFB: disable old omapfb for OMAP4 builds
  OMAP: DSS: VRAM: Align start & size of vram to 2M

Build fails when OMAP4 and FB_OMAP are defined:

drivers/built-in.o: In function `omapfb_do_probe':
drivers/video/omap/omapfb_main.c:1773: undefined reference to `omap2_int_ctrl'

Old omapfb does not work on OMAP4, and never will. Change the omapfb
build dependency so that old omapfb depends on OMAP1/2/3, fixing the
build for plain OMAP4 builds.

Reported-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>

Align the start address and size of VRAM area to 2M as per comments from
Russell King:

> > So, why SZ_2M?
>
> Firstly, that's the granularity which we allocate page tables - one
> Linux page table covers 2MB of memory.  We want to avoid creating page
> tables for the main memory mapping as that increases TLB pressure through
> the use of additional TLB entries, and more page table walks.
>
> Plus, we never used to allow the kernel's direct memory mapping to be
> mapped at anything less than section size - this restriction has since
> been lifted due to OMAP SRAM problems, but I'd rather we stuck with it
> to ensure that we have proper behaviour from all parts of the system.
>
> Secondly, we don't want to end up with lots of fragmentation at the end
> of the memory mapping as that'll reduce performance, not only by making
> the pfn_valid() search more expensive.
>
> Emsuring a minimum allocation size and alignment makes sure that the
> regions can be coalesced together into one block, and minimises run-time
> expenses.
>
> So please, 2MB, or if you object, at the _very_ _least_ 1MB.  But
> definitely not PAGE_SIZE.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
Acked-by: Tony Lindgren <tony@atomide.com>