- 11 May, 2012 29 commits
-
-
Ricardo Neri authored
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>
-
Ricardo Neri authored
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>
-
Ricardo Neri authored
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>
-
Ricardo Neri authored
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>
-
Ricardo Neri authored
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>
-
Tomi Valkeinen authored
Merge OMAP DSS cleanups that restructure the omapdss driver to facilitate implementing device tree support in the future.
-
Russ Dill authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
Change omapfb to use platform_driver_probe and add __init & __exit. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Grazvydas Ignotas authored
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>
-
Grazvydas Ignotas authored
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>
-
- 10 May, 2012 1 commit
-
-
Tomi Valkeinen authored
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.
-
- 09 May, 2012 10 commits
-
-
Tomi Valkeinen authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-
Archit Taneja authored
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>
-