OMAPDSS: DPI: Use DPI driver data

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 it's 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: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DPI: Allocate driver data

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: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DPI: Store dpi_data pointer in the DT port's data

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: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DSS: init dss ports cleanly

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: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DT: Get source endpoint by matching reg-id

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: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DPI: Add support for multiple instances

Register DPI outputs, and assign the port_num to them as specified by the
'reg' property in the DPI ports in DT.

To support multiple DPI instances, dpi_get_channel needs to take the DPI
instance's port number to get the corresponding channel. Make it take this
argument. We just pass 0 in the non-DT path, since we don't support multiple
instances in the non-DT case.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DSS: add a param to dpi_select_source which specifies it's port number

Add an 'id' 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: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: Add a PLL library

The DSI, HDMI and the VIDEO PLLs(on DRA7x) are very similar in terms of register
programming model and PLL parameter calculations.

An overlay manager's pixel clock can be driven by DSI PLL on OMAP3, DSI and HDMI
PLLs on OMAP4/5, and VIDEO and HDMI PLL on DRA7x.

This can make the DPI driver quite messy if we want to use different PLL API for
differnt SoCs.

We create a pll library, which provides a way to register to a pll instance,
which an output driver(like DSI, DPI, HDMI) can use.

Currently done only for DSI/HDMI type PLLs.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: Wait for DSI PLL hsdividers in respective driver itself

Waiting for the PLL HSdivider to become active in dss.c makes dss.c code depend
on the type of PLL being used. It also requires us to extract the DSI platform
device which the PLL is a part of.

Simplify this by making the callers to the clk source selection function wait
for the HSdividers to become active. With this change, the functions
dss_select_dispc/lcd/dsi_clk_source just take care of setting the DSS bits for
switching the clock source.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DSI: Use PLL library

Make the DSI driver use the pll helper library to create PLL instances, and
register to those. We keep the existing dsi pll calculation stuff so that DPI
can still use it. This will be removed when DPI also stops using it.

There are some hacks which make sure that both the old DSI PLL code path and
the new PLL library work together. This is needed because DPI still uses dsi
functions to configure the DSI PLL. The old DSI PLL code will be removed once
DPI also uses the PLL library.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
omapdss: DPI: Use PLL library

Make the DPI driver use the pll helper library to use DSI PLLs to compute the
PLL parameters for the desired pixel clock, and to configure and lock the PLL.

DPI in itself doesn't create PLL instances, it retrieves pll_data from the DSI
platform device. The driver still relies on the dsi functions to enable/disable
the DSI PLLs. This would later be removed when we add PLL ops to hide this from
the DPI driver.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DISPC: Use PLL library functions to get clock rates

Use PLL library pll_data handle, and pll_get_hsdiv_rate to get the high speed
divider clock rate.

The hsdivider index is assumed to be 0, it may be better to later have a
function which tells which hsdiv output goes back as a clock source to DISPC.

Remove BUG() statements as they don't do much here.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
omapdss: DSI: Remove unneeded DSI PLL code

The DSI and DPI drivers now use the PLL library to compute and configure PLL
parameters. Remove the redundant code path which was used previously by DSI
and DPI.

The dsi_clock_info struct now contains a pll_params struct, and additional
clock information specific to DSI(LP clock info).

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: FEATURES: Remove DSI PLL related features and params

DSI PLL related features, register fields, and parameter ranges are now managed
by the PLL library internally. Remove the redundant code.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: PLL: Add pll ops

PLL parameter computation and configuration is generally independent of the IP
in which the PLL belongs to. But power and clock control of the PLL is managed
by the DSI protocol engine, and HDMI wrapper in DSI and HDMI respectively.

In order to make the DPI driver completely independent of DSI, we need to add
ops in the PLL library which the DSI(or HDMI) driver populates. These ops will
performs the power, clock and regulator management related operations managed
by the parent IP.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DSI: Add PLL ops

Add DSI PLL library ops which can enable and disable the DSI PLLs. These ops
abstract away integration specific details between DSI IP and DSI PLL. These
details involve: enabling/disabling vdda_dsi regulator, configuring PLL power
states through DSI_CLK_CTRL, enabling/disabling SCP clock.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DPI: Simplify driver using PLL ops

The DPI driver currently relies on the DSI platform device to enable/disable the
PLL. With PLL ops, we now only require a pll_data pointer to configure the PLL.

This makes the DPI driver independent of DSI functions. dpi_get_dsidev() is
replaced by dpi_get_pll_data(). dpi_init_pll() is now independent of dsi
specific code. A few of the DSI functions used by DPI can now be made static.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
omapdss: Add DRA74xx as an OMAPDSS version

DRA74x has a slightly modified version of the DSS on OMAP5. DRA74x has 3
instances of DPI, no DSI or RFBI. It has 2 VIDEO PLLs, which are very similar
to the DSI PLLs.

Create a new OMAPDSS version for it. Use omap5 structs for initializations in
dss_features, dss, dispc, pll and hdmi helper libraries.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DSS: Add func for selection of overlay managers for DPI ports on DRA74x

We've had at most only one DPI instance in DSS. With the DRA7x family, we will
have 3 DPI instances.

Create a function dpi_select_source op for dra7x which selects the source for
DPI1 instance, and makes sure DPI2 and DPI3 are only linked with LCD2 and LCD3
managers respectively. This also calls for a new dss feat struct DRA74x.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: Add functions for external control of PLL

Add functions which configure the control module register
CTRL_CORE_DSS_PLL_CONTROL found in DRA7x SoCs. This register configures whether
the PLL registers are accessed internally by DSS, or externally using OCP2SCP
interface. They also configure muxes which route the PLL output to a particular
LCD overlay manager within DSS.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>