ARM: AM43xx: hwmod: add DSS hwmod data

Add DSS hwmod data for AM43xx.

Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: am43xx: add ti,set-rate-parent for disp_clk

disp_clk is a mux-clock, and to set the rate of the parent PLL, we need
ti,set-rate-parent flag.

Add the flag.

Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: am4372.dtsi: add DSS information

Add DT data for the display subsystem for AM4372. The DSS on AM4372 is
basically OMAP3's DSS, without DSI and VENC blocks.

Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: am437x-gp-evm: add LCD data

Add DT data for am437x-gp-evm's LCD panel.

Signed-off-by: Sathya Prakash M R <sathyap@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: am43x-epos-evm: add LCD data

Add DT data for am43x-epos-evm's LCD panel.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: OMAP2+: hwmod: OMAP5 DSS hwmod data

Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more
or less similar to omap4 hwmod data.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: omap5-clocks.dtsi: add dss iclk

Add missing DSS interface clock node.

Note: The TRM says DSS's interface clock is DSS_L3_GICLK, but it is not
clear to me from reading the TRM and looking at the
arch/arm/boot/dts/omap54xx-clocks.dtsi whether using 'l3_iclk_div' as
the parent for 'dss_l3_iclk' is the correct clock.

The clock is explicitly used only by the RFBI, and we don't have any
boards using the RFBI, so I have no means to test it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk

Add ti,set-rate-parent to dss_dss_clk so that the DSS driver can
set the rate.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: omap5.dtsi: add DSS nodes

Add OMAP5 DSS nodes to omap5.dtsi.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: omap5-uevm.dts: add tca6424a

omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: omap5-uevm.dts: add display nodes

omap5-uevm has a single HDMI output. Add the necessary display
information, including pinmuxing.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
ARM: dts: oma3-gta04: Add display support

This patch add support for lcd display on gta04 board. Display control
is connected to spi (used spi bitbang driver).

Signed-off-by: Marek Belisko <marek@goldelico.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Merge remote-tracking branch 'tomba/3.16/omap' into dss_multi_dpi
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 whether the node
is DPI or SDI for OMAP34xx DSS revision. For other DSS revisions, only DPI
output exists.

For multiple DPI output instances(introduced in DRA7xx DSS), we would use the
'reg' property in dts to specify the DPI output instance.

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
'reg' is 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 matching the reg id. This allows us to have a more generic way
to init/uninit ports within DSS, and support multiple DPI ports.

Also, 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>
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>
OMAPDSS: DPI: support multiple DPI instances

SoCs containing DSS until now had only one DPI instance. DRA7x has 3 DPI
instances.

In order to support multiple instances, we allocate a driver data
struct(dpi_data) for each instance. This is somewhat similar to how DSI driver
was changed to support multiple instances.

One difference is that there aren't platform devices for each DPI instance
when DT is used. In the DT case, we store the dpi_data pointer in the DPI port's
(of the type struct device_node) data pointer. In the non DT case, we still
have dummy platform devices, and the device's private data pointer is used to
store the DPI instance's dpi_data.

dpi_init_output/dpi_uninit_output are untouched and only used for non DT case,
dpi_init_output_port/dpi_uninit_output_port are used in the DT case, where DSS
configures the ports using dpi_init_port/dpi_uninit_port.

Signed-off-by: Archit Taneja <archit@ti.com>
OMAPDSS: DPI: make dpi_get_channel take DPI reg-id

To support multiple DPI instances, dpi_get_channel needs to take the DPI
instance's reg-id 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>
OMAPDSS: DSS: add reg-id param to dpi_select_source

Add an argument which describes which DPI instance we are referring to when
selecting it's overlay manager.

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