The omap_dss_start_device() and omap_dss_stop_device(), called by the
DSS output drivers, are old relics. They originally did something
totally else, but nowadays they increase the module ref count for panels
that are enabled.

This model is quite broken: the panel modules may be used even before
they are enabled. For example, configuring the panel requires calls to
functions located in the panel modules.

In the following patches we try to improve the ref count management for
the modules and display devices. The first step, however, is to remove
the omap_dss_start/stop_device() totally.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.

After we've finished the removal of the dss bus, we see the following
changes:

- struct omap_dss_device won't be a real Linux device anymore, but more
  like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
  entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
  platform/i2c/spi/etc devices/drivers, whichever fits the control
  mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
  fill the required fields, and register the omap_dss_device to
  omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
  dev pointer to the actual device that manages the omap_dss_device.

The model described above resembles the model that has been discussed
with CDF (common display framework).

For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "old_dev", which is a full embedded device struct, and the
new "dev", which is a pointer to the device. "old_dev" will be removed
in the future.

For devices belonging to dss bus the dev is initialized to point to
old_dev. This way all the code can just use the dev, for both old and
new style panels.

Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We aim to remove the custom omapdss bus totally, as it's quite a strange
construct and won't be compatible with common display framework. One
problem on the road is that we have sysfs files for each display, and
they depend on the omapdss bus.

This patch creates the display sysfs files independent of the omapdss
bus. This gives us backwards compatibility without using the omapdss bus
for the sysfs files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We have support functions to suspend and resume all the displays that
are used with system suspend. These functions use the dss bus to iterate
the display devices.

As we aim to remove the custom dss bus totally, this patch removes the
explicit use of dss bus from these functions. Instead the
for_each_dss_dev() macro is used to go through the devices.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_dss_get_next_device() uses the dss bus to iterate over the
displays. This patch changes omap_dss_get_next_device() to use the new
panel list instead.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently use the omapdss bus (which contains all the available
displays) to iterate the displays. As the omapdss bus is on its way out,
this needs to be changed.

Instead of using the dss bus to iterate displays, this patch adds our
own list of displays which we manage. The panels on the dss bus are
automatically added to this new list.

An "alias" field is also added to omap_dss_device. This field is
set to "display%d", the same way as omap_dss_device's dev name is set.
This alias is later used to keep backward compatibility, when the
embedded dev is no longer used.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In the future the "dssdev" parameter passed to output drivers will
change its meaning. Instead of being a pointer to the panel device, it's
a pointer to the output instance.

To make the transition easier, some of the uses for this dssdev
parameter can be easily removed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add helper functions to convert between omapdss specific video timings
and the common videomode.

Eventually omapdss will be changed to use only the common video timings,
and these helper functions will make the transition easier.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Clean up the VENC driver's regulator init to remove the (unused)
omap_dss_device parameter, renaming the function to a more sensible
name, and making the code slightly clearer.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

SDI requires a regulator to operate. This regulator is, for some reason,
currently attached to the virtual omapdss device, instead of the SDI
device. This does not work for DT, as the regulator mappings need to be
described in the DT data, and the virtual omapdss device is not present
there.

Fix the issue by acquiring the regulator in the SDI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to SDI.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Clean up the SDI driver's regulator init to remove the (unused)
omap_dss_device parameter, renaming the function to a more sensible
name, and making the code slightly clearer.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Separate regulator init code into its own function for clarity.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the virtual omapdss device is not present there.

Fix the issue by acquiring the regulator in the DPI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to DPI.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Split regulator and DSI PLL init code to their own functions for
clarity.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Separate the regulator initialization code to its own function, removing
duplicate code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use devm_regulator_get() instead of regulator_get() to simplify code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.

This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.

To support that kind of scenarios, we need to add new step to the
initialization: connect.

This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.

One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.

This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Currently omapdrm creates crtcs, which map directly to DSS overlay
managers, only on demand at init time. This would make it difficult to
manage connecting the display entities in the future, as the code cannot
just search for a suitable overlay manager.

We cannot fix this the sane way, which would be to create crtcs for each
overlay manager, because we need an overlay for each crtc. With limited
number of overlays, that's not possible.

So the solution for now is to detach the overlay manager from the crtc.
crtcs are still created on demand at init time, but all overlay managers
are always initialized by the omapdss.

This way we can create and connect whole display pipelines from the
overlay manager to the display, regardless of which crtcs omapdrm would
create.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Split the function that creates overlay manager structs into two: one
that creates just the structs, and one that creates the sysfs files for
the manager.

This will help us use the overlay manager structs with omapdrm in the
following patches, while still leaving the sysfs files out.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add two helper functions that can be used to find either the DSS output
or the overlay manager that is connected to the given display.

This hides how the output and the manager are actually connected, making
it easier to change the connections in the future.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Minor cleanup for the dss_[ovl|mgr]_get_device() functions to make them
more readable.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When using DT, dss device does not have platform data. However,
dss_get_ctx_loss_count() uses dss device's platform data to find the
get_ctx_loss_count function pointer.

To fix this, dss_get_ctx_loss_count() needs to be changed to get the
platform data from the omapdss device, which is a "virtual" device and
always has platform data.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add a support function to find a DSS output by given DT node. This is
used in later patches to link the panels to DSS outputs.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add a support function to find a DSS output by given name. This is used
in later patches to link the panels to DSS outputs.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdss output drivers always read the platform data. This crashes when
there's no platform data when using DT.

Add a check to read the platform data only if it exists.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We can currently set the default display (i.e. the initial display) in
the omapdss platform data by using a pointer to the default
omap_dss_device. Internally omapdss uses the device's name to resolve
the default display.

As it's difficult to get the omap_dss_device pointer in the future,
after we've changed the omapdss device model, this patch adds a new way
to define the default display, by using the name of the display.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

When removing atmel_lcdfb module, the backlight is unregistered but not
blanked. (only for CONFIG_BACKLIGHT_ATMEL_LCDC case).
This can result in the screen going full white depending on how the PWM
is wired.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

When a too small framebuffer is given, the atmel_lcdfb_check_var
silently fails.
Adding an error message will save some head scratching.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Signed-off-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>

If NO_DMA=y:

  drivers/built-in.o: In function `goldfish_fb_remove':
  drivers/video/goldfishfb.c:301: undefined reference to `dma_free_coherent'
  drivers/built-in.o: In function `goldfish_fb_probe':
  drivers/video/goldfishfb.c:247: undefined reference to `dma_alloc_coherent'
  drivers/video/goldfishfb.c:280: undefined reference to `dma_free_coherent'
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

A simple frame-buffer describes a raw memory region that may be rendered
to, with the assumption that the display hardware has already been set
up to scan out from that buffer.

This is useful in cases where a bootloader exists and has set up the
display hardware, but a Linux driver doesn't yet exist for the display
hardware.

Examples use-cases include:

* The built-in LCD panels on the Samsung ARM chromebook, and Tegra
  devices, and likely many other ARM or embedded systems.  These cannot
  yet be supported using a full graphics driver, since the panel control
  should be provided by the CDF (Common Display Framework), which has been
  stuck in design/review for quite some time.  One could support these
  panels using custom SoC-specific code, but there is a desire to use
  common infra-structure rather than having each SoC vendor invent their
  own code, hence the desire to wait for CDF.

* Hardware for which a full graphics driver is not yet available, and
  the path to obtain one upstream isn't yet clear.  For example, the
  Raspberry Pi.

* Any hardware in early stages of upstreaming, before a full graphics
  driver has been tackled.  This driver can provide a graphical boot
  console (even full X support) much earlier in the upstreaming process,
  thus making new SoC or board support more generally useful earlier.

[akpm@linux-foundation.org: make simplefb_formats[] static]
Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Acked-by: NOlof Johansson <olof@lixom.net>
Cc: Rob Clark <robclark@gmail.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When booting with DT, there's a crash when omapfb is probed. This is
caused by the fact that omapdss+DT is not yet supported, and thus
omapdss is not probed at all. On the other hand, omapfb is always
probed. When omapfb tries to use omapdss, there's a NULL pointer
dereference crash. The same error should most likely happen with omapdrm
and omap_vout also.

To fix this, add an "initialized" state to omapdss. When omapdss has
been probed, it's marked as initialized. omapfb, omapdrm and omap_vout
check this state when they are probed to see that omapdss is actually
there.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The new SOLO6X10 driver needs the built-in console fonts, specifically
the VGA8x16 font and building it without console support results in
a link error error.

drivers/built-in.o: In function `solo_osd_print':
 :(.text+0x7d3424): undefined reference to `find_font'

This adds a dependency on the CONFIG_FONTS symbol and changes the
console code to always build the base driver even if there are
no specific fonts built-in.

Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cd2c7db (videomode: videomode_from_timing work) changed the name of
the function from videomode_from_timing() to videomode_from_timings().

commit 32ed6ef1 (videomode: create enum for videomode's display flags) changed
the 'data_flags' field in videomode structure to 'flags'

Adapt to these changes in order to fix the following errors:

drivers/video/mxsfb.c:761:3: error: too many arguments to function 'videomode_from_timing'
drivers/video/mxsfb.c:761:7: error: void value not ignored as it ought to be
drivers/video/mxsfb.c:768:9: error: 'struct videomode' has no member named 'data_flags'
drivers/video/mxsfb.c:770:9: error: 'struct videomode' has no member named 'data_flags'

Also, select VIDEOMODE_HELPER instead of OF_VIDEOMODE, as this one is
deprecated.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Acked-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The support for PB1100, PB1500, and PB1550 got merged into the code for
DB1000 and DB1550 code in v3.7. When that was done the three related
Kconfig symbols were dropped. But not all related Kconfig macros were
removed. Do so now.

Note that the PB1100 code in the Au1100 LCD driver is removed entirely
and not converted to use its current Kconfig macro. That is done because
the macros it uses (PB1100_G_CONTROL, PB1100_G_CONTROL_BL, and
PB1100_G_CONTROL_VDD) are never defined. Actually only one of these was
ever defined (PB1100_G_CONTROL) but that define was removed in v2.6.34.
So, as far as I can tell, this code could have never compiled.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Patchwork: http://patchwork.linux-mips.org/patch/5040/Acked-by: NJohn Crispin <blogic@openwrt.org>

Commit 11bd5933 ("fbdev/ps3fb: use vm_iomap_memory()") introduced
the following warning:

drivers/video/ps3fb.c: In function 'ps3fb_mmap':
drivers/video/ps3fb.c:712:2: warning: suggest parentheses around '+' inside '<<' [-Wparentheses]

Fix this by adding the parentheses.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

If the I2C adapter needed by the TFP410 device is not available yet,
return EPROBE_DEFER so that the device will get probed again.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for venc_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the VENC driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add proper error handling for hdmi_probe_pdata(). This will cause
EPROBE_DEFER to be properly passed upwards, causing the HDMI driver to be
probed again later if a resource was missing.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>