Add DT support to VENC.
In contrast to non-DT version, the DT version gets the invert-polarity
and connector type via venc's endpoint, not from the connector.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add DT support to HDMI driver. The only thing needed for DT support here
is the of_match_table.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add DT support to DISPC. Only thing needed here is the of_match_table.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
The regulator names used for DSS components are somewhat ugly for DT
use. As we're just adding DT support, it's simple to change the
regulator names.
This patch makes the DSS driver get the regulators with somewhat cleaner
names when bootin with DT. For example, this allows us to define HDMI's
VDDA regulator in the DT data as:
vdda-supply = <...>;
instead of
vdda_hdmi_dac-supply = <...>;
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add helpers to get ports and endpoints from DT data.
These helpers parse v4l2 style ports and endpoints, but compared to the
v4l2 helpers, these allow iterating ports and endpoints separately.
This is a temporary solution until we get generic code to parse the
ports and endpoints.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for "display0" DT alias
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
We currently create a "displayX" style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that "display0" is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Add support to get the label (i.e. a "nickname") for a display from the
DT data. If there is no label defined, use the display's alias (e.g.
'display0') as a name.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
As there is no common panel framework in the kernel, we have OMAP
specific panel drivers. However, the DT data should be generic. This
brings the issue that some other platform could use the same panels, and
would need to create a driver with the same 'compatible' string as the
OMAP driver.
In the long run, we have to get a common panel framework. For the time
being, this patch solves the issue:
At early boot time, we go through the DT nodes looking for the panels
the kernel supports for OMAP. For each found node, the 'compatible'
string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
"omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
at the beginning of their compatible field.
This allows us to have generic DT data, but OMAP specific display
drivers.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The OMAP display architecture requires a bunch of platform devices which
are not created via .dts (for now). We also need to pass a few function
pointers and the DSS hardware version from the arch code to omapdss
driver.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which handles those tasks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reviewed-by: Archit Taneja <archit@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Add DT data for OMAP4 Pandaboard. The board has the following displays:
dvi: uses TFP410 encoder to convert DPI to DVI
hdmi: OMAP HDMI output with TPD12S015 ESD/level shifter
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Add DT data for OMAP4 display subsystem, which contains the following
blocks:
dss - the wrapper/glue for the display modules
dispc - display controller
dsi - MIPI DSI encoder (two independent modules)
rfbi - MIPI DBI encoder
venc - analog TV encoder
hdmi - HDMI encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Add DT data for OMAP3 display subsystem, which contains the following
blocks:
dss - the wrapper/glue for the display modules
dispc - display controller
dsi - MIPI DSI encoder
rfbi - MIPI DBI encoder
venc - analog TV encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Add DT data for OMAP2 display subsystem, which contains the following
blocks:
dss - the wrapper/glue for the display modules
dispc - display controller
rfbi - MIPI DBI encoder
venc - analog TV encoder
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Set 'ti,set-rate-parent' property for clocks in the dpll4_m4 clock
path, which is used for DSS functional clock. This fixes DSS driver's
clock rate configuration, which needs the rate to be propagated properly
to the divider node (dpll4_m4_ck).
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Marek Belisko <marek@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
We need to use set-rate-parent for dpll4_m4 clock path, so use the
ti,fixed-factor-clock version which supports set-rate-parent property.
The set-rate-parent flag itself is set in the following patch, this one
just changes the clock driver to ti,fixed-factor-clock without any other
changes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Marek Belisko <marek@goldelico.com>
Acked-by: Tony Lindgren <tony@atomide.com>
OMAP3630 DPLL4 is different than on OMAP3430, in that it doesn't have
the x2 multiplier for its outputs. This is not currently reflected in
the clock DT data.
Fix the issue by setting the clock multiplier to 1 (instead of 2) for the
DPLL4 output clocks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Marek Belisko <marek@goldelico.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The DSS fclk and iclk handles are named differently on OMAP3430 ES1 than
on later OMAP revisions. The ES1 has handles 'dss1_alwon_fck_3430es1'
and 'dss_ick_3430es1', whereas later revisions have similar names but
ending with 'es2'.
This means we don't have one clock handle to which we could refer to
when defining the DSS clocks.
However, as the namespaces are separate for ES1 and ES2+ OMAPs, we can
just rename the handles to 'dss1_alwon_fck' and 'dss_ick' for both ES1
and ES2+, removing the issue.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Christoph Fritz <chf.fritz@googlemail.com>
Tested-by: Marek Belisko <marek@goldelico.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The IOMMU DT nodes have been added for the DSP and IPU
subsystems. The MMUs in OMAP5 are identical to those in
OMAP4, including the bus error back capability on IPU.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Add the IOMMU nodes for the DSP and IPU subsystems. The MMU
within the IPU sub-system also supports a bus error back
capability, not available on the DSP MMU.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
[s-anna@ti.com: IPU bus error back addition]
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Tomi Valkeinen
Denis Carikli
Stefan Roese
Yegor Yefremov
Suman Anna
Florian Vaussard