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>

A panel connects to one of the overlay managers of DSS through some interface block.
On OMAP4, specifying the type of the display is not sufficient to conclude which manager
the panel should be connected to.
Hence, a new member 'channel' is introduced in omap_dss_device structure to determine
which manager the panel uses. The dss_recheck_connections() called in dss_driver_probe()
uses this channel parameter to set the correct manager to the corresponding omap_dss_device.

The channel parameter is used only once to ensure the correct managers are set for each
panel. The parameter dssdev->manager->id will take care of ensuring that the panel and
then the interface driver configures the correct DISPC channel.

Also, add a new Overlay Manager in manager.c, make other changes needed for LCD2 channel.
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NMukund Mittal <mmittal@ti.com>
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

DISPC_CONFIG bits LCDENABLEPOL, LCDENABLESIGNAL, PCKFREEENABLE and FUNCGATED
have been removed from OMAP4, use dss_features to handle them correctly.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

DISPC functions are modified in order to work when the manager is LCD2.
This includes:
Adding new IRQs specific to LCD2 and their handling.
Provide dumps of the new manager's registers.
Provide dumps of the new manager's clocks.
Checks for channel for registers DISPC_CONTROL2 and DISPC_CONFIG2
which can't be parametrized.
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NMukund Mittal <mmittal@ti.com>
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

The following dispc functions are also changed to incorporate channel as an argument:
	-dispc_lclk_rate()
	-dispc_pclk_rate()
	-dispc_set_pol_freq()
	-dispc_set_clock_div()
	-dispc_get_clock_div()
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NMukund Mittal <mmittal@ti.com>
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
[tomi.valkeinen@nokia.com: fixed trivial compile error]
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

The interface drivers (dsi.c, sdi.c etc) need to call dispc functions with
dssdev->manager->id as a parameter to specify the DISPC channel which they want
to configure/use, this is required as the same functions are now used to configure
dispc registers of different channels.

The following dispc functions are changed to incorporate channel as an argument:
	-dispc_enable_fifohandcheck()
	-dispc_set_lcd_size()
	-dispc_set_parallel_interface_mode()
	-dispc_set_tft_data_lines()
	-dispc_set_lcd_display_type()
	-dispc_set_lcd_timings()
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NMukund Mittal <mmittal@ti.com>
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
[tomi.valkeinen@nokia.com: fixed trivial compile error]
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. There is a set
of regsiters for LCD2 channel similar to the existing LCD channel, like
DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so on.

Introduce new enum members for LCD2 Channel and corresponding Overlay Manager
in display.h.

Represent the following DISPC register defines with channel as a parameter
to differentiate between LCD and LCD2 registers (and also DIGIT in some cases):

DISPC_DEFAULT_COLOR, DISPC_TRANS_COLOR, DISPC_TIMING_H, DISPC_TIMING_V,
DISPC_POL_FREQ, DISPC_DIVISOR, DISPC_SIZE_LCD, DISPC_DATA_CYCLEk,
DISPC_CPR_COEF_R, DISPC_CPR_COEF_G and DISPC_CPR_COEF_B

This parametrization helps in reducing the number of register defines for DISPC.
Replace the existing reads/writes to these registers in this new way.
Also, Introduce defines for registers DISPC_CONTROL2 and DISPC_CONFIG2 which
are used exclusively for LCD2 channel.
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NMukund Mittal <mmittal@ti.com>
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Initialize a dss_features struct for omap4.
Add support for LCD2 manager by introducing a new member in dss_feat_id.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

The supported set of color modes varies for different DISPC pipelines(plane)
and omap version. This makes the checks for validation of a color mode more
complicated as new omap versions are added.

A dss_feature function is created which tells if a color_mode is supported
for a plane on the current omap revision.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Still keep sharp_ls_panel driver, because it contains blacklight control driver.
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
Acked-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Generic DPI panel driver includes the driver and 4 similar panel configurations. It
will match the panel name which is passed from platform data and setup the
right configurations.

With generic DPI panel driver, we can remove those 4 duplicated panel display
drivers. In the future, it is simple for us just add new panel configuration
date in panel-generic-dpi.c to support new display panel.
Signed-off-by: NBryan Wu <bryan.wu@canonical.com>
Acked-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

A null pointer check added. And using kstrdup()
instead of kmalloc() & strcpy()
Signed-off-by: NSamreen <samreen@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>