Commit Graph

775 Commits

Author SHA1 Message Date
Ricardo Neri e92a5b28f7 OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
genirq requires that the IRQ requests that do not provided a handler to
use the IRQF_ONESHOT flag. This is to prevent situations in which the irq line
is reenabled while the interrupt is still asserted. While this situation may
not happen in edge type interrupts, genirq still requires to use IRQF_ONESHOT.

Also, remove the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated.

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-22 11:00:09 +03:00
Archit Taneja c808ab9c82 OMAPDSS: Apply VENC timings even if panel is disabled
The VENC interfaces uses it's venc_set_timing() function to take in a new set
of timings. If the panel is disabled, it does not disable and re-enable the
interface. Currently, the manager timings are applied in venc_power_on(), these
are not called by set_timings if the panel is disabled. When checking overlay
and manager data, the DSS driver uses the last applied manager timings, and not
the timings held by omap_dss_device struct. Hence, there is a need to apply the
new manager timings even if the panel is disabled.

Apply the manager timings if the VENC panel is disabled.

This is similar to the commit below which fixed the same issue for HDMI/DPI
interfaces:

fcc3661990

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-22 11:00:08 +03:00
Archit Taneja 2aefad49d8 OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
DSS2 driver uses the timings in manager's private data to check the validity of
overlay and manager infos written by the user. For VENC interface, we divide the
Y resolution by half when writing to the DISPC_DIGIT_SIZE register as the
content is interlaced. However, the height of the manager/display with respect
to the content shown through VENC still remains the same.

The VENC driver divides the y_res parameter in omap_video_timings by half, and
then applies the configuration. This leads to manager's private data storing
the wrong Y resolution. Hence, overlay related checks fail.

Ensure that manager's private data stores the original timings, and the Y
resolution is halved only when we write to the DISPC register. This is a hack,
the proper solution would be to pass some sort of interlace parameter which
makes the call whether we should divide y_res or not.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-22 11:00:01 +03:00
Chandrabhanu Mahapatra 65e006ff4b OMAPDSS: DISPC: Support rotation through TILER
TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
Physical memory can be mapped to a portion of OMAP's system address space called
TILER address space. The TILER address space is split into 8 views. Each view
represents a rotated or mirrored form of the mapped physical memory. When a
DISPC overlay's base address is programmed to one of these views, the TILER
fetches the pixels according to the orientation of the view. A view is further
split into 4 containers, each container holds elements of a particular size.
Rotation can be achieved at the granularity of elements in the container. For
more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM.
Rotation type TILER has been added which is used to exploit the capabilities of
these 8 views for performing various rotations.

When fetching from addresses mapped to TILER space, the DISPC DMA can fetch
pixels in either 1D or 2D bursts. The fetch depends on which TILER container we
are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts,
and page mode sized containers require 1D bursts.

The DSS2 user is expected to provide the Tiler address of the view that it is
interested in. This is passed to the paddr and p_uv_addr parameters in
omap_overlay_info. It is also expected to provide the stride value based on the
view's orientation and container type, this should be passed to the screen_width
parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is
used to calculate the required row_inc for DISPC. x_predecim and y_predecim are
also used to calculate row_inc and pix_inc thereby adding predecimation support
for TILER.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-22 10:59:15 +03:00
Tomi Valkeinen 3cb6a1b967 OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.

This patch fixes the warnings by initializing the variables and
returning properly after BUG() lines. However, the behaviour is still
undefined after the BUG, but this is the choice the user makes when
using CONFIG_BUG=n.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-22 10:59:15 +03:00
Tomi Valkeinen 4a75cb857d OMAPFB: remove compiler warnings when CONFIG_BUG=n
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.

This patch fixes the warnings by initializing the variables and
returning properly after BUG() lines. However, the behaviour is still
undefined after the BUG, but this is the choice the user makes when
using CONFIG_BUG=n.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-22 10:59:15 +03:00
Tomi Valkeinen c6eee968d4 OMAPDSS: remove compiler warnings when CONFIG_BUG=n
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.

This patch fixes the warnings by initializing the variables and
returning properly after BUG() lines. However, the behaviour is still
undefined after the BUG, but this is the choice the user makes when
using CONFIG_BUG=n.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-22 10:59:14 +03:00
Tomi Valkeinen 36377357db OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
Commit 05dd0f5308 ("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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Chandrabhanu Mahapatra <cmahapatra@ti.com>
2012-05-22 10:59:14 +03:00
Tomi Valkeinen 3568f2a46f OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Joe Woodward <jw@terrafix.co.uk>
2012-05-22 10:59:13 +03:00
Archit Taneja 6f28c2964b OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
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: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-21 12:21:18 +03:00
Chandrabhanu Mahapatra 05dd0f5308 OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
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: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-15 13:51:56 +03:00
Ricardo Neri f3a97491f2 OMAPDSS: HDMI: Implement DSS driver interface for audio
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:17:10 +03:00
Ricardo Neri b7dea05aec OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutex
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:17:09 +03:00
Ricardo Neri 24ccfc5541 OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA order
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:17:09 +03:00
Ricardo Neri 6ec355d6c7 OMAPDSS: HDMI: Add an audio configuration function
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:17:08 +03:00
Ricardo Neri 25a653597e OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculation
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:17:08 +03:00
Ricardo Neri 35547626f3 OMAPDSS: HDMI: Relocate N/CTS calculation
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:17:06 +03:00
Ricardo Neri c1164ed87e OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audio
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:15:23 +03:00
Ricardo Neri 7e151f7f6a OMAPDSS: HDMI: Decouple HDMI audio from ASoC
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:15:22 +03:00
Axel Castaneda Gonzalez 3df9fb5c51 OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stop
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: Axel Castaneda Gonzalez <x0055901@ti.com>
Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:15:22 +03:00
Ricardo Neri 7c92af1678 OMAPDSS: HDMI: OMAP4: Remove invalid I2S settings
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:15:21 +03:00
Ricardo Neri 199e7fd621 OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enums
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:15:21 +03:00
Ricardo Neri 7c3291f06b OMAPDSS: HDMI: Remove ASoC codec
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:15:18 +03:00
Ricardo Neri c0456be38f OMAPDSS: HDMI: Split video_enable into video_enable/disable
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:13:51 +03:00
Ricardo Neri 027bdc85ee OMAPDSS: HDMI: Split audio_enable into audio_enable/disable
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: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:13:50 +03:00
Russ Dill af461d64e1 OMAPDSS: TFP410: use gpio_set_value_cansleep
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: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 15:09:29 +03:00
Tomi Valkeinen 38f3daf678 OMAPDSS: separate pdata based initialization
Move the platform-data based display device initialization into a
separate function, so that we may later add of-based initialization.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 15:09:24 +03:00
Tomi Valkeinen 11ee960640 OMAPDSS: DSI: improve DSI module id handling
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:54:41 +03:00
Tomi Valkeinen 9d8232a77f OMAPDSS: init omap_dss_devices internally
Now that each output driver creates their own display devices, the
output drivers can also initialize those devices.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:54:38 +03:00
Tomi Valkeinen 35deca3de6 OMAPDSS: interface drivers register their panel devices
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:52:23 +03:00
Tomi Valkeinen c018c6738b OMAPDSS: change default_device handling
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:52 +03:00
Tomi Valkeinen d64f14e191 OMAPFB: add __init & __exit
Change omapfb to use platform_driver_probe and add __init & __exit.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:52 +03:00
Tomi Valkeinen 6e7e8f06b2 OMAPDSS: add __init & __exit
Now that we are using platform_driver_probe() we can add __inits and
__exits all around.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:52 +03:00
Tomi Valkeinen 61055d4b2e OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:52 +03:00
Tomi Valkeinen e40402cf18 OMAPDSS: move the creation of debugfs files
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:52 +03:00
Tomi Valkeinen 461395c464 OMAPDSS: handle output-driver reg/unreg more dynamically
Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:52 +03:00
Tomi Valkeinen 852f083843 OMAPDSS: remove uses of dss_runtime_get/put
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:51 +03:00
Tomi Valkeinen a57dd4fe7b OMAPDSS: create DPI & SDI drivers
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:51 +03:00
Tomi Valkeinen 11436e1dd2 OMAPDSS: use platform_driver_probe for core/dispc/dss
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:51 +03:00
Tomi Valkeinen 04c742c3dc OMAPDSS: remove return from platform_driver_unreg
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:51 +03:00
Tomi Valkeinen 00928eaf52 OMAPDSS: clean up the omapdss platform data mess
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:51 +03:00
Tomi Valkeinen e23d83b0c9 OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:50 +03:00
Tomi Valkeinen 958f2717b8 OMAPDSS: TFP410: pdata rewrite
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:50 +03:00
Tomi Valkeinen 3a028bb99d OMAPFB: fix parsing of vram parameter
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: Tomi Valkeinen <tomi.valkeinen@ti.com>
Reported-by: Hein Tibosch <hein_tibosch@yahoo.es>
2012-05-11 14:44:27 +03:00
Grazvydas Ignotas b3e68d3065 OMAPDSS: OMAPFB: always allow to configure overlay
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: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:21 +03:00
Grazvydas Ignotas 0aca3c63e0 OMAPDSS: VENC: allow switching venc output type at runtime
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: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:13 +03:00
Tomi Valkeinen 9b71fb5cbc Merge branch 'for-l-o-3.5'
Conflicts:
	drivers/video/omap2/displays/panel-taal.c

Merge OMAP DSS related board file changes. The branch will also be
merged through linux-omap tree to solve conflicts.
2012-05-10 20:24:14 +03:00
Archit Taneja 81ab95b7ec OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()
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: Archit Taneja <archit@ti.com>
2012-05-09 13:44:09 +03:00
Archit Taneja 3fa03ba854 OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()
The pixel clock rate for the TV manager is calculated by checking the device
type connected to the manager, and then requesting the VENC/HDMI interface for
the pixel clock rate.

Remove the use of omap_dss_device pointer from here by checking which interface
generates the pixel clock by reading the DSS_CTRL.VENC_HDMI_SWITCH bit.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:09 +03:00
Archit Taneja b3d795abb2 OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointer
The omap_dss_device pointer declared in dss_ovl_setup_fifo() isn't used. Remove
the pointer variable declaration and it's assignment.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:08 +03:00
Archit Taneja fcc3661990 OMAPDSS: DPI/HDMI: Apply manager timings even if panel is disabled
The DPI and HDMI interfaces use their 'set_timing' functions to take in a new
set of timings. If the panel is disabled, they do not disable and re-enable
the interface. Currently, the manager timings are applied in hdmi_power_on()
and dpi_set_mode() respectively, these are not called by set_timings if the
panel is disabled.

When checking overlay and manager data, the DSS driver uses the last applied
manager timings, and not the timings held by omap_dss_device struct. Hence,
there is a need to apply the new manager timings even if the panel is disabled.

Apply the manager timings if the panel is disabled. Eventually, there should be
one common place where the timings are applied independent of the state of the
panel.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:08 +03:00
Archit Taneja 228b21349d OMAPDSS: APPLY: Remove display dependency from overlay and manager checks
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.

Pass the manager's timings in private data to dss_mgr_check(). Remove the need
to pass omap_dss_device structs in the functions which check for the validity
of overlay and manager parameters.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:07 +03:00
Archit Taneja 5dd747e889 OMAPDSS: APPLY: Don't check manager settings if it is disabled
If a manager is disabled, there is no guarantee at any point in time that all
it's parameters are configured. There is always a chance that some more
parameters are yet to be configured by a user of DSS, or by DSS itself.

However, when the manager is enabled, we can be certain that all the parameters
have been configured, as we can't enable a manager with an incomplete
configuration. Therefore, if a manager is disabled, don't check for the validity
of it's parameters or the parameters of the overlays connected to it. Only check
once it is enabled. Add a check in dss_check_settings_low() to achieve the same.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:07 +03:00
Archit Taneja b917fa3961 OMAPDSS: MANAGER: Create a function to check manager timings
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.

dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the omap_dss_device struct. This would be later
replaced by the timings stored in the manager's private data.

Make dss_mgr_check_timings() and dispc_mgr_timings_ok() take a const
omap_video_timings pointer since these functions just check the timings.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:07 +03:00
Archit Taneja 4172116385 OMAPDSS: Apply manager timings instead of direct DISPC writes
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.

Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit
is set by dss_mgr_set_timings().

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:06 +03:00
Archit Taneja 45324a2648 OMAPDSS: APPLY: Add manager timings as extra_info in private data
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.

To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar to what is done for overlays. This is needed
because timings aren't a part of overlay_manager_info struct configured by a
user of DSS, they are configured internally by the interface or panel drivers.

Add dirty and shadow_dirty extra_info flags for managers, update these flags
at the appropriate places. Rewrite the function extra_info_update_ongoing()
slightly as checking for manager's extra_info flags can simplify the code a bit.

Create function dss_mgr_set_timings() which applies the new manager timings to
extra_info.

Signed-off-by: Archit Taneja <archit@ti.com>
2012-05-09 13:44:06 +03:00
Archit Taneja 408d9dbbc4 OMAPDSS: DISPC: Remove Fake VSYNC support
Fake VSYNC support is a hack and has some bugs in it. It isn't used by any user
of DSS. Remove Fake VSYNC support. For DSI command mode and RFBI panels, a user
of DSS should wait for the completion of a frame by using the panel driver's
sync op.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-09 13:43:17 +03:00
Archit Taneja a2e5d82758 OMAPDSS: Fix DSI_FCLK clock source selection
The wrong bit field was being updated in DSS_CTRL when trying to configure the
clock source of DSI2 functional clock. Use the correct bit field based on the
dsi module number.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-09 13:43:11 +03:00
Archit Taneja 9b9c457b43 OMAPDSS: HDMI: define and dump CORE registers in correct order
The HDMI core register offset macros aren't defined in ascending order of their
values, some of the offset macros are also redefined. The same issues occur when
these core registers are dumped.

Clean up the ordering of HDMI core registers and remove repeated registers in
the definition in ti_hdmi_4xxx_ip.h and in ti_hdmi_4xxx_core_dump().

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-09 13:43:05 +03:00
Archit Taneja 3c7de24771 OMAPDSS: HDMI: Fix ti_hdmi_4xxx_core_dump
The function ti_hdmi_4xxx_core_dump has some bugs, the following mention the
bugs and the solutions:

- The macros DUMPCORE and DUMPCOREAV in ti_hdmi_4xxx_core_dump() use
  hdmi_pll_base() for the offsets needed to calculate register addresses, use
  functions hdmi_core_sys_base() amd hdmi_av_base() to calculate the correct
  offsets for CORE_SYS and CORE_AV registers.

- Many of the CORE_AV registers use the DUMPCORE macro, and hence the register
  addresses are calculated incorrectly. Rename the current DUMPCOREAV macro as
  DUMPCOREAV2 as it takes 2 arguments to dump indexed CORE_AV registers, create
  a new macro called DUMPCOREAV which is now used for dumping non-indexed
  CORE_AV registers.

Thanks to Ancy Tom <ancytom@gmail.com> for pointing out the issues.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-09 13:42:58 +03:00
Tomi Valkeinen e4a9e94cc5 OMAPDSS: DSI: implement generic DSI pin config
In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.

This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.

The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:

{
	0,	// pin num for clock lane +
	1,	// pin num for clock lane -
	2,	// pin num for data1 lane +
	3,	// pin num for data1 lane -
	...
}

The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-05-09 10:53:05 +03:00
Tomi Valkeinen 3acc797c1d OMAPDSS: Taal: move reset gpio handling to taal driver
The reset GPIO for Taal panel driver is currently requested in the
4430sdp board file. This patch moves the gpio request/free into the Taal
driver, where it should be.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-05-09 10:53:05 +03:00
Tomi Valkeinen dac8eb5f1d OMAPDSS: TFP410: rename dvi files to tfp410
Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-05-09 10:51:05 +03:00
Tomi Valkeinen 2e6f2ee7ac OMAPDSS: TFP410: rename dvi -> tfp410
The driver for the TFP410 DPI-to-DVI chip was named quite badly as "DVI
panel driver". This patch renames the code to use tfp410 name for the
driver.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-05-09 10:51:05 +03:00
Tomi Valkeinen e813a55eb9 OMAP: board-files: remove custom PD GPIO handling for DVI output
Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
remove the custom PD handling from the board files.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
2012-05-09 10:51:04 +03:00
Tomi Valkeinen 2da35193dc OMAPDSS: panel-dvi: add PD gpio handling
The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.

This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-09 10:51:04 +03:00
Chandrabhanu Mahapatra 8b53d99119 OMAPDSS: DISPC: Correct DISPC functional clock usage
DISPC_FCLK is incorrectly used as functional clock of DISPC in scaling
calculations. So, DISPC_CORE_CLK replaces as functional clock of DISPC.
DISPC_CORE_CLK is derived from DISPC_FCLK divided by an independent DISPC
divisor LCD.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-03 16:13:01 +03:00
Chandrabhanu Mahapatra 7faa92339b OMAPDSS: DISPC: Handle synclost errors in OMAP3
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver rejects
configuration exceeding above limitations.

This code was successfully tested on OMAP3. This code is written based on code
written by Ville Syrjälä <ville.syrjala@nokia.com> in Linux OMAP kernel. Ville
Syrjälä <ville.syrjala@nokia.com> had added checks for video overlay horizontal
timing and DISPC horizontal blanking length limitations.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-03 16:12:57 +03:00
Chandrabhanu Mahapatra aed74b5500 OMAPDSS: DISPC: Enable predecimation
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
up to 2 times in OMAP2. However, with predecimation, the image can be reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.

The pipeline is configured to use a burst of size 8 * 128 bits which consists
of 8 mini bursts of 16 bytes each. So, horizontal predecimation more than 16
can lead to complete discarding of such mini bursts. L3 interconnect may
handover the bus to some other initiator and inturn delay the fetching of
pixels leading to underflows. So, maximum predecimation limit is fixed at 16.

Based on the downscaling required, a prior calculation of predecimation values
for width and height of an image is done. Since, Predecimation reduces quality
of an image higher priorty is given to DISPC Scaler for downscaling.

This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
vertical predecimation worked fine except for some synclost errors due to
undocumented errata in OMAP3 which are fixed later and skewed images were seen
on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
the future patches.

This code is based on code written by Lajos Molnar <lajos@ti.com> who had added
predecimation support for NV12/YUV/rotated/SDMA buffers.

Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-03 16:12:48 +03:00
Jan Weitzel 3dd606e435 ARM: OMAP2+ Add Primview displays to panel-generic
Add displays to panel-generic-dpi.c
Prime View PD050VL1 (640 x 480)
Prime View PD104SLF (800 x 600)
Prime View PM070WL4 (800 x 480)

Signed-off-by: Jan Weitzel <j.weitzel@phytec.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:11 +03:00
Archit Taneja 8f366162d2 OMAPDSS: DISPC: Clean up manager timing/size functions
Clean up the DISPC manager timings related function by:

- Create a common function to set size for LCD and TV.
- Create a common function to check timings for LCD and TV.
- Add dss params to get the range of manager size.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:10 +03:00
Archit Taneja c51d921a0c OMAPDSS: DISPC: Use a common function to set manager timings
Currently, a LCD manager's timings is set by dispc_mgr_set_lcd_timings() and TV
manager's timings is set by dispc_set_digit_size(). Use a common function called
dispc_mgr_set_timings() which sets timings for both type of managers.

We finally want the interface drivers to use an overlay manager function to
configure it's timings, having a common DISPC function would make things
cleaner.

For LCD managers, dispc_mgr_set_timings() sets LCD size and blanking values, for
TV manager, it sets only the TV size since blanking values don't exist for TV.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:10 +03:00
Archit Taneja e5c09e06a9 OMAPDSS: DISPC/RFBI: Use dispc_mgr_set_lcd_timings() for setting lcd size
The RFBI driver uses dispc_mgr_set_lcd_size() to set the width and height of
the LCD manager. Replace this to use dispc_mgr_set_lcd_timings(), pass dummy
blanking parameters like done in the DSI driver.

This prevents the need to export dispc_mgr_set_lcd_size(), and use a common
function to set lcd timings.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:09 +03:00
Thomas Weber e97374c0fe OMAPDSS: Add EDT ET0500G0DH6 display support
The EDT ET0500G0DH6 is a 5 inch display. It is
tested on an OMAP3 board.

Signed-off-by: Thomas Weber <weber@corscience.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:08 +03:00
Thomas Weber 697bacbaea OMAPDSS: Add Mitsubishi AA084SB01 display support
This patch adds support for the Mitsubishi display
AA084SB01. This is a 7 inch LVDS display. It is tested with
an OMAP3 board.

Signed-off-by: Thomas Weber <weber@corscience.de>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:08 +03:00
Grazvydas Ignotas 31e8dfe148 OMAPDSS: TPO-TD03MTEA1: add set/check timing functions
On pandora we use .set_timings to alter refresh rate,
so add .check_timings/.set_timings functions.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:07 +03:00
Grazvydas Ignotas 4b6430fc98 OMAPDSS: provide default get_timings function for panels
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:07 +03:00
Grazvydas Ignotas f3fb3bbc7f OMAPDSS: OMAPFB: check for matching memory size early
If the size of memory region that is being set up is the same as before,
we don't have to do memory and layer busy checks.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:06 +03:00
Mark Brown 2c83af49ca OMAPDSS: TPO-TD03MTEA1: Correct comment for power on delay
Since any power on stabilisation delay for the supply itself should be
taken care of transparently by the regulator API when the regulator is
enabled the additional delay that the TPO-TD03MTEA1 driver adds after
that returned should be due to the requirements of the device itself
rather than the supply (the delay is also suspicously long for one for
a regulator to ramp). Correct the comment to avoid misleading people
taking this code as a reference.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:06 +03:00
Mark Brown 956107eadc OMAPDSS: TPO-TD03MTEA1: Check for errors from regulator_enable()
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:05 +03:00
Mark Brown ec8741078d OMAPDSS: VENC: Check for errors from regulator_enable()
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:05 +03:00
Mark Brown 9c3d5eb71b OMAP: DSS2: Remove suspicous and unused TAAL regulator API usage
The TAAL driver contains some regulator support which is currently unused
(the code is there but the one panel supported by the driver doesn't have
any regulators provided). This code mostly looks like an open coded
version of the regulator core bulk API.

The only additional feature is that a voltage range can be set once when
the device is opened, though this is never varied at runtime. The general
expectation is that if the device is not actively managing the voltage of
the device (eg, doing DVFS) then any configuration will be done using the
constraints rather than by drivers, saving them code and ensuring that
they work well with systems where the voltage is not configurable.

If systems are added needing regulator support this can be added back in,
though it should be based on core features rather than open coding things.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:04 +03:00
Tomi Valkeinen b6e695abe7 OMAPDSS: DSI: remove option to use pck for DSI PLL clkin
For some OMAP versions the TRM says that the pixel clock from DISPC can
be used as an input clock for DSI PLL, instead of the default, which is
sysclk.  For some OMAP versions the bits affecting this are marked as
reserved.  This feature has never been tested, so it's unknown if the HW
even works, and has never been used.

To clean things up, this patch removes the functionality. This should
not affect any board.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-04-23 10:48:04 +03:00
Tomi Valkeinen a8081d3179 OMAPDSS: Ensure OPP100 when DSS is operational
Most of the DSS clocks have restrictions on their frequency based on the
OPP in use. For example, maximum frequency for a clock may be 180MHz in
OPP100, but 90MHz in OPP50. This means that when a high enough pixel
clock or function clock is required, we need to use OPP100.

However, there's currently no way in the PM framework to make that kind
of request. The closest we get is to ask for very high bus throughput
from the PM framework, which should effectively force OPP100.

This patch is a simple version for handling the problem. Instead of
asking for OPP100 only when needed, this patch asks for OPP100 whenever
DSS is active. This obviously is not an optimal solution for cases with
small displays where OPP50 would work just fine. However, a proper
solution is a complex one, and this patch is a short term solution for
the problem.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Acked-by: Kevin Hilman <khilman@ti.com>
2012-04-23 10:48:03 +03:00
Linus Torvalds 820d41cf0c ARM: cleanups of io includes
Rob Herring has done a sweeping change cleaning up all of the mach/io.h includes,
 moving some of the oft-repeated macros to a common location and removing a bunch of
 boiler plate. This is another step closer to a common zImage for multiple platforms.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIcBAABAgAGBQJPcpqHAAoJEIwa5zzehBx3xCMP/2evrPQyorzMBztrFB4Ry9Ol
 qNkSVNsemZjdtkY2dnJv+zJ/Xb0PPDU9EuBHr/SpqmVrRZEZeJND42wZK/OTFCBZ
 Ufi7KP1qE30daO5H3YmL+58/Ixir5fTHqggqolHhTcEYU2hnHgLBI4rIFu92kSO7
 TMyrAUs14jSkTVZc6HSF83w3PfQWhMzWvspJVHQ6RebZRruETAr7v9weVMbgxcDk
 jQ5XJ9y73rGs2AF8bZTpUdFPzkcac7UiHn3/XyqoZs8RNCL98BGpskzhILyTARf5
 X90c9mqQF+AEbb9QSDDd52uYFsJ/5COJvWdlExRI9gZZDI8Pd05ijZBR9IdGJg/B
 NsVsl98wvZ/zjHJ/Sb2qt5ruet7PiQUGhkshB42jVHsaWfRM030sKGYxQ8pX5Tsa
 cSagnfBCvAZ9VjDLkXrnEbWRNTz8LSwn9l63z0jmtm5D8+vbpMtgvtWARtuZ4RNn
 D8wIWoyT0ytVZnosu5441TEgCejtcKOEFzThvKDYMeMJZ/rqVkAbcznapoC2qUd4
 fceNlLfQFvW7xpY1MY8mhlwC0ki4hM9MSDieaXUyefvAU/hoSp8MveVUH5UspYfb
 0FpkEhzklW/g0/fuq0DJQIrMn7dajjUvVZIUQtiVQuFHOr6RUbFG5vmXuCbAyx10
 PE2K4rnKz+PC8bKab7v9
 =YIsn
 -----END PGP SIGNATURE-----

Merge tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull "ARM: cleanups of io includes" from Olof Johansson:
 "Rob Herring has done a sweeping change cleaning up all of the
  mach/io.h includes, moving some of the oft-repeated macros to a common
  location and removing a bunch of boiler plate.  This is another step
  closer to a common zImage for multiple platforms."

Fix up various fairly trivial conflicts (<mach/io.h> removal vs changes
around it, tegra localtimer.o is *still* gone, yadda-yadda).

* tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (29 commits)
  ARM: tegra: Include assembler.h in sleep.S to fix build break
  ARM: pxa: use common IOMEM definition
  ARM: dma-mapping: convert ARCH_HAS_DMA_SET_COHERENT_MASK to kconfig symbol
  ARM: __io abuse cleanup
  ARM: create a common IOMEM definition
  ARM: iop13xx: fix missing declaration of iop13xx_init_early
  ARM: fix ioremap/iounmap for !CONFIG_MMU
  ARM: kill off __mem_pci
  ARM: remove bunch of now unused mach/io.h files
  ARM: make mach/io.h include optional
  ARM: clps711x: remove unneeded include of mach/io.h
  ARM: dove: add explicit include of dove.h to addr-map.c
  ARM: at91: add explicit include of hardware.h to uncompressor
  ARM: ep93xx: clean-up mach/io.h
  ARM: tegra: clean-up mach/io.h
  ARM: orion5x: clean-up mach/io.h
  ARM: davinci: remove unneeded mach/io.h include
  [media] davinci: remove includes of mach/io.h
  ARM: OMAP: Remove remaining includes for mach/io.h
  ARM: msm: clean-up mach/io.h
  ...
2012-03-29 18:02:10 -07:00
Linus Torvalds d61b7a572b ARM: global cleanups
Quite a bit of code gets removed, and some stuff moved around, mostly
 the old samsung s3c24xx stuff. There should be no functional changes
 in this series otherwise. Some cleanups have dependencies on other
 arm-soc branches and will be sent in the second round.
 
 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQIVAwUAT2pCjGCrR//JCVInAQLd8RAAqCxhzSc4ewTUP/974gVhujj3TrpiEQcS
 FKvYWF76yP38Lbf3CJZBZaONRtrQNOhYpVQ0jb3WCV4F8mEH9PCes2q9RObeBYiY
 TNX8VdcuVjX2U9HaH0+RQtBUdujNLHpEOqtO57un7T5UDNssR5JOive1tNAooRv1
 pL0Hgx3AVqUbNOPpqQqHzy/MDdd67S6dX80yysANjFGMX87Nvp/ztYAdNnIdta+Z
 pDJt+DPlmK8LvjoSL3SEUN0p3Thk75621cCuauGq88PLIB2w62tzF0NFFbvIAgJT
 3aMlHM2flOiTJAWkUvA8zJiUzwv/0vYvH3xPoTo84abve3lVfZcY+fHNcfxE/Gge
 ri2MmkHyimVP3rNeyM0GbN1RTej1TN1MezeQW3nq2wP6nvS2k0/t32ObLLtWU7XA
 6iA0hKVMSnhqj4ln6jPAmyaDkaWHyYz97urhgetHqGadvLTiGPXCSBPalSiFmyMo
 11tvuqwUNz9tw4nsvGboFQwS2ZoVquC5inoHp5seqZETkGCB67JyeRGxtAM4gbP/
 wIRa3OBLY99yo1on6QovWNnSOMC6X4cOvBI/qHIjSEY/T9JVkslY87gRg3LkxCBR
 XpXfZ6iuLHoSRUGcIjE8D6KHjMgWIDPRnLkIliK4H+3Jn08g0R1MxCplevFCRtis
 egswZ8C24Xw=
 =o5Xl
 -----END PGP SIGNATURE-----

Merge tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc

Pull "ARM: global cleanups" from Arnd Bergmann:
 "Quite a bit of code gets removed, and some stuff moved around, mostly
  the old samsung s3c24xx stuff.  There should be no functional changes
  in this series otherwise.  Some cleanups have dependencies on other
  arm-soc branches and will be sent in the second round.

  Signed-off-by: Arnd Bergmann <arnd@arndb.de>"

Fixed up trivial conflicts mainly due to #include's being changes on
both sides.

* tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (121 commits)
  ep93xx: Remove unnecessary includes of ep93xx-regs.h
  ep93xx: Move EP93XX_SYSCON defines to SoC private header
  ep93xx: Move crunch code to mach-ep93xx directory
  ep93xx: Make syscon access functions private to SoC
  ep93xx: Configure GPIO ports in core code
  ep93xx: Move peripheral defines to local SoC header
  ep93xx: Convert the watchdog driver into a platform device.
  ep93xx: Use ioremap for backlight driver
  ep93xx: Move GPIO defines to gpio-ep93xx.h
  ep93xx: Don't use system controller defines in audio drivers
  ep93xx: Move PHYS_BASE defines to local SoC header file
  ARM: EXYNOS: Add clock register addresses for EXYNOS4X12 bus devfreq driver
  ARM: EXYNOS: add clock registers for exynos4x12-cpufreq
  PM / devfreq: update the name of EXYNOS clock registers that were omitted
  PM / devfreq: update the name of EXYNOS clock register
  ARM: EXYNOS: change the prefix S5P_ to EXYNOS4_ for clock
  ARM: EXYNOS: use static declaration on regarding clock
  ARM: EXYNOS: replace clock.c for other new EXYNOS SoCs
  ARM: OMAP2+: Fix build error after merge
  ARM: S3C24XX: remove call to s3c24xx_setup_clocks
  ...
2012-03-27 16:03:32 -07:00
Tomi Valkeinen dc7e57fa80 OMAPDSS: register dss drivers in module init
We do the dss driver registration in a rather strange way: we have the
higher level omapdss driver, and we use that driver's probe function to
register the drivers for the rest of the dss devices.

There doesn't seem to be any reason for that, and additionally the
soon-to-be-merged patch "ARM: OMAP: omap_device: remove
omap_device_parent" will break omapdss initialization with the current
registration model.

This patch changes the registration for all drivers to happen at the
same place, in the init of the module.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-03-21 12:55:15 +00:00
Florian Tobias Schandinat e9fe8a714e Merge branch 'for-3.4' of git://gitorious.org/linux-omap-dss2/linux into fbdev-next 2012-03-20 08:49:51 +00:00
Olof Johansson e3643b77de Merge branch 'next/cleanup-exynos-clock' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into next/cleanup
* 'next/cleanup-exynos-clock' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  ARM: EXYNOS: Add clock register addresses for EXYNOS4X12 bus devfreq driver
  ARM: EXYNOS: add clock registers for exynos4x12-cpufreq
  PM / devfreq: update the name of EXYNOS clock registers that were omitted
  PM / devfreq: update the name of EXYNOS clock register
  ARM: EXYNOS: change the prefix S5P_ to EXYNOS4_ for clock
  ARM: EXYNOS: use static declaration on regarding clock
  ARM: EXYNOS: replace clock.c for other new EXYNOS SoCs
  (includes an update to v3.3-rc6)
2012-03-13 16:08:06 -07:00
Tomi Valkeinen df01d53068 OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update
Currently the shadow-dirty flags for manual update displays is cleared
in the apply_irq_handler when an update has finished. This is not
correct, as the shadow registers are taken into use (i.e. after that
they are not dirty) when the update is started.

Move the mgr_clear_shadow_dirty() call from apply_irq_handler to
dss_mgr_start_update() to fix this.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-13 15:46:21 +02:00
Tony Lindgren 6076c64412 ARM: OMAP: Remove remaining includes for mach/io.h
These are no longer needed with the recent iomap.h
changes.

Reported-by: Rob Herring <robherring2@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-03-06 21:34:38 -06:00
Tomi Valkeinen 4614679c9d OMAPDSS: APPLY: print warning if wait_pending_extra_info_updates fails
wait_pending_extra_info_updates() currently does a hacky second check
for extra_info_update_ongoing() at the end of the function to show a
warning if extra_info update is still ongoing. The call to
extra_info_update_ongoing() should really be inside spinlock, but that's
a bit heavy just for verification.

Rather than that, check the return value of the
wait_for_completion_timeout() and print an error if it has timeouted or
returned an error.

Even better would be to return the error value and act on it in the
callers of wait_pending_extra_info_updates. However, it's not clear what
the callers should do in case of an error, as the error should only
happen if there's a bug in the driver or the HW. So we'll just print the
warning for now.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-06 14:08:39 +02:00
Lajos Molnar 21e56f79ab OMAPDSS: MANAGER/APPLY: Add runtime_pm protection around wait_for_go/vsync functions
If DSS suspends within the functions dss_mgr_wait_for_go(),
dss_mgr_wait_for_go_ovl() or dss_mgr_wait_for_vsync(). It may lose it's clock
and lead to a register access failure.

Request runtime_pm around these functions.

[archit@ti.com: Moved runtime_pm calls to wait_for_go/vsync functions rather
then calling them from omap_dispc_wait_for_irq_interruptible_timeout()]

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-06 14:08:30 +02:00
Lajos Molnar c0c1cfcb57 OMAPDSS: DISPC: Fix FIR coefficients
coef3_M8 had an incorrect phase with 50% more intensity. This resulted in
banding on slightly down/upscaled images. Fixed a rounding error in coef5_M9.

Also removed ARRAY_LEN macro as ARRAY_SIZE is the standard linux one.

Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-06 14:08:23 +02:00
Lajos Molnar 08f3267e26 OMAPDSS: DISPC: Fix OMAP4 supported color formats
Add missing but supported color formats for GFX pipeline in dss features:
RGBX16-4444, RGBA16-4444 and XRGB16-1555.

In dispc_ovl_set_color_mode():

- Remove unsupported modes on GFX pipeline: YUV2 and UYVY. Replace these by
  missing modes supported by GFX pipelines: RGBX16-4444 and RGBA16-4444.

- Fix swapped modes on VID pipelines: RGBX16-4444 and XRGB16-4444.

Signed-off-by: Lajos Molnar <lajos@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-06 14:08:16 +02:00
Mythri P K dd2116a35a OMAPDSS: HDMI: Add M2 divider while calculating clkout
While calculating regm and regmf value add using M2 divider in
the equation.
Formula for calculating:
Output clock on digital core domain:
	CLKOUT = (M / (N+1))*CLKINP*(1/M2)
Internal oscillator output clock on internal LDO domain:
	CLKDCOLDO = (M / (N+1))*CLKINP
The current code when allows variable M2 values as input
ignores using M2 divider values in calculation of regm and regmf.
so fix it by using M2 in calculation although the default value for
M2 is 1.

Signed-off-by: Mythri P K <mythripk@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-03-06 14:08:10 +02:00
Tomi Valkeinen 0ba86d7ede Merge commit 'v3.3-rc6'
Merge v3.3-rc6 to get the latest DSS and OMAP arch fixes.

Conflicts:
	arch/arm/mach-omap1/board-innovator.c
	drivers/video/omap2/dss/apply.c
2012-03-06 13:20:31 +02:00
Florian Tobias Schandinat 0d04c58aa4 Merge branch 'fbdev-for-linus' into fbdev-next 2012-02-29 22:42:55 +00:00
Tomi Valkeinen a3d0e4aeca OMAPDSS: APPLY: make ovl_enable/disable synchronous
ovl->enable/disable are meant to be synchronous so that they can handle
the configuration of fifo sizes. The current kernel doesn't configure
fifo sizes yet, and so the code doesn't need to block to function (from
omapdss driver's perspective).

However, for the users of omapdss a non-blocking ovl->disable is
confusing, because they don't know when the memory area is not used
any more.

Furthermore, when the fifo size configuration is added in the next merge
window, the change from non-blocking to blocking could cause side
effects to the users of omapdss. So by making the functions block
already will keep them behaving in the same manner.

And, while not the main purpose of this patch, this will also remove the
compile warning:

drivers/video/omap2/dss/apply.c:350: warning:
'wait_pending_extra_info_updates' defined but not used

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-02-29 22:42:28 +00:00
Tomi Valkeinen c9043ff9e6 OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
panel-dvi uses i2c, but the Kconfig didn't have dependency on I2C. Add
it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2012-02-29 22:42:28 +00:00