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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
OMAPDSS: Add Video DPLLs for DRA7x

VIDEO DPLLS are a lot like the OMAP5 DSI PLLs. The few differences are that
they need a control module register to ensure SCP register access, and they
are primarily used to drive DPI interfaces.

Signed-off-by: Archit Taneja <archit@ti.com>
OMAPDSS: DPI: Use VIDEO PLLs on DRA7x

Make the DPI driver use VIDEOx DPLLs for DRA74x. This involves adding an entry
in dpi_get_pll_data() for DRA74x, and calling a dss dpll function to configure
the DSS_PLL_CONTROL control module mux register to route the PLL output to the
desired overlay manager.

We currently fix the mapping of the PLLs with the LCD overlay managers. There
should ideally be a method by which the driver figures out a unused PLL, and
configure the mux registers pixel clock paths accordingly.

Signed-off-by: Archit Taneja <archit@ti.com>
OMAPDSS: DISPC: Choose the PLL type based on a dispc feature

We need to retrieve the pll_data handle to calculate the hsdivider clock rate.
The pll can be either a VIDEO PLL on DRA7x platforms, or a DSI PLL on other
platforms.

Retrieve the right pll_data handle using a dispc feat which choses the dss dpll
function to get pll_data for DRA7x, and the dsi pll function to get pll_data
for others.

Signed-off-by: Archit Taneja <archit@ti.com>
omapdss: dss/dispc/hdmi: Add compatible string for dra7

Add compatible strings for DSS and DISPC drivers. The HDMI IP is the same as
the one on OMAP5, add compatible string in the hdmi5 driver.

Signed-off-by: Archit Taneja <archit@ti.com>
omapdss: Add DRA74x version in dpi_get_channel()

Make sure dpi_get_channel() returns the desired overlay manager for the given
DPI instance in DRA74x.

DPI1 can be connected to any channel, but we just return LCD for now to keep
things simple.

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