summaryrefslogtreecommitdiff
path: root/drivers/video
Commit message (Collapse)AuthorAgeFilesLines
* OMAPDSS: remove compiler warnings when CONFIG_BUG=nTomi Valkeinen2012-05-226-5/+113
| | | | | | | | | | | | | | 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>
* OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uvTomi Valkeinen2012-05-221-3/+4
| | | | | | | | | | | | | | | | | Commit 05dd0f5308213e169b02458a7f3a61362e581e14 ("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>
* OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displaysTomi Valkeinen2012-05-223-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: DSI: Support command mode interleaving during video mode blanking ↵Archit Taneja2012-05-211-0/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: DISPC: Update Accumulator configuration for chroma planeChandrabhanu Mahapatra2012-05-151-3/+89
| | | | | | | | | | | | | | | | | 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>
* OMAPDSS: HDMI: Implement DSS driver interface for audioRicardo Neri2012-05-113-2/+241
| | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: HDMI: Panel: Simplify the name of the HDMI mutexRicardo Neri2012-05-111-20/+21
| | | | | | | | 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>
* OMAPDSS: HDMI: OMAP4: Remap speaker order to match ALSA orderRicardo Neri2012-05-111-0/+8
| | | | | | | | | | | | | 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>
* OMAPDSS: HDMI: Add an audio configuration functionRicardo Neri2012-05-114-14/+191
| | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: HDMI: Add support for more audio sample rates in N/CTS calculationRicardo Neri2012-05-111-14/+74
| | | | | | | | | | 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>
* OMAPDSS: HDMI: Relocate N/CTS calculationRicardo Neri2012-05-114-59/+43
| | | | | | | | | | | | 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>
* OMAPDSS: HDMI: OMAP4: Expand configuration for IEC-60958 audioRicardo Neri2012-05-112-13/+20
| | | | | | | | | | | 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>
* OMAPDSS: HDMI: Decouple HDMI audio from ASoCRicardo Neri2012-05-115-12/+10
| | | | | | | | 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>
* OMAPDSS: HDMI: Decouple wrapper enable/disable and audio start/stopAxel Castaneda Gonzalez2012-05-113-5/+22
| | | | | | | | | | 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>
* OMAPDSS: HDMI: OMAP4: Remove invalid I2S settingsRicardo Neri2012-05-112-8/+0
| | | | | | | | | 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>
* OMAPDSS: HDMI: OMAP4: Remove CEA-861 audio infoframe and IEC-60958 enumsRicardo Neri2012-05-112-95/+20
| | | | | | | | 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>
* OMAPDSS: HDMI: Remove ASoC codecRicardo Neri2012-05-112-241/+0
| | | | | | | | | | | | 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>
* OMAPDSS: HDMI: Split video_enable into video_enable/disableRicardo Neri2012-05-114-8/+21
| | | | | | | | | | 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>
* OMAPDSS: HDMI: Split audio_enable into audio_enable/disableRicardo Neri2012-05-114-8/+23
| | | | | | | | | | 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>
* OMAPDSS: TFP410: use gpio_set_value_cansleepRuss Dill2012-05-111-2/+2
| | | | | | | | | 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>
* OMAPDSS: separate pdata based initializationTomi Valkeinen2012-05-116-80/+119
| | | | | | | 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>
* OMAPDSS: DSI: improve DSI module id handlingTomi Valkeinen2012-05-111-25/+21
| | | | | | | | | | | | | | | | 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>
* OMAPDSS: init omap_dss_devices internallyTomi Valkeinen2012-05-118-56/+42
| | | | | | | 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>
* OMAPDSS: interface drivers register their panel devicesTomi Valkeinen2012-05-118-36/+122
| | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: change default_device handlingTomi Valkeinen2012-05-111-5/+9
| | | | | | | | | | | | | | | | | | | | 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>
* OMAPFB: add __init & __exitTomi Valkeinen2012-05-111-5/+4
| | | | | | Change omapfb to use platform_driver_probe and add __init & __exit. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add __init & __exitTomi Valkeinen2012-05-1110-56/+56
| | | | | | | 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>
* OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdiTomi Valkeinen2012-05-116-12/+6
| | | | | | | | 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>
* OMAPDSS: move the creation of debugfs filesTomi Valkeinen2012-05-118-74/+48
| | | | | | | | 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>
* OMAPDSS: handle output-driver reg/unreg more dynamicallyTomi Valkeinen2012-05-112-93/+59
| | | | | | | | 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>
* OMAPDSS: remove uses of dss_runtime_get/putTomi Valkeinen2012-05-119-99/+11
| | | | | | | | | 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>
* OMAPDSS: create DPI & SDI driversTomi Valkeinen2012-05-115-41/+71
| | | | | | | | | | | | | | | 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>
* OMAPDSS: use platform_driver_probe for core/dispc/dssTomi Valkeinen2012-05-113-6/+3
| | | | | | | | 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>
* OMAPDSS: remove return from platform_driver_unregTomi Valkeinen2012-05-116-6/+6
| | | | | | | | | 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>
* OMAPDSS: clean up the omapdss platform data messTomi Valkeinen2012-05-115-35/+43
| | | | | | | | | | | | | | | | | 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>
* OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->idTomi Valkeinen2012-05-111-3/+3
| | | | | | | | 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>
* OMAPDSS: TFP410: pdata rewriteTomi Valkeinen2012-05-111-34/+38
| | | | | | | | 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>
* OMAPFB: fix parsing of vram parameterTomi Valkeinen2012-05-111-1/+1
| | | | | | | | | | | | | 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>
* OMAPDSS: OMAPFB: always allow to configure overlayGrazvydas Ignotas2012-05-111-2/+2
| | | | | | | | | | | | | 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>
* OMAPDSS: VENC: allow switching venc output type at runtimeGrazvydas Ignotas2012-05-111-1/+53
| | | | | | | | | | | | | | 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>
* Merge branch 'for-l-o-3.5'Tomi Valkeinen2012-05-105-128/+171
|\ | | | | | | | | | | | | | | 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.
| * OMAPDSS: DSI: implement generic DSI pin configTomi Valkeinen2012-05-092-65/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAPDSS: Taal: move reset gpio handling to taal driverTomi Valkeinen2012-05-091-0/+15
| | | | | | | | | | | | | | | | | | 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>
| * OMAPDSS: TFP410: rename dvi files to tfp410Tomi Valkeinen2012-05-092-2/+2
| | | | | | | | | | | | | | | | 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>
| * OMAPDSS: TFP410: rename dvi -> tfp410Tomi Valkeinen2012-05-093-52/+52
| | | | | | | | | | | | | | | | | | 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>
| * OMAP: board-files: remove custom PD GPIO handling for DVI outputTomi Valkeinen2012-05-091-13/+0
| | | | | | | | | | | | | | | | 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>
| * OMAPDSS: panel-dvi: add PD gpio handlingTomi Valkeinen2012-05-091-0/+31
| | | | | | | | | | | | | | | | | | | | 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>
* | OMAPDSS: DISPC: Remove usage of dispc_mgr_get_device()Archit Taneja2012-05-093-32/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | OMAPDSS: DISPC: Remove omap_dss_device pointer usage from dispc_mgr_pclk_rate()Archit Taneja2012-05-091-5/+6
| | | | | | | | | | | | | | | | | | | | | | 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>
* | OMAPDSS: APPLY: Remove an unnecessary omap_dss_device pointerArchit Taneja2012-05-091-3/+0
| | | | | | | | | | | | | | 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>
View Lorry Controller Status