Some old example code has been left lying around. Remove the example
code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Once in a time omapdss had basic support for fifomerge. Fifomerge was
removed as the implementation didn't work properly, and a proper
implementation is a complex problem.

However, some unused fifo-merge related code was left behind. This patch
removes those.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dispc_mgr_is_enabled() was missing a prototype in dss.h
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

ULPS cannot be entered if the DDR clk is enabled. Thus disable the DDR
clk before entering ULPS.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We sometimes get timeout when disabling the DSI interface with video
mode. It looks like the disable will stall until the current frame has
been finished, and this can take multiple milliseconds.

wait_for_bit_change() currently uses a busyloop to wait for a bit to
change. This is used in multiple places. The problem is, we don't have
clear understanding how long particular operations can take, so the
function needs to support longer waits.

Improve wait_for_bit_change() to first busy loop for 100 times to see if
the bit changes almost right away. If the bit hasn't changed, move to a
loop with a sleep of 1ms, and poll for 500ms.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The current code always enters ULPS for 3 lanes. This is not right, as
there could be only 2 lanes used, and on OMAP4 we have 5 lanes.

Fix the code to put all used lanes into ULPS.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

There's no longer need for the dsi_get_num_lanes_used function, so it
can be removed. The lane check in dsi_init_display() can be removed as
the validity of the config will be verified when parsing it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use the new lane config in dsi_cio_enable_lane_override(). The function
parameters are also slightly changed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use the new lane config in dsi_cio_wait_tx_clk_esc_reset(). This also
extends the function to support 5 lanes on OMAP4, instead of 3 lanes.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use the new lane config in dsi_get_lane_mask().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use the new lane config in dsi_set_lane_config().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Parse the lane configuration from the device data into internal lane
config format. This will be used in the following patches to clean up
the lane handling.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DSI driver currently counts used lanes and number of supported lanes by
using the number of data lanes (i.e. excluding clock lane). This patch
changes this to use the number of all lanes so that the following lane
config patches are cleaner.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Flush posted write in _enable_lcd_out() and _enable_digit_out(). This
ensures the the lcd/digit bit is written before the code starts waiting
for interrupts about enabling/disabling the output.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Flush posted write after setting the bit to send the BTA to ensure the
BTA is sent right away, as the code in dsi_vc_send_bta_sync() waits for
an interrupt caused indirectly by sending the BTA.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Flush posted write between writing the ULPS enable bits and waiting for
the interrupt.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add data for the FocalTech ETM070003DH6 display to the generic_dpi_panel
display driver.
Signed-off-by: NIlya Yanok <yanok@emcraft.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

While the OLPC display appears to be able to handle either positive
or negative sync, the Display Controller only recognises positive sync.

This brings viafb (for XO-1.5) in line with lxfb (for XO-1) and
fixes a recent regression where the XO-1.5 DCON could no longer be
frozen. Thanks to Florian Tobias Schandinat for helping identify
the fix.

Test case: from a vt,
	echo 1 > /sys/devices/platform/dcon/freeze
should cause the current screen contents to freeze, rather than garbage being
displayed.
Signed-off-by: NDaniel Drake <dsd@laptop.org>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: stable@kernel.org

Patch follows the disable and software reset sequence specified
in version2 to LCDC functional specification.
Without this flicker is observed on re-enabling the LCDC.
Signed-off-by: NManjunathappa, Prakash <prakash.pm@ti.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Current code calculates scaling factors for video overlays even when the
overlays are not scaled. Change the code to skip calculations when not
scaling.

This optimizes the code a bit, but also fixes a problem when configuring
an overlay for a disabled display: if the display is disabled we don't
necessarily know the pixel clock used when the display is enabled, and
in some cases (like HDMI) the pixel clock is set to zero until a proper
video mode is set later. A wrong pixel clock will mess up the
scaling calculations, causing an error like:

omapdss DISPC error: failed to set up scaling, required fclk rate = 0
Hz, current fclk rate = 170666666 Hz

A proper fix would be to check later whether the clocks are enough for the
scaling, at the point when the overlay or display is actually enabled,
but this patch removes the problem for now.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Fix warnings similar to this by including module.h:

drivers/video/omap/dispc.c:276:1: warning: data definition has no type
or storage class
drivers/video/omap/dispc.c:276:1: warning: type defaults to 'int' in
declaration of 'EXPORT_SYMBOL'
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

hdmi_get_pixel_clock() returns the pixel clock in Hz, but the pck is
stored as kHz. This means the return value has to be multiplied by 1000,
not by 10000 as the code did.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The rename of corgibl_limit_intensity is missed in commit d00ba726
("backlight: Rename the corgi backlight driver to generic").  Let's fix it
now.
Signed-off-by: NAxel Lin <axel.lin@gmail.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>

Using gpio_request_one can make the error handling simpler.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.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 regulator support in the l4f00242t03 is very non-idiomatic.  Rather
than requesting the regulators based on the device name and the supply
names used by the device the driver requires boards to pass system
specific supply names around through platform data.  The driver also
conditionally requests the regulators based on this platform data, adding
unneeded conditional code to the driver.

Fix this by removing the platform data and converting to the standard
idiom, also updating all in tree users of the driver.  As no datasheet
appears to be available for the LCD I'm guessing the names for the
supplies based on the existing users and I've no ability to do anything
more than compile test.

The use of regulator_set_voltage() in the driver is also problematic,
since fixed voltages are required the expectation would be that the
voltages would be fixed in the constraints set by the machines rather than
manually configured by the driver, but is less problematic.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: NFabio Estevam <fabio.estevam@freescale.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>

A few new i2c-drivers came into the kernel which clear the
clientdata-pointer on exit or error.  This is obsolete meanwhile, the core
will do it.
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Paul Mundt <lethal@linux-sh.org>
Acked-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

They were getting this implicitly by an include of module.h
from device.h -- but we are going to clean that up and break
that include chain, so include module.h explicitly now.

[ with contributions from Axel Lin <axel.lin@gmail.com> ]
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

With module.h being implicitly everywhere via device.h, the absence
of explicitly including something for EXPORT_SYMBOL went unnoticed.
Since we are heading to fix things up and clean module.h from the
device.h file, we need to explicitly include these files now.
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>

Now that no driver any longer depends on the CONFIG_SOC_AU1???  symbols,
it's time to get rid of them: Move some of the platform devices to the
boards which can use them, Rename a few (unused) constants in the header,
Replace them with MIPS_ALCHEMY in the various Kconfig files.  Finally
delete them altogether from the Alchemy Kconfig file.
Signed-off-by: NManuel Lauss <manuel.lauss@googlemail.com>
To: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: https://patchwork.linux-mips.org/patch/2707/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

According to the comments in include/linux/init.h:

"Pointers to __devexit functions must use __devexit_p(function_name), the
wrapper will insert either the function_name or NULL, depending on the config
options."

We have __devexit annotation for platinumfb_remove(), thus add __devexit_p at
necessary place.
Signed-off-by: NAxel Lin <axel.lin@gmail.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

This tries to clear up the confusion between integers and iomem pointers
in the marvell pxa platform. MMIO addresses are supposed to be __iomem*
values, in order to let the Linux type checking work correctly. This
patch moves the cast to __iomem as far back as possible, to the place
where the MMIO virtual address windows are defined.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

The diu_pool structure contains diu_addr objects for various objects
allocated in DMA space that are used by the DIU, but the only instance
of this structure is a global variable, 'pool'.  Eliminate 'pool' by
merging its fields into the fsl_diu_data structure, which is instantiated
on the heap for each DIU controller found.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The diu_hw structure contains two fields used to access the DIU registers,
but the only instance of this structure is a global variable, 'dr'.
Eliminate 'dr' by merging its fields into the fsl_diu_data structure,
which is instantiated on the heap for each DIU controller found.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The Freescale DIU video controller supports five video "modes", but only
the first two are used by the driver.  The other three are special modes
that don't make sense for a framebuffer driver.  Therefore, there's no
point in keeping a global variable that indicates which mode we're
supposed to use.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The MFB_TYPE_xxx macros indicate different "operating modes" of each AOI,
but this feature is not actually used in the driver.  The mfb_index.type
field is always set to MFB_TYPE_OUTPUT, so just delete it and any code
that references it.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Each of the five AOIs created by the DIU driver has a special purpose, and
they're not treated equally.  It makes sense to identify them with an enum
instead of a hard-coded number.

Since the 'index' is now an enum, it can only contain allowed values, so
there's no need to check for an invalid value.  This simplifies some other
code, such as fsl_diu_disable_panel(), which no longer needs to return an
error code.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Add the following new video modes to the Freescale DIU framebuffer driver:

640x480x60
640x480x72
640x480x75
640x480x90
640x480x100
800x480x60
800x600x60
854x480x60
1280x480x60
1280x720x60
1920x1080x60

Also add margin data to the 320x240 video mode.  This mode was originally
intended only for the AOIs (overlays) used on planes two and three, but with
real margin data, it can now be used as an actual video mode.
Video mode data is from earlier work done by Jerry Huang
<Chang-Ming.Huang@freescale.com>.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

The function which is supposed to provide screen blanking support doesn't
actually do anything, so the framebuffer layer thinks the screen has
been blanked when it really isn't.  Remove the code completely for now.

A side-effect of this change is that the framebuffer console blanking now
works correctly.  Presumably this is because the console now receives -EINVAL
instead of '0' when it asks the driver to blank the screen, so the console
does it manually now.

A signficant refactoring of the driver is planned, and proper hardware
blanking support will added afterwards.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

Move several macros and structures from the Freescale DIU driver's header
file into the source file, because they're only used by that file.  Also
delete a few unused macros.

The diu and diu_ad structures cannot be moved because they're being used
by the MPC5121 platform file.  A future patch eliminate the need for
the platform file to access these structs, so they'll be moved also.
Signed-off-by: NTimur Tabi <timur@freescale.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>