The init/uninit port functions are used to set up the DPI and SDI outputs under
the dss platform device. A 'reg' property is used to determine the port number
of the output. This tells us whether the port is DPI or SDI for OMAP34xx DSS
revision. For other DSS revisions, we only have DPI outputs under the dss
platform device.

For multiple DPI output instances(introduced in DRA7xx DSS), we will use the
the port number to specify which DPI output instance is being inited.

The current functions work fine if there is only one DPI output instance in
DSS. For multiple DPI instances, it would get complicated to figure out whether
port number was used to specify whether the output is SDI, or another DPI
instance.

We create a list of port types supported for each DSS rev, with the index of the
port in the list specifying the port number of the output for that DSS revision.
This allows us to have a more generic way to init/uninit ports within DSS, and
also support multiple DPI ports.

We make the uninit_port functions iterative since we will have multiple DPI
ports to uninit in the future.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DPI and SDI ports are backed by only one parent DSS device. We don't have a
corresponding platform_device for ports under DSS. In order to support multiple
instances of DPI, we need to pass the driver data pointer through the DPI port's
private data ('data' member in device_node struct).

dpi_init_output/dpi_uninit_output are untouched and only used for non-DT case,
these are called when the DPI platform device probed/removed. These funcs will
be removed when non-DT mode is removed.

dpi_init_output_port/dpi_uninit_output_port are created and used for the DT
path, called when DSS inits/uninits it's ports. These new functions retrieve
the dpi_data pointer from 'port->data', and not from the platform device's
data(pdev->dev) like in the non-DT path.

We add some code in dss_uninit_ports() to pass a pointer to the DPI port in
dpi_uninit_port().
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Allocate driver data(dpi_data) for each DPI instance. It's allocated in
omap_dpi_probe() when DT isn't used, and in dpi_init_port() when DT is used.
The dpi_data struct instance is no longer global. In the case of DPI ops, it's
retrieved from dpi_get_data_from_dssdev(). 'dssdev' passed by the connected
encoder/panel driver is a pointer to the 'output' member in dpi_data, and thus
can be used to get the DPI instance's driver data. In the case of probe/ini_port
functions, it's set as DPI/DSS device's private data embedded in the
platform_device struct.

Having dpi_data as private data of the platform device will not work for
multiple DPI instances in the DT case. This is because there is no corresponding
platform_device for DPI or SDI, they exist only as ports under the parent DSS
platform_device in the DT case. The DPI port's private data('data' member in
device_node struct) will later be used to store dpi_data.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DPI related data is currently a static global struct parameter. It is accessed
directly by functions in the driver.

This method won't work if we want the driver to support multiple DPI instances.
Create struct dpi_data, and pass its pointer to functions which need to use it.

We still have a static instance defined for dpi_data, which is accessed by top
level DPI ops. This will be removed when the driver dynamically allocates
dpi_data for each DPI instance.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

PLL_SELFREQDCO bitfield is from bit 3 to 1, but the driver writes bits
from 4 to 1. The bit 4 is 'reserved', so this probably should not cause
any issues, but it's better to fix it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Preload register is dumped twice for video overlays and mflag register
is not dumped for GFX.

Fix the register dump.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The register offset for DISPC_OVL_MFLAG_THRESHOLD is wrong, fix it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

HDMI PLL's REGSD field is only set by the driver if the PLL's output
clock is over 1GHz. This is clearly an error, as REGSD should be set
always.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The PLL settings are committed by setting GO bit, which is then cleared
by the HW when the settings have been taken into use.

The current PLL code handles this wrong: instead of waiting for the bit
to be cleared, it waits for the bit to be set. Usually, the bit is
always set, as the CPU has just set it before. However, if the CPU takes
enough time between setting the GO bit and checking it, the HW may
already have cleared the bit and this leads to timeout error.

Fix the wait to check the bit properly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We should wait for any pending updates when an overlay manager is
about to be disabled, because the updates will never be finished if the
manager is disabled too early.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapdss drivers cannot handle devices being unbound while the devices
are part of a connected display pipeline. Module refcounts are used to
prevent unloading the modules, but one can still manually unbind the
devices via sysfs, causing crash.

Set suppress_bind_attrs to disable the bind/unbind support via sysfs.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Replace the use of nested functions where a normal function will suffice.

Nested functions are not liked by upstream kernel developers in general. Their
use breaks the use of clang as a compiler, and doesn't make the code any
better.

This code now works for both gcc and clang.
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Suggested-by: NArnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use c99 initializers for structures.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@decl@
identifier i1,fld;
type T;
field list[n] fs;
@@

struct i1 {
 fs
 T fld;
 ...};

@bad@
identifier decl.i1,i2;
expression e;
initializer list[decl.n] is;
@@

struct i1 i2 = { is,
+ .fld = e
- e
 ,...};
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

After v3.16-rc1, devices populated with of_platform_populate() should be
depopulated using of_platform_depopulate(). Failure to do so prevents
the devices from being populated again (e.g. when loading a module).

This patch fixes the problem for the OMAP DSI driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We no longer need the horrible driver internal videmode tables, which
were used to decide if a given videomode is a HDMI or DVI mode. So
remove all related code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of using hardcoded AVI infoframe, and a custom HDMI/DVI mode
selection based in internal videomode tables, add support to set the
infoframe and HDMI/DVI mode.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of using hardcoded AVI infoframe, and a custom HDMI/DVI mode
selection based in internal videomode tables, add support to set the
infoframe and HDMI/DVI mode.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add infoframe and hdmi_dvi_mode fields to 'struct hdmi_config' which
will be used in the following patches for OMAP4 and OMAP5 HDMI.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We now use the common AVI infoframe support, so the OMAP specific AVI
infoframe code can be removed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of using OMAP specific AVI infoframe structs, use the common one
from include/linux/hdmi.h.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of using OMAP specific AVI infoframe structs, use the common one
from include/linux/hdmi.h.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Select HDMI support to be able to use HDMI infoframe helpers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

OMAP HDMI driver has an 'enum hdmi_audio_sample_size', which conflicts
with the common include/linux/hdmi.h.

Change the name of the OMAP specific enum with '_omap" postfix.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dispc_mgr_timings_ok() is a bit confusing how it handles the return
value.

Change the function to just return immediately when a timing is deemed
not valid, making the code much easier to follow.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

OMAP2/3 does not support interlace for LCD out. OMAP4+ does, but is not
supported by the driver at the moment.

The driver still accepts interlaced mode for LCD out, causing broken
display output.

This patch makes dispc reject interlace for LCD out.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DISPC reg dump prints a few registers twice. Remove the extra prints.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

kmalloc can return null. Add a check to avoid potential null
pointer dereference error when the pointer is accessed later.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Move the panel/encoder driver compatible-string converter from
arch/arm/mach-omap2/display.c to omapdss driver. That is a more logical
place for it, as it's really an omapdss internal hack.

The code is rewritten to follow the video node graph, starting from
omapdss. This removes the need to have the device compatible-string
database.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

devm_ioremap_resource returns ERR_PTR on error, not NULL. Fix the
error checks in the driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Remove some unused defines from the HDMI driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Commit 59b3d38a missed cleaning up the
hdmi_wp.c file.

Clean up hdmi_wp.c the same way as the others.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use correct variable name for base address.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When omapdss writes to DISPC_POL_FREQ register, it always ORs the bits
with the current contents of the register, never clearing the old ones,
causing wrong signal polarity settings.

As we write all the bits in DISPC_POL_FREQ, we don't need to care about
the current contents of the register. So fix the issue by constructing
new register value from scratch.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that all the boards using OMAP HDMI are using DT boot, we can remove
the hacks for getting the ioresources with non-DT boot.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This adds a new driver to omapdss for OMAP5 HDMI. However, the new
driver uses common HDMI files which are shared with OMAP4 HDMI driver.

OMAP5 HDMI has a different HDMI core IP compared to OMAP4, but has very
similar PLL and PHY IPs which can be handled with common code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add a features struct to differentiate between the HDMI PLLs on OMAP4
and OMAP5. The OMAP5 PLL is more sensitive when it comes to locking.  We
need to ensure that the DCO freq isn't too low for lower pixel clocks.

Modify the PLL computation slightly to ensure the HDMI PLL locks for lower
frequencies. This will be later replaced by a more complex computation
which makes sure all the PLL constraints are met.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

OMAP5 HDMI PHY has some differences compared to OMAP4 HDMI PHY. This
patch creates a features struct which help the driver configure the PHY
based on what SoC it is.

Some of the features aren't currenlty used, but will come in use later.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The HDMI core IP on OMAP5 has a wider address range for registers. The offsets
for the later registers can't fit into the u16 type currently used for hdmi
register read and write functions. Use u32 for offsets instead.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

HDMI IRQ handling was moved into hdmi_phy.c when restructuring the HDMI
driver. While this worked fine, it's not correct.

The HDMI IRQ handling should be either in the hdmi_wp, or in the main
hdmi driver. This patch moves the handling to the main hdmi driver, as I
feel it's a more appropriate choice.

This move also requires changing the handling of the PHY power, as that
was partly handled in the IRQ handler. The PHY power is handled via the
WP module. An option would be to give HDMI PHY driver function pointers
that it could use to manage the PHY power, but as the PHY power is not
needed to access the PHY registers, the handling was also moved to the
main HDMI driver. This could be changed later if need be.

Note that there's slightly similar power issue with the PLL: the HDMI
PLLs power is also handled via the WP module. For now, the PLL power
handling is still done inside the PLL driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We'll soon add support for OMAP5 HDMI, which uses some of the same files
as OMAP4 HDMI does.

This patch adds a new config entry "OMAP2_DSS_HDMI_COMMON", which both
OMAP4 and OMAP5 HDMI config entries can select. OMAP2_DSS_HDMI_COMMON
will cause the common HDMI files to be compiled.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>