The clock source selection for the LCD outputs is too hardcoded at the
moment. For example, LCD3 is set to use PLL2_1, and PLL2 doesn't exist
on DRA72x SoCs.

There are quite many ways to configure the clocks, even using HDMI PLL
for LCD outputs, but enabling full configuration of the clocks is rather
tricky.

This patch improves the situation a bit by checking if the PLL about to
be used exists, and if not, tries another one.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The driver only uses even dividers for hsdiv when pclk >= 100MHz, as odd
dividers can create uneven duty cycle. However, while this holds true
for some dividers like DISPC's LCK and PCK dividers, it is not actually
true for hsdiv.

hsdiv always produces even duty cycle, so the constraint can be removed.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Use 'vm' to refer to a struct videomode instead of 'p', 't', 'timings' or
something else.

The code will be easier to follow if we use consistent names.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_video_timings can be replaced with the generic videomode in omapdrm
and the omap_video_timings can be removed.

This patch will replace the omap_video_timings with videomode.
With the change we no longer need the functions to convert to/from
videomode and drm_display_mode to omap_video_timings, these can be removed
as well.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omap_video_timings struct have the same members as struct videomode, but
their types are different. As first step change the types of the
omap_video_timings struct members to match their counterpart in
struct videomode to catch any type cast related issues.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

In preparation to move the stack to use the generic videmode struct for
display timing information rename the x_res member to hactive.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

All drivers to include the omapdrm/dss/omapdss.h header file. This header
includes the <video/omapdss.h>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>

Originally DSS only had DSI PLLs, and thus the DPI driver has functions
and variables that refer to DSI or DSI PLL. Now we support DSI, VIDEO
and HDMI PLLs, so it's time to remove the DSI references from the code.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Type A and B PLLs require a bit different calculations for the clock
rates. DPI driver supports only type A PLLs.

This patch adds support for the type B PLL.

Type B PLLs are simpler than type A, as type B can produce a good clock
for almost any rate. Thus we can just ask it to produce the pixel clock
and use one as LCK and PCK dividers.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Add a "_a" postfix to the type A PLL calc functions, to differentiate
them from the type B PLL calculations which we will add shortly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DPI driver uses a fixed clkout index, 0. This has worked fine as the
first clkout is usually used.

To generalize the code and to support additional clock sources, change
the code to use dss_pll_get_clkout_idx_for_src() to get the clkout
index.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We can clean up the DPI driver's clock source handling by using the
dss_clk_source instead of only a dss_pll pointer.

This will also make it possible to use additional clock sources, like
PLL1_3 or HDMI_PLL, which the code did not support earlier.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The code to set the clock muxes for DISPC's LCD clock inputs is very
confusing. Especially on DRA7, there's an additional clock muxing that
needs to be done, which at the moment is done in dpi.c using
dss_ctrl_pll_set_control_mux().

Clean this all up by:
- Using dss_clk_source instead of dss_pll_id, as dss_pll_id doesn't
  specify the clock source quite correctly.
- Splitting the dss_select_lcd_clk_source() up into DSS version specific
  helper functions.
- Using dss_ctrl_pll_set_control_mux() from the helper functions, so
  that dpi.c doesn't have to call it.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The names of the enum dss_clk_source's values are legacy names, only
correct for OMAP3 DSS. Rename the names to more generic ones.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

'enum omap_dss_clk_source' is internal to dss. Let's rename it to
'dss_clk_source' match our naming convention.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are removing the uses of 'struct omap_overlay_manager'. This patch
changes DPI driver to use 'omap_channel' instead.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DSS output drivers check 'dssdev->manager' in disconnect()
functions. This check is not needed as the manager must always be set if
the output device was connected. Remove the check.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Both dpi and sdi check for 'mgr != NULL' in check_timings. This check is
not necessary, as mgr must always be set before check_timings. Remove
the check.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are removing uses of 'struct omap_overlay_manager'. This patch
changes dss_mgr_disable() to accept 'enum omap_channel' instead of
'struct omap_overlay_manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are removing uses of 'struct omap_overlay_manager'. This patch
changes dss_mgr_enable() to accept 'enum omap_channel' instead of
'struct omap_overlay_manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are removing uses of 'struct omap_overlay_manager'. This patch
changes dss_mgr_set_lcd_config() to accept 'enum omap_channel' instead
of 'struct omap_overlay_manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are removing uses of 'struct omap_overlay_manager'. This patch
changes dss_mgr_set_timings() to accept 'enum omap_channel' instead of
'struct omap_overlay_manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are removing uses of 'struct omap_overlay_manager'. This patch
changes dss_mgr_disconnect() to accept 'enum omap_channel' instead of
'struct omap_overlay_manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are removing uses of 'struct omap_overlay_manager'. This patch
changes dss_mgr_connect() to accept 'enum omap_channel' instead of
'struct omap_overlay_manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Use 'out->dispc_channel_connected' to check if the device is connected
to an overlay manager or not, instead of using 'out->manager'.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DISPC requires the x resolution to be divisible by 8 when stall mode is
not used.

Add a check to the DPI driver to verify this.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Now that omapfb has its own copy of omapdss and display drivers, we can
move omapdss and display drivers which omapdrm uses to omapdrm's
directory.

We also need to change the main drm Makefile so that omapdrm directory
is always entered, because omapdss has a file that can't be built as a
module.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Acked-by: NRob Clark <robdclark@gmail.com>

All the output drivers check for 'out' being NULL, but it can never be
NULL. Remove the check.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

omapdss kernel module contains drivers for multiple devices, one for
each DSS submodule. The probing we have at the moment is a mess, and
doesn't give us proper deferred probing nor ensure that all the devices
are probed before omapfb/omapdrm start using omapdss.

This patch solves the mess by using the component system for DSS
submodules.

The changes to all DSS submodules (dispc, dpi, dsi, hdmi4/5, rfbi, sdi,
venc) are the same: probe & remove functions are changed to bind &
unbind, and new probe & remove functions are added which call
component_add/del.

The dss_core driver (dss.c) acts as a component master. Adding and
matching the components is simple: all dss device's child devices are
added as components.

However, we do have some dependencies between the drivers. The order in
which they should be probed is reflected by the list in core.c
(dss_output_drv_reg_funcs). The drivers are registered in that order,
which causes the components to be added in that order, which makes the
components to be bound in that order. This feels a bit fragile, and we
probably should improve the code to manage binds in random order.
However, for now, this works fine.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

The following patches will add component handling to omapdss, improving
the handling of deferred probing. However, at the moment we're using
quite a lot of __inits and __exits in the driver, which prevent normal
dynamic probing and removal.

This patch removes most of the uses of __init and __exit, so that we can
register drivers after module init, and so that we can unregister
drivers even if the module is built-in.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Add support for DRA7xx DPI output.

DRA7xx has three DPI outputs, each of which gets its input from a DISPC
channel. However, DRA72x has only one video PLL, and DRA74x has two
video PLLs. In both cases the video PLLs need to be shared between
multiple outputs. The driver doesn't handle this at the moment.

Also, DRA7xx requires configuring CONTROL module bits to route the clock
from the PLL to the used DISPC channel.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that we have the common DSS PLL support, change DSI to use it. This
results in quite a lot of changes, but almost all of them are trivial
name changes.

The functions to calculate and program the PLL settings can be removed
from dsi.c, as the common PLL API contains the same functionality.

We also need to create struct dss_pll_hw entries for PLL hardware
features for different OMAP platforms, instead of using the
dss_features.c as the old code does.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

When DPI uses the DSI PLL for pixel clock, the DPI code will call
dsi_runtime_get/put to keep the DSI block enabled. A much simpler way to
handle this is to do dsi_runtime_get/put in DSI's dsi_pll_init() and
dsi_pll_uninit(), thus removing the need for DSI to call the runtime PM
functions.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are creating a common DSS PLL code, so having fixed DSI specific
hsdiv fields in the clock information is not ok.

This patch changes the hsdiv fields to arrays, so that we can use all
the 4 possible hsdiv outputs (DSI only usees 2), and we have generic way
to access the hsdivs.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We are creating a common DSS PLL code, so rename 'clkin4ddr' field,
which is DSI specific name, to 'clkdco' which is a generic name.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

struct dsi_clock_info contains clkin field, which is the rate of the
PLL's input clock. This field is not needed, as it can be easily
retrieved by using the clk_get_rate().

This patch removes the clkin field.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DSS PLL has support to power on the PLL's highspeed clock output
and HSDIV output separately. In practice both need to powered on, as in
most OMAP's that's the only working configuration. We already do that in
dsi_pll_init(), by overriding the passed arguments so that both are
always powered.

Simplify the code by removing the support for choosing which outputs to
power on.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

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>

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: 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>