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>

In omapdss_of_find_source_for_first_ep, we retrieve a source endpoint's DT node,
and then see what omapdss output has the matching device_node pointer in
omap_dss_find_output_by_node.

For all DPI and SDI outputs, the device_node pointer is set as the parent's DSS
device_node pointer. If the source is one of these outputs, the above method
won't work.

To get the correct output for ports within DSS(and in other cases in the future,
where multiple ports might be under one device), we require additional
information which is exclusive to the output port.

We create a new field in omap_dss_device called 'port_num', this provides port
number of the output port corresponding to this device. When searching for the
source endpoint in DT, we extract the 'reg' property from the port corresponding
to the endpoint source. From the list of registered outputs, we pick out that
output which has both dev->of_node and port_num matching with the device_node
pointer and 'reg' of the source endpoint node from DT.

For encoder blocks(the ones which have both an input and output port), we need
to set the port_num as the 'reg' property for the output port as defined in the
DT bindings. We set port_num to 1 in the tfp410 and tpd12s015 encoder drivers.
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>

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>

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>

Avoid colision with regmap's struct reg_field definition by renaming
omapdss's struct reg_field to dispc_reg_field, and moving it inside
dispc.c as that's the only place it is used.
Signed-off-by: NJyri Sarha <jsarha@ti.com>
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>

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>

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>

Replace the ti_hdmi_4xxx* notation for OMAP4 HDMI driver with hdmi4. Rename
the hdmi.c encoder driver to hdmi4.c. Rename ti_hdmi.h to hdmi.h
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

With all the old panels removed and all the old panel model APIs removed
from the DSS encoders, we can now remove the custom omapdss-bus which
was used in the old panel model.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.

This patch removes the code from the VENC driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

Now that the old panel drivers have been removed, we can remove the
old-model API and related code from the DSS encoder drivers.

This patch removes the code from the HDMI driver.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

Regulator handling for DPI and SDI is currently handled in the core.c,
using the 'virtual' omapdss platform device. Nowadays we have proper
devices for both DPI and SDI, and so we can handle the regulators inside
the respective drivers.

This patch moves the regulator handling for DPI into dpi.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

Regulator handling for DPI and SDI is currently handled in the core.c,
using the 'virtual' omapdss platform device. Nowadays we have proper
devices for both DPI and SDI, and so we can handle the regulators inside
the respective drivers.

This patch moves the regulator handling for SDI into sdi.c.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: NArchit Taneja <archit@ti.com>

In order to allow multiple display block in a video pipeline, we need to
give the drivers way to register themselves. For now we have
the omapdss_register_display() which is used to register panels, and
dss_register_output() which is used to register DSS encoders.

This patch makes dss_register_output() public (with the name of
omapdss_register_output), which can be used to register also external
encoders. The distinction between register_output and register_display
is that a "display" is an entity at the end of the videopipeline, and
"output" is something inside the pipeline.

The registration and naming will be made saner in the future, but the
current names and functions are kept to minimize changes during the dss
device model transition.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DISPC needs to know the clock rate for DIGIT (i.e. TV) channel, and this
clock is provided by either VENC or HDMI modules. Currently DISPC will
call a function in VENC/HDMI, asking what the clock rate is. This means
we have a fixed dependency from DISPC to both VENC and HDMI.

To have a more generic approach, and in particular to allow adding OMAP5
HDMI driver, we need to remove this dependency. This patch makes
VENC/HDMI inform DISPC when the their clock changes, thus reversing the
dependency and removing the issue.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have omap_dss_device, which represents an external display
device, sometimes an external encoder, sometimes a panel. Then we have
omap_dss_output, which represents DSS's output encoder.

In the future with new display device model, we construct a video
pipeline from the display blocks. To accomplish this, all the blocks
need to be presented by the same entity.

Thus, this patch combines omap_dss_output into omap_dss_device. Some of
the fields in omap_dss_output are already found in omap_dss_device, but
some are not. This means we'll have DSS output specific fields in
omap_dss_device, which is not very nice. However, it is easier to just
keep those output specific fields there for now, and after transition to
new display device model is made, they can be cleaned up easier than
could be done now.
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>

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>

Commit 100c8262 (OMAPDSS: DPI: use new
clock calculation code) breaks dpi.c compilation if DSI is not enabled
in the kernel configuration.

Fix compilation by adding dummy inline functions for the ones that dpi.c
references. The functions will never be called, as dpi.c knows that
there is no DSI device available.
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 DSI PLL and HSDIV clock divisors.
dsi_pll_calc() and dss_hsdiv_calc() provide a generic way to go over
all the divisors, within given clock range. The functions 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>

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>

Add new way to iterate over DISPC clock divisors. dispc_div_calc()
provides a generic way to go over all the divisors, within given pixel
clock range. dispc_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>

Export DISPC functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Export dss_mgr_ops related functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Move creation of the sysfs files for displays to the compat layer.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

This patch adds a new function, dispc_ovl_check(), which can be used to
verify scaling configuration for an overlay. The function gets both the
overlay and overlay manager as parameters, so that the caller does not
need to configure the hardware before using this function.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The whole dispc irq handling system we currently have is only needed for
compat layer, and thus can be moved from dispc.c to the compat layer.

This is quite straigtforward, but we need to add new dispc functions to
request and free the actual hardware irq: dispc_request_irq() and
dispc_free_irq().
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

dispc_mgr_enable_sync and dispc_mgr_disable_sync are only used with the
compat mode. Non-compat will use the simpler enable and disable
functions.

This patch moves the synchronous enable/disable code to the compat
layer. A new file is created, dispc-compat.c, which contains low level
dispc compat code (versus apply.c, which contains slightly higher level
compat code).
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Some of the output drivers need to handle FRAMEDONE interrupt from
DISPC. This creates a direct dependency to dispc code, and we need to
avoid this to make the compat code to work.

Instead of the output drivers registering for dispc interrupts, we
create new mgr-ops that are used to register a framedone handler. The
code implementing the mgr-ops is responsible for calling the handler
when DISPC FRAMEDONE interrupt happens. The compat layer is improved
accordingly to do the call to the framedone handler.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The output drivers need some operations from the overlay managers, like
enable and set_timings. These will affect the dispc registers, and need
to be synchronized with the composition-side changes with overlays and
overlay managers.

We want to handle these calls in the apply.c in the compatibility mode,
but when in non-compat mode, the calls need to be handled by some other
component (e.g. omapdrm).

To make this possible, this patch creates a set of function pointers in
a dss_mgr_ops struct, that is used to redirect the calls into the
correct destination.

The non-compat users can install their mgr ops with
dss_install_mgr_ops() function.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Most of the functions that are assigned to the fields in ovl struct are
in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Most of the functions that are assigned to the fields in ovl-mgr struct
are in apply.c. By moving the function pointer setup into apply.c we can
make these functions static.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>