Commit 05dd0f53 ("OMAPDSS: DISPC: Update
Accumulator configuration for chroma plane") adds
dispc_ovl_set_accu_uv() function that sets the accu, but the function
only handles YUV and NV12 modes, and BUGs otherwise.

The patch also adds a call to the function, but unfortunately the place
of call was such that the mode could be other than YUV or NV12, thus
crashing the driver.

This patchs moves the call to a slightly later spot, at which point only
YUV and NV12 modes are handled.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>

There is a problem related to DSS FIFO thresholds and power management
on OMAP3. It seems that when the full PM hits in, we get underflows. The
core reason is unknown, but after experiments it looks like only
particular FIFO thresholds work correctly.

This bug is related to an earlier patch, which added special FIFO
threshold configuration for OMAP3, because DSI command mode output
didn't work with the normal threshold configuration.

However, as the above work-around worked fine for other output types
also, we currently always configure thresholds in this special way on
OMAP3. In theory there should be negligible difference with this special
way and the standard way. The first paragraph explains what happens in
practice.

This patch changes the driver to use the special threshold configuration
only when the output is a manual update display on OMAP3. This does
include RFBI displays also, and although it hasn't been tested (no
boards using RFBI) I suspect the similar behaviour is present there
also, as the DISPC side should work similarly for DSI command mode and
RFBI.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Joe Woodward <jw@terrafix.co.uk>

DSI supports interleaving of command mode packets during the HSA, HFP, HBP and
BLLP blanking intervals in a video mode stream. This is useful as a user may
want to read or change the configuration of a panel without stopping the video
stream.

On OMAP DSI, we can queue HS or LP command mode packets in the TX FIFO, and
the DSI HW takes care of interleaving this data during the one of the blanking
intervals. The DSI HW needs to be programmed with the maximum amount of data
that can be interleaved in a particular blanking period. A blanking period
cannot be used to send command mode data for it's complete duration, there is
some amount of time required for the DSI data and clock lanes to transition
to the desired LP or HS state.

Based on the state of the lanes at the beginning and end of the blanking period,
we have different scenarios, with each scenario having a different value of time
required to transition to HS or LP. Refer to the section 'Interleaving Mode' in
OMAP TRM for more info on the scenarios and the equations to calculate the time
required for HS or LP transitions.

We use the scenarios which takes the maximum time for HS or LP transition, this
gives us the minimum amount of time that can be used to interleave command mode
data. The amount of data that can be sent during this minimum time is calculated
for command mode packets both in LP and HS. These are written to the registers
DSI_VM_TIMING4 to DSI_VM_TIMING6.

The calculations don't take into account the time required of transmitting BTA
when doing a DSI read, or verifying if a DSI write went through correctly. Until
these latencies aren't considered, the behaviour of DSI is unpredictable when
a BTA is interleaved during a blanking period. Enhancement of these calculations
is a TODO item.

The calculations are derived from DSI parameter calculation tools written by
Sebastien Fagard <s-fagard@ti.com>
Signed-off-by: NArchit Taneja <archit@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

DISPC has two accumulator registers DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1 each
with horizontal and vertical bit fields. The bit fields can take values in the
range of -1024 to 1023. Based on bit field values DISPC decides on which one out
of 8 phases the filtering starts. DISPC_VIDp_ACCU_0 is used for progressive
output and for interlaced output both DISPC_VIDp_ACCU_0 and DISPC_VIDp_ACCU_1
are used.

The current accumulator values in DISPC scaling logic for chroma plane takes
default values for all color modes and rotation types. So, the horizontal and
vertical up and downsampling accumulator bit field values have been updated for
better performance.
Signed-off-by: NChandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Implement the DSS device driver audio support interface in the HDMI
panel driver and generic driver. The implementation relies on the
IP-specific functions that are defined at DSS probe time.

A mixed locking strategy is used. The panel's mutex is used when
the state of the panel is queried as required by the audio functions.
The audio state is protected using a spinlock as users of DSS HDMI
audio functionality might start/stop audio while holding a spinlock.
The mutex and the spinlock are held and released as needed by each
individual function to protect the panel state and the audio state.

Although the panel's audio_start functions does not check whether
the panel is active, the audio _ENABLED state can be reached only
from audio_enable, which does check the state of the panel. Also,
if the panel is ever disabled, the audio state will transition
to _DISABLED. Transitions are always protected by the audio lock.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

As the hdmi_lock mutex is inside the hdmi struct, rename to simply
"lock". This is only a change in the name. There are not changes
in functionality.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

As of today, the only know user of the DSS HDMI audio support is
ASoC. Hence, it makes sense to remap the speaker order to match
the ALSA speaker order. In the future, a dynamic mapping mechanism
may be implemented.

Remapping is needed as the HDMI speaker order is FL/FR/LFE/C/RL/RR/
RLC-FLC/RRC-FLC while the ALSA order is FL/FR/RL/RR/C/LFE/SL/SR.
Refer to CEA-861 Section 6.6.2 for further details.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

The generic HDMI driver does not need to know about the specific
settings of a given IP. Hence, it just passes the audio configuration
and the IP library parses such configuration and sets the IP
accordingly. This patch introduces an IP-specific audio configuration
function.

Also, this patch implements the audio config function for OMAP4. The
DMA, format and core config functions are no longer exposed to the
generic HDMI driver as they are IP-specific.

The audio configuration function caters for 16-bit through 24-bit
audio samples with sample rates from 32kHz and up to 192kHz as well
as up to 8 audio channels.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

Add support for more sample rates when calculating N and CTS. This
covers all the audio sample rates that an HDMI source is allowed
to transmit according to the HDMI 1.4a specification.

Also, reorganize the logic for the calculation when using deep color.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

The N and CTS parameters are relevant to all HDMI implementations and
not specific to a given IP. Hence, the calculation is relocated
into the generic HDMI driver.

Also, deep color is not queried but it is still considered in the
calculation of N. This is to be changed when deep color functionality is
implemented in the driver.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

Utilize a snd_aes_iec958 struct to write the parameters of the IEC-60958
channel status word into the HDMI IP registers. Hence, the user of the
driver has full control of what parameters are written in the word.

Also, some of the parameters of the I2S structure have been removed
as they are actually IEC-60958 parameters.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

Instead of having OMAPDSS HDMI audio functionality depending on the
ASoC HDMI audio driver, use a new config option so that
potential users, including ASoC, may select if needed.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

Decouple the enable/disable operation of the HDMI audio wrapper from
audio start/stop. Otherwise, an audio FIFO underflow may occur. The
audio wrapper enablement must be done after configuration and
before audio playback is started.
Signed-off-by: NAxel Castaneda Gonzalez <x0055901@ti.com>
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

According to the most up-to-date documentation from Texas Instruments,
the configuration of High Bitrate Audio is not possible. Also, it is
not possible to set polarity of the I2S Word Select signal. This patch
removes the invalid settings.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

Instead of having its own definitions for CEA-861 and IEC-60958, the HDMI
driver should use those provided by ALSA. This patch removes the definitions
that are already provided by ALSA.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

Remove the ASoC OMAP HDMI audio codec. The goal of removing the codec
is to, in subsequent patches, give way to the implementation of the HDMI
audio support using the DSS device driver audio interface. This
approach will expose the HDMI audio functionality to any interested entity.

In a separate patch, ASoC will use this new approach to expose HDMI audio
to ALSA.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

To improve readability, split the video_enable HDMI IP operation
into two separate functions for enabling and disabling video.
The video_enable function is also modified to return an error value.

While there, update these operations for the OMAP4 IP accordingly.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

To improve readability, split the audio_enable HDMI IP operation
into two separate functions for enabling and disabling audio.
The audio_enable function is also modified to return an error value.

While there, update these operations for the OMAP4 IP accordingly.
Signed-off-by: NRicardo Neri <ricardo.neri@ti.com>

The Beagleboard xM gpio used for TFP410 powerdown is connected through
an I2C attached chip which means setting the GPIO can sleep. Code that
calls tfp410_power_on/off holds a mutex, so sleeping should be fine.
Signed-off-by: NRuss Dill <Russ.Dill@ti.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Move the platform-data based display device initialization into a
separate function, so that we may later add of-based initialization.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently use the id of the dsi platform device (dsidev->id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.

However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.

Instead of using dsidev->id during operation, this patch stores the
value of dsidev->id to a private field of the dsi driver at probe(). The
future device tree code can thus set the private field with some other
way.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that each output driver creates their own display devices, the
output drivers can also initialize those devices.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Currently the higher level omapdss platform driver gets the list of
displays in its platform data, and uses that list to create the
omap_dss_device for each display.

With DT, the logical way to do the above is to list the displays under
each individual output, i.e. we'd have "dpi" node, under which we would
have the display that uses DPI. In other words, each output driver
handles the displays that use that particular output.

To make the current code ready for DT, this patch modifies the output
drivers so that each of them creates the display devices which use that
output. However, instead of changing the platform data to suit this
method, each output driver is passed the full list of displays, and the
drivers pick the displays that are meant for them. This allows us to
keep the old platform data, and thus we avoid the need to change the
board files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have a two ways to set a "default panel device" for dss, to
which the overlays are connected when the omapdss driver is loaded:

- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata

The current code handles this in a bit too complex way by using both of
the above methods during runtime. However, with DT we don't have pdata
anymore, so the code handling the second case won't work anymore. The
current code has also the problem that it modifies the platform_data.

This patch simplifies the code a bit by using the pointer method only
inside the probe function, and stores the name of the panel device. This
way we only need to handle the textual format during operation and also
avoid modifying the platform_data.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Change omapfb to use platform_driver_probe and add __init & __exit.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that we are using platform_driver_probe() we can add __inits and
__exits all around.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that the core.c doesn't fail if output driver's init fails, we can
change the uses of platform_driver_register to platform_driver_probe.
This will allow us to use __init in the following patches.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

Now that the omapdss_core device is the parent for all other dss
devices, we don't need to use the dss_runtime_get/put anymore. Instead,
enabling omapdss_core will happen automatically when a child device is
enabled.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.

This patch modifies the dpi.c and sdi.c to create drivers for the
platform devices.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The platform devices for omapdss, dss and dispc drivers are always
present, so we can use platform_driver_probe instead of
platform_driver_register.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

For unknown reasons we seem to have a return in each of the omapdss's
uninit functions, which is a void function.

Remove the returns.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:

- Remove struct omap_display_platform_data. It was used just as a
  wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
  dss hwmods do not need the platform data. This should also work better
  for DT, as we can create omapdss device programmatically in generic omap
  boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
  that the dss hwmod drivers can call.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
instance. However, there were a few places where dsidev->id was used
instead of the function. Fix those places to use the function.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

To ease device tree adaptation in the future, rewrite TFP410 platform
data handling to be done inside probe(), so that probe() is the only
place where we need to handle the DT/pdata choice.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

omapfb_parse_vram_param()'s check for end pointer returned from
simple_strtoul() is wrong, causing the code to bug if the second or
later vram parameters are non-parseable, for example
"omapfb.vram=0:2M,:5M".

However, even in that case the code will most likely bail out with
-EINVAL in the following checks, so the bug is probably not a fatal one.
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: NHein Tibosch <hein_tibosch@yahoo.es>

Currently when multiple overlays are active, OMAPFB_SETUP_PLANE fails.
Instead of failing, allow it to configure the first overlay as if there
was only one overlay, the remaining ones will have to be configured in
other ways (sysfs).

This allows overlay-controlling programs (like video players) to function
properly when framebuffer is cloned to another display (like TV).
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

VENC output type (composite/svideo) doesn't have to be fixed by board
wiring, it is possible to also provide composite signal through svideo
luminance connector (software enabled), which is what pandora does.

Having to recompile the kernel for users who have TV connector types
that don't match default board setting is very inconvenient, especially
for users of a consumer device, so add support for switching VENC output
type at runtime over a new sysfs file output_type.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>

The functions calc_fclk_five_taps() and check_horiz_timing_omap3() use the
function dispc_mgr_get_device() to get the omap_dss_device pointer to which
the manager is connected, the width of the panel is derived from that.

The manager's timing is stored in it's private data in APPLY. This contains
the latest timings applied to the manager. Pass these timings to
dispc_ovl_setup() and use them in the above functions. Remove the function
dispc_mgr_get_device() as it isn't used any more.
Signed-off-by: NArchit Taneja <archit@ti.com>