The omap_hdmi private data structure is currently stored as a global
variable. While no platform with multiple HDMI4 encoders currently
exists nor is planned, this doesn't comply with the kernel device model
and should thus be fixed.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

To simplify implementation of debugfs seq_file show handlers, the driver
passes the pointer to the show function through the debugfs_create_file
data pointer. This prevents using the pointer to pass driver private
data to the show handler, and requires all handlers to use global
variables to access private data.

To prepare for the removal of global private data in the driver, rework
the debugfs infrastructure to allow passing a private data pointer to
show handlers.

The price to pay is explicit removal of debugfs files to free the
internally allocated memory. This is desirable anyway as debugfs entries
should be removed when a component driver is unbound, otherwise crashes
will occur due to access to freed memory when the components will be
dynamically allocated instead of stored in global variables.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

This removes the need to access the global DSS private data in those
functions (both for the current accesses and the future ones that will
be introduced when allocating the DSS device dynamically).
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

To prepare for the removal of the global variable storing DSS private
data, pass its pointer to the dss_runtime_{get,put}() functions.

As this requires getting hold of the dss_device structure in the
callers, we add a new dss_get_device() function to retrieve it. The
function currently returns a pointer to the global data structure, and
will later be updated to get the pointer from device driver data when
the DSS private structure will be allocated dynamically.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>

Extend the hdmi_core_data struct with the additional fields needed
for CEC.

Also fix a simple typo in a comment.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The OMAP4 and OMAP5 HDMI PHYs have different properties that require
specific handling in the HDMI PHY driver. This needs knowledge of the
PHY version, which is currently inferred from the DSS version. As part
of the effort to remove usage of the DSS version, use the HDMI
controller version instead.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The HDMI wrapper code only needs to differentiate between major OMAP
revisions, which can be obtained from the HDMI transmitter compatible
string. Replace the OMAP SoC model checks to prepare for removal of the
OMAP SoC version platform data.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The FEAT_HDMI_* features are specific to the HDMI4, move them from the
omap_dss_features structure to the hdmi4 driver.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

PHY features are stored in a global variable, while they should be
properties of the PHY object. As existing OMAP platforms have a single
HDMI PHY this doesn't cause any issue, but doesn't follow the driver
model.

Move the PHY features to the HDMI PHY data structure to follow the
driver model and pave the road for multiple HDMI PHYs support.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.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: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi 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: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi 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: Peter Ujfalusi <peter.ujfalusi@ti.com>

Clean up the header files regarding to hdmi audio so the omap-hdmi-audio.h
file will only need to include the platform_data/omapdss.h file.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
CC: Mark Brown <broonie@kernel.org>
CC: Jyri Sarha <jsarha@ti.com>
CC: Liam Girdwood <liam.r.girdwood@linux.intel.com>

Move hdmi_pll_compute(), used to calculate the config for HDMI PLL, from
hdmi_pll.c to pll.c, with the name of dss_pll_calc_b(), to make it
available to non-HDMI users.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

To make it possible to use HDMI PLL for other video outputs than HDMI,
the HDMI PLL code needs to do runtime_get/put for the HDMI IP, so that
the IP (include the PLL) is enabled.

To do that we also need to store the HDMI pdev in the hdmi_pll_data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Dave Airlie <airlied@gmail.com>
Acked-by: Rob Clark <robdclark@gmail.com>

Reconfigure and restart audio when display is enabled, if audio
playback was active before. This is needed in a situation when an
audio+video stream application opens the audio stream before the
video. When video stream is opened the display mode may change and
that aborts audio playback, because the display is momentarily
turned off.

The audio configuration is stored when it is successfully applied and
a boolean is set when the audio playback is started and unset when
stopped. This data is used to reconfigure the audio when display is
re-enabled. The audio playback is aborted if the reconfiguration fails.

A new spin lock is introduced in order to protect state variables
related to audio playback status. This is needed for the transition
from display enabled state (when audio start/stop commands can be
written to HW) to display disabled state (when audio start/stop
commands update only the hdmi.audio_playing variable) to always
serialize correctly with the start/stop audio commands. The already
existing mutex can not be used, because the audio start and stop
commands are executed in atomic context.

For example: when display is turned back on we take the spinlock and
we can be sure that the audio start/stop status will not change while
we update the HW according to hdmi.audio_playing state and set
hdmi.display_enabled to true. After releasing the lock
hdmi.display_enabled is true and all audio_start and audio_stop
commands write their stuff directly to HW.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Enabling idle mode during audio playback causes the glitches on OMAP5
HDMI. The TRM also suggests to use no-idle for HDMI audio playback.

This patch sets HDMI idle mode to no-idle for the duration of the
playback, and restores it back to original value afterwards.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Make hdmi_mode_has_audio() more user friedly by taking hdmi_config as
parameter.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Adds display_enabled flag and audio_abort_cb callback to struct hdmi.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

This is used to store omap-hdmi-audio pdev for unregistering it.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Unify the private anonymous struct in hdmi4.c and hdmi5.c, name it as
struct omap_hdmi, and make it public in hdmi.h.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The audio dma port is found in the hdmi_wp physical address space.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

It does not waste too many bytes to compile all audio related core
functions always in with HDMI support. It should help readability and
in keeping the audio code in working shape. Leave the options just for
disabling and enabling the functionality in hdmi[45].c.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The OMAP5 HDMI audio implementation needs HDMI_AUDIO_LAYOUT_6CH in
hdmi_core_audio_layout enum. I found the correct value from ti-linux
3.8 tree.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

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

The function to program the PLL settings can be removed from hdmi_pll.c,
as the common PLL API contains the same functionality.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

At the moment we have one function, hdmi_pll_enable, which enables the
PLL and writes the PLL configuration to registers.

To make the HDMI PLL ahere to the DSS PLL API, split the hdmi_pll_enable
into two parts: hdmi_pll_enable which enables the PLL HW, and
hdmi_pll_set_config which writes the config.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

HDMI PLL code needs the pointer to the WP block so that it can manage
its power. Currently this is passed as a function parameter to
hdmi_pll_enable and hdmi_pll_disable. To make the PLL function adhere to
the DSS PLL API, we need to remove the WP parameter.

This patch stores the WP pointer to hdmi_pll_data in hdmi_pll_init, so
that it's available when needed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The code calculating HDMI PLL parameters has always been very confusing.
Now that we are implementing a common PLL library for the DSS, it's
important that the PLL code is understandable.

This patch rewrites the calculation code, and removes a few hacks that
were used there.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Only OMAP5+ has REFSEL field, but at the moment it's set also on OMAP4.

Fix this by adding a "has_refsel" field, and setting the REFSEL based on
that.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

We no longer need the horrible driver internal videmode tables, which
were used to decide if a given videomode is a HDMI or DVI mode. So
remove all related code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Add infoframe and hdmi_dvi_mode fields to 'struct hdmi_config' which
will be used in the following patches for OMAP4 and OMAP5 HDMI.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

We now use the common AVI infoframe support, so the OMAP specific AVI
infoframe code can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Instead of using OMAP specific AVI infoframe structs, use the common one
from include/linux/hdmi.h.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAP HDMI driver has an 'enum hdmi_audio_sample_size', which conflicts
with the common include/linux/hdmi.h.

Change the name of the OMAP specific enum with '_omap" postfix.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

This adds a new driver to omapdss for OMAP5 HDMI. However, the new
driver uses common HDMI files which are shared with OMAP4 HDMI driver.

OMAP5 HDMI has a different HDMI core IP compared to OMAP4, but has very
similar PLL and PHY IPs which can be handled with common code.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

OMAP5 HDMI PHY has some differences compared to OMAP4 HDMI PHY. This
patch creates a features struct which help the driver configure the PHY
based on what SoC it is.

Some of the features aren't currenlty used, but will come in use later.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

The HDMI core IP on OMAP5 has a wider address range for registers. The offsets
for the later registers can't fit into the u16 type currently used for hdmi
register read and write functions. Use u32 for offsets instead.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

HDMI IRQ handling was moved into hdmi_phy.c when restructuring the HDMI
driver. While this worked fine, it's not correct.

The HDMI IRQ handling should be either in the hdmi_wp, or in the main
hdmi driver. This patch moves the handling to the main hdmi driver, as I
feel it's a more appropriate choice.

This move also requires changing the handling of the PHY power, as that
was partly handled in the IRQ handler. The PHY power is handled via the
WP module. An option would be to give HDMI PHY driver function pointers
that it could use to manage the PHY power, but as the PHY power is not
needed to access the PHY registers, the handling was also moved to the
main HDMI driver. This could be changed later if need be.

Note that there's slightly similar power issue with the PLL: the HDMI
PLLs power is also handled via the WP module. For now, the PLL power
handling is still done inside the PLL driver.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

Add support to configure the pins used for the HDMI lanes. The order and
polarity of the lanes can be defined in the DT data.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>