The current way how omapdss handles system suspend and resume is that
omapdss device (a platform device, which is not part of the device
hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses
the suspend and resume callbacks from platform_driver to handle system
suspend. It does this by disabling all enabled panels on suspend, and
resuming the previously disabled panels on resume.

This presents a few problems.

One is that as omapdss device is not related to the panel devices or the
DSS HW devices, there's no ordering in the suspend process. This means
that suspend could be first ran for DSS HW devices and panels, and only
then for omapdss device. Currently this is not a problem, as DSS HW
devices and panels do not handle suspend.

Another, more pressing problem, is that when suspending or resuming, the
runtime PM functions return -EACCES as runtime PM is disabled during
system suspend. This causes the driver to print warnings, and operations
to fail as they think that they failed to bring up the HW.

This patch changes the omapdss suspend handling to use PM notifiers,
which are called before suspend and after resume. This way we have a
normally functioning system when we are suspending and resuming the
panels.

This patch, I believe, creates a problem that somebody could enable or
disable a panel between PM_SUSPEND_PREPARE and the system suspend, and
similarly the other way around in resume. I choose to ignore the problem
for now, as it sounds rather unlikely, and if it happens, it's not
fatal.

In the long run the system suspend handling of omapdss and panels should
be thought out properly. The current approach feels rather hacky.
Perhaps the panel drivers should handle system suspend, or the users of
omapdss (omapfb, omapdrm) should handle system suspend.

Note that after this patch we could probably revert
0eaf9f52 (OMAPDSS: use sync versions of
pm_runtime_put). But as I said, this patch may be temporary, so let's
leave the sync version still in place.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NJassi Brar <jaswinder.singh@linaro.org>
Tested-by: NJassi Brar <jaswinder.singh@linaro.org>
Tested-by: NJoe Woodward <jw@terrafix.co.uk>
Signed-off-by: NArchit Taneja <archit@ti.com>
[fts: fixed 2 brace coding style issues]
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

If CONFIG_DEBUG_FS or CONFIG_OMAP2_DSS_DEBUG_SUPPORT is disabled, the
build fails:

drivers/video/omap2/dss/core.c:197:50: error: static declaration of
'dss_debugfs_create_file' follows non-static declaration
drivers/video/omap2/dss/dss.h:166:5: note: previous declaration of
'dss_debugfs_create_file' was here

This patch fixes the dummy dss_debugfs_create_file() so that the driver
builds.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Currently the higher level omapdss platform driver gets the list of
displays in its platform data, and uses that list to create the
omap_dss_device for each display.

With DT, the logical way to do the above is to list the displays under
each individual output, i.e. we'd have "dpi" node, under which we would
have the display that uses DPI. In other words, each output driver
handles the displays that use that particular output.

To make the current code ready for DT, this patch modifies the output
drivers so that each of them creates the display devices which use that
output. However, instead of changing the platform data to suit this
method, each output driver is passed the full list of displays, and the
drivers pick the displays that are meant for them. This allows us to
keep the old platform data, and thus we avoid the need to change the
board files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have a two ways to set a "default panel device" for dss, to
which the overlays are connected when the omapdss driver is loaded:

- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata

The current code handles this in a bit too complex way by using both of
the above methods during runtime. However, with DT we don't have pdata
anymore, so the code handling the second case won't work anymore. The
current code has also the problem that it modifies the platform_data.

This patch simplifies the code a bit by using the pointer method only
inside the probe function, and stores the name of the panel device. This
way we only need to handle the textual format during operation and also
avoid modifying the platform_data.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that we are using platform_driver_probe() we can add __inits and
__exits all around.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.

This patch modifies the dpi.c and sdi.c to create drivers for the
platform devices.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The platform devices for omapdss, dss and dispc drivers are always
present, so we can use platform_driver_probe instead of
platform_driver_register.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:

- Remove struct omap_display_platform_data. It was used just as a
  wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
  dss hwmods do not need the platform data. This should also work better
  for DT, as we can create omapdss device programmatically in generic omap
  boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
  that the dss hwmod drivers can call.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Most of the DSS clocks have restrictions on their frequency based on the
OPP in use. For example, maximum frequency for a clock may be 180MHz in
OPP100, but 90MHz in OPP50. This means that when a high enough pixel
clock or function clock is required, we need to use OPP100.

However, there's currently no way in the PM framework to make that kind
of request. The closest we get is to ask for very high bus throughput
from the PM framework, which should effectively force OPP100.

This patch is a simple version for handling the problem. Instead of
asking for OPP100 only when needed, this patch asks for OPP100 whenever
DSS is active. This obviously is not an optimal solution for cases with
small displays where OPP50 would work just fine. However, a proper
solution is a complex one, and this patch is a short term solution for
the problem.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: NKevin Hilman <khilman@ti.com>

We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.

There doesn't seem to be any reason for that, and additionally the
soon-to-be-merged patch "ARM: OMAP: omap_device: remove
omap_device_parent" will break omapdss initialization with the current
registration model.

This patch changes the registration for all drivers to happen at the
same place, in the init of the module.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: NFlorian Tobias Schandinat <FlorianSchandinat@gmx.de>

module_param(bool) used to counter-intuitively take an int.  In
fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
trick.

It's time to remove the int/unsigned int option.  For this version
it'll simply give a warning, but it'll break next kernel version.
Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Create a new file, apply.c, and move code about handling the
apply-mechanism and configuration of the managers and overlays from
manager.c to apply.c.

Not all related code is moved in this patch, but only the core
apply/configure functions. The later patches move rest of the code from
overlay.c and manager.c, adding necessary locking at the same time.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add support to dump the HDMI wrapper, core, PLL and PHY registers
through debugfs.
Signed-off-by: NMythri P K <mythripk@ti.com>
[tomi.valkeinen@ti.com: updated the description]
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DSS enables core clocks for the duration of initialization to avoid
unnecessary context saves and restores.

With PM runtime the clocks cannot be handled in this way, outside the
dss module drivers. Thus we need to remove the optimization.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The initialization order of the DSS modules is important when pm_runtime
support is implemented. Currently RFBI is initialized before DISPC,
which will cause problems with pm_runtime as RFBI uses DISPC.

The same goes for uninitialization order, and dss_uninit needs to be
called last, and dispc_uninit just before that.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol
engine and DISPC Functional clock. Do the following:

- Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the
  dsi module number as an argument.
- Create debugfs files for dsi2, split the corresponding debugfs functions.
- Allow DPI to use these new clock sources.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_dss_register_device and omap_dss_unregister_device can only be
called from core.c, so we can make it static.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

arch/arm/plat-omap/include/plat/display.h is an include for the OMAP DSS
driver. A more logical place for it is in include/video.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

calling the platform registration of HDMI driver from core
during initialization.
Signed-off-by: NMythri P K <mythripk@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

cpu_is_omapxxx() was used previously to select the supported interfaces.
Now that the interfaces are platform devices, we no longer need to do
the check when registering the driver. Thus we can just remove the
checks.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DPI and SDI are different from the other interfaces as they are not
hwmods and there is not platform driver for them. They could be said to
be a part of DSS or DISPC modules, although it's not a clear definition.

This patch moves DPI and SDI initialization into DSS platform driver,
making the code more consistent: omap_dss_probe() only initializes
platform drivers now.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dpi_init() does not use the pdev argument for anything. Remove it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

FB_OMAP_BOOTLOADER_INIT does not work, and it was only partially
implemented for SDI.

This patch removes support for FB_OMAP_BOOTLOADER_INIT to clean up the
code and to remove any assumptions that FB_OMAP_BOOTLOADER_INIT would
work.

Proper implementation is much more complex, requiring early boot time
register and clock handling to keep the DSS running.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

MODULE_PARM_DESC() takes the name of the actual module parameter, not the
name of the variable, as input. Fix the module parameter description for
def_disp.
Signed-off-by: NJani Nikula <jani@nikula.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

enum dss_clock structure is replaced with generic names that
could be used across OMAP2420, 2430, 3xxx, 44xx platforms.
Signed-off-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NArchit Taneja <archit@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>

Calls init functions of dss_features during dss_probe, and the following
features are made omapxxxx independent:
  - number of managers, overlays
  - supported color modes for each overlay
  - supported displays for each manager
  - global aplha, and restriction of global alpha for video1 pipeline
  - The register field ranges : FIRHINC, FIRVINC, FIFOHIGHTHRESHOLD
    FIFOLOWTHRESHOLD and FIFOSIZE
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Perform graceful cleanup on errors instead of just bailing out.
Signed-off-by: NJani Nikula <ext-jani.1.nikula@nokia.com>
Tested-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Move a number of #ifdefs from code into dss.h and elsewhere, and
conditionally define no-op static inline functions, cleaning up the
code. This style is according to Documentation/SubmittingPatches.
Signed-off-by: NJani Nikula <ext-jani.1.nikula@nokia.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

This allows us to disable DPI on systems that do not have it
Signed-off-by: NRoger Quadros <roger.quadros@nokia.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>

Move get_recommended_bpp() from omap_dss_device to omap_dss_driver.

This is part of a larger patch-set, which moves the control from omapdss
driver to the display driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>