Add a 'port' parameter in dpi_select_source. The param tells the port
number of the DPI instance that we want to configure. We use this number
to select the overlay manager for that DPI instance.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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>

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>

Add omap5 entries to dispc's and dss's of_device_id tables.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add DSS features for AM43xx.
Signed-off-by: NSathya Prakash M R <sathyap@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The support for simpler port/endpoint binding was removed in the merged version
of omapdss DT. But dss_init_ports still tries to get to an endpoint even if no
port exists. Remove this as this doesn't work.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dss_uninit_ports is only called by __exit omap_dsshw_remove

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: linux-omap@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NFabian Frederick <fabf@skynet.be>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The drivers/video directory is a mess. It contains generic video related
files, directories for backlight, console, linux logo, lots of fbdev
device drivers, fbdev framework files.

Make some order into the chaos by creating drivers/video/fbdev
directory, and move all fbdev related files there.

No functionality is changed, although I guess it is possible that some
subtle Makefile build order related issue could be created by this
patch.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NRob Clark <robdclark@gmail.com>
Acked-by: NJingoo Han <jg1.han@samsung.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

"clk: divider: fix rate calculation for fractional rates" patch (and
similar for TI specific divider) fixes the clk-divider's rounding. This
patch updates the DSS driver to round the rates accordingly.

This fixes the DSS's warnings about clock rate mismatch, and also fixes
the wrong fclk rate being set.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: NChristoph Fritz <chf.fritz@googlemail.com>
Tested-by: NMarek Belisko <marek@goldelico.com>

dss_init_ports() is missing __init, so fix that.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add DT support for DSS. Contrary to the non-DT version, the DSS in DT
mode contains DPI and SDI outputs, which better reflects the hardware.
The non-DT code will be removed after all boards have been converted to
DT, so there's no need to change the non-DT code to act the same way.

The code for DPI and SDI needs to be refined later to make it possible
to add multiple DPI ports. For now, handling just a single DPI port is
enough for all the boards.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

The omapdss driver no longer uses get_context_loss_count call, so we can
remove it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

This patch adds support for SoCs that have a dedicated DSS PLL used for
DSS function clock.

If there is no dss parent clock defined, it is presumed that the
functionl clock rate can be set (almost) freely. The code calculates the
highest allowed fck rate, which when divided with some integer gives the
required pck.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We need the required pixel clock rate when calculating the dss fclk on
SoCs that have a dedicated DSS PLL.

This patch changes the code to pass the pck to the calc functions. The
pck rate is taken into use in the next patch.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The dss parent_clk_name currently points to a clock node which we use to
change the fclk rate. Now that we have CLK_SET_RATE_PARENT properly set,
we can set the rate directly to the fclk node.

However, we still need to calculate the possible clock rates. For this,
we need the rate of the parent of the current parent_clk.

To simplify the code, this patch changes the parent_clk_name to point to
the above mentioned parent, so that we can get the rate directly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Rename the variables related to DSS fclk's parent: "clk_name" and
"dpll4_m4_ck", to "parent_clk_name" and "parent_clk", which much better
tell what they mean.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Simplify dss_dump_clocks() so that it doesn't make any presumptions
about the DSS fclks nature.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Remove struct dss_clock_info, as it is not usable in a case where DSS
fclk comes from a dedicated PLL. Instead, just use the fclk rate in
place of dss_clock_info, as that is all that's needed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The driver considers OMAP2 DSS's functional clock as a fixed clock.
However, it can be changed, but the possible dividers are not continuous
which is why it was just handled as a fixed clock.

As a partial fix, this patch changes the code to handle the continous
part of the dividers, from 1 to 6. This let's us handle the OMAP2 fck
the same way as fcks on other OMAPs.
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>

DSS func clock is calculated with prate / div * m. However, the current
omapdss code calculates it with prate * m / div, which yields a slightly
different result when there's a remainder. For example, 432000000 / 14 *
2 = 61714284, but 432000000 * 2 / 14 = 61714285.

In addition to that, the clock framework wants the clock rate given with
clk_set_rate to be higher than the actual (truncated) end result. So, if
prate is 432000000, and div is 14, the real result is 30857142.8571...
We need to call clk_set_rate with 30857143, which gives us a clock of
30857142. That's why we need to use DIV_ROUND_UP() when calling
clk_set_rate.

This patch fixes the clock calculation.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use devm_clk_get() instead of clk_get() for dss, and for outputs hdmi
and venc. This reduces code and simplifies error handling.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that the old clock calculation code is no longer used, we can remove
it from the driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add new way to iterate over DSS clock divisors. dss_div_calc() provides
a generic way to go over all the divisors, within given clock range.
dss_div_calc() will call a callback function for each divider set,
making the function reusable for all use cases.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Dispc currently gets dispc's fck with clk_get() and uses clk_get_rate()
to get the rate for scaling calculations. This causes a problem with
common clock framework, as omapdss uses the dispc functions inside a
spinlock, and common clock framework uses a mutex in clk_get_rate().

Looking at the DSS clock tree, the above use of the dispc fck is not
quite correct. The DSS_FCLK from PRCM goes to DSS core block, which has
a mux to select the clock for DISPC from various options, so the current
use of dispc fck bypasses that. Fortunately we never change the dispc
clock mux for now.

To fix the issue with clk_get_rate(), this patch caches the dss clock
rate in dss.c when it is set. Dispc will then ask for the clock rate
from dss. While this is not very elegant, it does fix the issue, and
it's not totally wrong when considering that the dispc fck actually
comes via dss.

In the future we should probably look into common clock framework and
see if that could be used to represent the DSS clock tree properly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When enabling a hwmod, omap_hwmod refers to the register mentioned in the
hwmod struct's member 'prcm.omap4.context_offs' to see whether context was
lost or not. It increments the context lost count for the hwmod and then clears
the register.

All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs.
When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since
it's corresponding platform device is the parent platform device("omapdss_dss").
The dss_core hwmod updates it's context lost count correctly and clears the
register. When the hwmods corresponding to the children platform devices are
enabled, they see that the register is clear, and don't increment their context
lost count. Therefore, all the children platform devices never report a loss in
context.

The DISPC driver currently gets the context lost count for DSS power domain from
it's corresponding platform device instance("omapdss_dispc"). The DISPC platform
device is one of the child devices, and it's corresponding hwmod("dss_dispc")
doesn't report the context lost count correctly.

Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss"
platform device as it's input, move the function to dss.c so that it has access
to that platform device.
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Do not fail if dpll4_m4_ck is missing. The clock is not there on omap24xx,
so this should not be a hard error.

The patch retains the functionality before the commit 185bae10 (OMAPDSS:
DSS: Cleanup cpu_is_xxxx checks).
Signed-off-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.

However, there is no safe way for the output drivers to handle dispc
clock, as it's shared between the outputs. Thus, if, say, the DSI driver
sets up DSI PLL and configures both the dispc and lcd clock sources to
that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.

Thus the output drivers should really only be concerned about the lcd
clock, which is what the output drivers actually use. There's lot to do
to clean up the dss clock handling, but this patch takes one step
forward and removes the use of dss_select_dispc_clk_source() from the
output drivers.

After this patch, the output drivers only configure the lcd source
clock. On omap4+ the dispc src clock is never changed from the default
PRCM source. On omap3, where the dispc and lcd clocks are actually the
same, setting the lcd clock source sets the dispc clock source.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We don't currently set the dss fck when starting up. This is not a
problem, as we setup the fck later when configuring the pixel clocks. Or
this is how it was for omap2, for the rest of the omaps this may not be
so.

For DSI, HDMI and also for DPI when using DSI PLL, we don't need to
change the dss fck, and thus it may be left unconfigured. Usually the
dss fck is already setup fine by default, but we can't trust this.

This patch sets the dss fck to maximum at probe time.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dss_calc_clock_rates() was removed earlier as it was not used, but it is
needed for DSI PLL calculations, so this patch adds it back.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dss_generic_clk_source_names is missing the names for clocks from DSI2
PLL. Add them.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Commit 185bae10 ("OMAPDSS: DSS: Cleanup
cpu_is_xxxx checks") broke the DSS clocks configuration by erroneously
using the clock parameters applicable to all other OMAP34xx SoCs for the
OMAP363x. This went unnoticed probably because the cpu_is_omap34xx()
class check wasn't seen as matching the OMAP363x subclass.

Fix it by checking for the OMAP363x subclass before checking for the
OMAP34xx class.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The output drivers get the omapdss hw version from the platform data for
their respective output device. This doesn't work with DT, as there's no
platform data for them.

Add a new function, omapdss_get_version(), which returns the dss version
from the core device, which will have platform data on DT also. The
function is exported so that users of omapdss can also use it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When compiling on x86, we get compilation errors for dss.c and dispc.c:

drivers/video/omap2/dss/dispc.c:126:11: error: ‘SZ_4K’ undeclared here
(not in a function)

include <linux/sizes.h> to fix compilation.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

cpu_is_* calls are no longer used in omapdss, so the includes for
<plat/cpu.h> can be removed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use omapdss_version in dss.c to select the proper dss features.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The config option CONFIG_OMAP2_DSS_DEBUG_SUPPORT has been removed and replaced
with CONFIG_OMAP2_DSS_DEBUG and CONFIG_OMAP2_DSS_DEBUGFS. CONFIG_OMAP2_DSS_DEBUG
enables DEBUG flag and CONFIG_OMAP2_DSS_DEBUGFS enables creation of debugfs for
OMAPDSS. Both the config options are disabled by default and can be enabled
independently of one another as per convenience.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Reviewed-by: NSumit Semwal <sumit.semwal@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We can select the video source for DPI output as follows:

OMAP2/3: always LCD1
OMAP4: LCD2 or DIGIT
OMAP5: LCD1/LCD2/LCD3/DIGIT

This patch adds support to select the source, and makes dpi.c call the
function to set the source.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Anders <x0132446@ti.com>