Commit Graph

299582 Commits

Author SHA1 Message Date
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
Ricardo Neri
9c0b842036 OMAPDSS: Provide an interface for audio support
There exist several display technologies and standards that support audio as
well. Hence, it is relevant to update the DSS device driver to provide an audio
interface that may be used by an audio driver or any other driver interested in
the functionality.

The audio_enable function is intended to prepare the relevant
IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
some IP, enabling companion chips, etc). It is intended to be called before
audio_start. The audio_disable function performs the reverse operation and is
intended to be called after audio_stop.

While a given DSS device driver may support audio, it is possible that for
certain configurations audio is not supported (e.g., an HDMI display using a
VESA video timing). The audio_supported function is intended to query whether
the current configuration of the display supports audio.

The audio_config function is intended to configure all the relevant audio
parameters of the display. In order to make the function independent of any
specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
is to contain all the required parameters for audio configuration. At the
moment, such structure contains pointers to IEC-60958 channel status word and
CEA-861 audio infoframe structures. This should be enough to support HDMI and
DisplayPort, as both are based on CEA-861 and IEC-60958. The omap_dss_audio
structure may be extended in the future if required.

The audio_enable/disable, audio_config and audio_supported functions could be
implemented as functions that may sleep. Hence, they should not be called
while holding a spinlock or a readlock.

The audio_start/audio_stop function is intended to effectively start/stop audio
playback after the configuration has taken place. These functions are designed
to be used in an atomic context. Hence, audio_start should return quickly and be
called only after all the needed resources for audio playback (audio FIFOs,
DMA channels, companion chips, etc) have been enabled to begin data transfers.
audio_stop is designed to only stop the audio transfers. The resources used
for playback are released using audio_disable.

A new enum omap_dss_audio_state is introduced to help the implementations of
the interface to keep track of the audio state. The initial state is _DISABLED;
then, the state transitions to _CONFIGURED, and then, when it is ready to
play audio, to _ENABLED. The state _PLAYING is used when the audio is being
rendered.

Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
2012-05-11 15:13:50 +03:00
Tomi Valkeinen
38137c8f0c Merge branch 'dss-devtree-cleanup'
Merge OMAP DSS cleanups that restructure the omapdss driver to facilitate
implementing device tree support in the future.
2012-05-11 15:10:10 +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
53f576a8dc OMAPDSS: create DPI & SDI devices
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 arch/arm/mach-omap2/display.c to create platform
devices for DPI and SDI, and later patches will implement driver for
them.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-11 14:44:51 +03:00
Tomi Valkeinen
966eaed08c OMAPDSS: create custom pdevs for DSS omap_devices
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod 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
Tomi Valkeinen
1dfafbc655 Merge branch 'archit/set-timing-work'
An overlay manager's timings (the manager size, and blanking parameters
if an LCD manager) are DISPC shadow registers, and they should hence
follow the correct programming model.

This series makes the video timings an extra_info parameter in manager's
private data. The interface drivers now apply the timings instead of
directly writing to registers.

This change also prevents the need to use display resolution for overlay
checks, hence making some of the APPLY functions less dependent on the
display. Some DISPC functions that needed display width can also use
these privately stored timings.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-05-09 13:53:52 +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