Currently, clock database has <dev, clock-name> tuples for DSS2. Because of
this, the clock names are different across different OMAP platforms.

This patch aligns the DSS2 clock names and roles across OMAP 2420, 2430, 3xxx,
44xx platforms in the clock databases, hwmod databases for opt-clocks, and DSS
clock handling.

This ensures that clk_get/put/enable/disable APIs in DSS can use uniform role
names.
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Acked-by: NPaul Walmsley <paul@pwsan.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DSS IRQ number can be obtained from platform_get_irq().  This API in turn
picks the right IRQ number belonging to HW IP from the hwmod database.
So hardcoding of IRQ number could be removed.

This IRQ is stored in dss_irq as part of dss structure, and freed it in
dss_exit().
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DSS, DISPC, DSI, RFBI, VENC baseaddr can be obtained from platform_get_resource().
This API in turn picks the right silicon baseaddr from the hwmod database.
So hardcoding of base addr could be removed.
Reviewed-by: NPaul Walmsley <paul@pwsan.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch replaces printk's in the init/probe functions to dev_dbg
for boot time optimization.
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DSI is created and init exit methods are moved from core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

Also, vdds_dsi regulator handling is copied to dsi.c, since vdds_dsi regulator is
needed by dpi_init() too. Board files are updated accordingly to add 2 instances of
vdds_dsi regulator.

DSI platform driver is registered from inside omap_dss_probe, in the order desired.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for VENC is created and init exit methods are moved from core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

Also, venc_vdda_dac reading is moved to venc.c.

VENC platform driver is registered from inside omap_dss_probe, in the order desired.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for DISPC is created and init exit methods are moved from core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

DISPC platform driver is registered from inside omap_dss_probe, in the order desired.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver for RFBI is created and init exit methods are moved from core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

RFBI platform driver is registered from inside omap_dss_probe, in the order desired.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

All clock management is moved to dss platform driver. clk_get/put APIs use
dss device instead of core platform device.

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So the device name is changed from omapdss to omapdss_dss in 2420, 2430,
3xxx clock database files. Now the core driver "omapdss" only takes care
of panel registration with the custom bus.
core driver also uses the clk_enable() / clk_disable() APIs exposed by DSS for
clock management.
DSS driver would do clock management of clocks needed by DISPC, RFBI, DSI, VENC

TODO:  The clock content would be adapted to omap_hwmod in a seperate series.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Hwmod adaptation design requires each of the DSS HW IP to be a platform driver.
So a platform_driver of DSS is created and init exit methods are moved from core.c
to its driver probe,remove. pdev member has to be maintained by its own drivers.

DSS platform driver is registered from inside omap_dss_probe, in the order desired.
Signed-off-by: NSenthilvadivu Guruswamy <svadivu@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

As part of omap hwmod changes, DSS will not be the only controller of its
clocks. hwmod initialization also enables the interface clocks, and
manages them.
So, when DSS is built as a module, omap_dss_remove doesn't try to disable
all clocks that have a higher usecount.
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The -rt patches change the console_semaphore to console_mutex.  As a
result, a quite large chunk of the patches changes all
acquire/release_console_sem() to acquire/release_console_mutex()

This commit makes things use more neutral function names which dont make
implications about the underlying lock.

The only real change is the return value of console_trylock which is
inverted from try_acquire_console_sem()

This patch also paves the way to switching console_sem from a semaphore to
a mutex.

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert]
Signed-off-by: NTorben Hohn <torbenh@gmx.de>
Cc: Thomas Gleixner <tglx@tglx.de>
Cc: Greg KH <gregkh@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Now vgacon_scrollback_startup() uses slab, not bootmem,
the comment above it is obsolete, so does __init_refok.
Signed-off-by: NWANG Cong <amwang@redhat.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

lcd_device_register may return ERR_PTR, so a check is added for this value
before the dereference.  All of the other changes reorganize the error
handling code in this function to avoid duplicating all of it in the added
case.

In the original code, in one case, the global variable fb_buffer was set to
NULL in error code that appears after this variable is initialized.  This
is done now in all error handling code that has this property.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
identifier f;
@@
f(...) { ... return ERR_PTR(...); }

@@
identifier r.f, fld;
expression x;
statement S1,S2;
@@
 x = f(...)
 ... when != IS_ERR(x)
(
 if (IS_ERR(x) ||...) S1 else S2
|
*x->fld
)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Acked-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Current implementation calls pxa168fb_check_var twice in pxa168fb_probe.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Current implementation puts CONFIG_CPU_FREQ at wrong place, CONFIG_CPU_FREQ
is for lcd_da8xx_cpufreq_deregister not for unregister_framebuffer.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Fix collision with kernel-supplied #define:

  drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined
  arch/x86/include/asm/page_64_types.h:6:1: warning: this is the location of the previous definition
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Haojian Zhuang <haojian.zhuang@marvell.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
is used to configure any non-standard kernel with a much larger scope than
only small devices.

This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
references to the option throughout the kernel.  A new CONFIG_EMBEDDED
option is added that automatically selects CONFIG_EXPERT when enabled and
can be used in the future to isolate options that should only be
considered for embedded systems (RISC architectures, SLOB, etc).

Calling the option "EXPERT" more accurately represents its intention: only
expert users who understand the impact of the configuration changes they
are making should enable it.
Reviewed-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Cc: Greg KH <gregkh@suse.de>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robin Holt <holt@sgi.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Return -EFAULT instead of number of bytes that could not be copied if
copy_from_user() fails.

Also fix a typo in the comments.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This patch fixes below compile error:

  CC      drivers/video/nuc900fb.o
drivers/video/nuc900fb.c: In function 'nuc900fb_suspend':
drivers/video/nuc900fb.c:726: error: too few arguments to function 'nuc900fb_stop_lcd'
drivers/video/nuc900fb.c: In function 'nuc900fb_resume':
drivers/video/nuc900fb.c:743: error: 'bfinfo' undeclared (first use in this function)
drivers/video/nuc900fb.c:743: error: (Each undeclared identifier is reported only once
drivers/video/nuc900fb.c:743: error: for each function it appears in.)
make[2]: *** [drivers/video/nuc900fb.o] Error 1
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Acked-by: NWan ZongShun <mcuos.com@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

It seems there is a small problem of VGA palette corruption on EFI
machine.  When the kernel initializes the architecture, it checks if the
machine is a EFI machine and assumes that a VGA console can exist.

When it initializes the console in vgacon_startup it checks if it can
really use the VGA console.  I think this is where a check is missing.
Currently, the function can fail if a VESA boot mode is detected but not if
a EFI boot mode was used.

Thus vgacon_startup() doesn't fail and initialize the video card for a real
VGA mode.  This function changes the first 16entries of the VGA palette.

When the efifb driver kicks in, the palette is not restored to default
ramp value, thus the 16 first entry remain in a modified state.  The
following patch prevent this corruption.
Signed-off-by: NYannick Heneault <yheneaul@matrox.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The reset command is part of the init sequence and it take effect
only if the lcd is powered.

The effect of the bug was that the sequence:
set lcd power_state to FB_BLANK_POWERDOWN
set lcd power_state to FB_BLANK_UNBLANK
Did not produced a complete reboot of the LCD which was showing fuzzy
colours.

This was not experienced before implementing correctly all the LCD power
states with the patch [1].  Since before the patch [1] the regulators were
not touched and the LCD shutdown was reached with a register write.  After
the patch [1] a complete boot sequence with an initial reset is needed for
the display every time the LCD is powered up.

drivers-video-backlight-l4f00242t03c-full-implement-fb-power-states-for-this-lcd.patch
Signed-off-by: NAlberto Panizzo <maramaopercheseimorto@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Axel Lin <axel.lin@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Otherwise a double call to:
$ echo 4 > /sys/class/lcd/l4f00242t03/lcd_power
Will, the first power down the lcd and regulators correctly and the
second produce an unbalanced call to regulator disable.
Signed-off-by: NAlberto Panizzo <maramaopercheseimorto@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Axel Lin <axel.lin@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Complete the support of fb power states managing correctly the regulators
bound to this driver.
Signed-off-by: NAlberto Panizzo <maramaopercheseimorto@gmail.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Marek Vasut <marek.vasut@gmail.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Axel Lin <axel.lin@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixes sparse warning:
drivers/video/backlight/l4f00242t03.c:28:21: error: dubious one-bit signed bitfield
Signed-off-by: NMariusz Kozlowski <mk@lab.zgora.pl>
Acked-by: NRichard Purdie <rpurdie@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Kconfig entries SH_MIPI_DSI and SH_LCD_MIPI_DSI while being invisible to
the user, broke the FrameBuffer menu (at least in menuconfig), as they
aren't depending on respective menuconfig item (FB). In result several
items got moved to the main "Graphics support" menu. Move these two
problematic items to the top of drivers/video/Kbuild to restore nice
display of FB menu.
Signed-off-by: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Implement simple blanking in pseudocolor modes for vt8500lcdfb

This follows the style of some other in-tree drivers by just setting
the hardware palette colors to all black. True Color modes are not
affected, but this at least allows to run xf86-video-fbdev without
errors due to blanking being unimplemented.
Signed-off-by: NAlexey Charkov <alchark@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

i.MX processors are currently manufactured by Freescale, not Motorola.

Make the manufacturer's name consistent.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

clk_get() returns a struct clk cookie to the driver and some platforms
may return NULL if they only support a single clock.  clk_get() has only
failed if it returns a ERR_PTR() encoded pointer.

Cc: linux-fbdev@vger.kernel.org
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Acked-by: NWan ZongShun <mcuos.com@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

clk_get() returns a struct clk cookie to the driver and some platforms
may return NULL if they only support a single clock.  clk_get() has only
failed if it returns a ERR_PTR() encoded pointer.

Cc: Vincent Sanders <support@simtec.co.uk>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: NJamie Iles <jamie@jamieiles.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

A part of file: drivers/video/modedb.c was not as per the coding guidelines.

The cleanup includes:
1) Converting spcaes to tabs
2) Adding spaces on either sides of "|" operator
Signed-off-by: NMayuresh Janorkar <mayur@ti.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Fix section mismatch errors in the ep93xx-fb driver resulting from
incorrect init/exit annotations.
Reported-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NRyan Mallon <ryan@bluewatersys.com>
Tested-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Configuring the kernel I found that the Matrox frame buffer help has a
different option than the one in the docs (Documentation/fb/matroxfb.txt).
I decided to check the source code to see what is the correct option.
drivers/video/matrox/matroxfb_base.c has a lot of comments that sugests
that the video option is "matrox".
However in line 2452 of this same file you have:
fb_get_options("matroxfb", &option)

video=matroxfb:XXX is the correct video option not video=matrox:XXX.
Signed-off-by: NVicente Jimenez Aguilar <googuy@gmail.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

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

A previous patch added a framebuffer notifier to sh_mobile_hdmi.c,
but did not register it with the framebuffer core. This patch adds
such a registration and moves the notifier block into dynamically
allocated per-device private data.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Currently, if no command-line option is specified, the sh_mobile_hdmi
will use the default 720p video mode. If a command line option of the
form "video=sh_mobile_lcdc:<width>x<height>@<refresh>" is provided,
the driver will look for that mode among those, available in the
monitor EDID. This patch adds the ability to request the driver to
use monitor's preferred mode by specifying 0 as width and hight in
the above string. If that mode is not supported by the system, the
driver will continue scanning through EDID modes, until it finds a
suitable one.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This patch fixes a potential memory leak when xenfb connect to
the backend fails.

Thanks for Ian's review and comments.

[v2: reworded the commit message a bit]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: NJoe Jin <joe.jin@oracle.com>
Tested-by: NGurudas Pai <gurudas.pai@oracle.com>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andrew Morton <akpm@linux-foundation.org>

When migrating guests over a long period we hit this:

<1>BUG: unable to handle kernel paging request at 0000000b819fdb98
<1>IP: [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
<4>PGD 94b10067 PUD 0
<0>Oops: 0000 [#1] SMP
.. snip..
Call Trace:
 [<ffffffff812712c9>] xenfb_send_event+0x5c/0x5e
 [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
 [<ffffffff812714ee>] xenfb_refresh+0x1b1/0x1d7
 [<ffffffff81270568>] ? sys_imageblit+0x1ac/0x458
 [<ffffffff81271786>] xenfb_imageblit+0x2f/0x34
 [<ffffffff8126a3e5>] soft_cursor+0x1b5/0x1c8
 [<ffffffff8126a137>] bit_cursor+0x4b6/0x4d7
 [<ffffffff8100ea5f>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
 [<ffffffff81269c81>] ? bit_cursor+0x0/0x4d7
 [<ffffffff812656b7>] fb_flashcursor+0xff/0x111
 [<ffffffff812655b8>] ? fb_flashcursor+0x0/0x111
 [<ffffffff81071812>] worker_thread+0x14d/0x1ed
 [<ffffffff81075a8c>] ? autoremove_wake_function+0x0/0x3d
 [<ffffffff81438d80>] ? _spin_unlock_irqrestore+0x16/0x18
 [<ffffffff810716c5>] ? worker_thread+0x0/0x1ed
 [<ffffffff810756e3>] kthread+0x6e/0x76
 [<ffffffff81012dea>] child_rip+0xa/0x20
 [<ffffffff81011fd1>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8101275d>] ? retint_restore_args+0x5/0x6
 [<ffffffff81012de0>] ? child_rip+0x0/0x20
Code: 6b ff 0c 8b 87 a4 db 9f 81 66 85 c0 74 08 0f b7 f8 e8 3b ff ff ff c9
c3 55 48 89 e5 48 83 ec 10 0f 1f 44 00 00 89 ff 48 6b ff 0c <8b> 87 a4 db 9f
81 66 85 c0 74 14 48 8d 75 f0 0f b7 c0 bf 04 00
RIP  [<ffffffff812a588f>] notify_remote_via_irq+0x13/0x34
 RSP <ffff8800e7bf7bd0>
CR2: 0000000b819fdb98
---[ end trace 098b4b74827595d0 ]---

The root cause of the panic is the race between the resume and reconnect to the backend.

Clearing the 'update_wanted' flag of xenfb before disconnecting from the
backend fixes this issue.
Signed-off-by: NJoe Jin <joe.jin@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Tested-by: NGurudas Pai <gurudas.pai@oracle.com>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andrew Morton <akpm@linux-foundation.org>