summaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2
Commit message (Collapse)AuthorAgeFilesLines
* OMAP: DSS2: HDMI: fix hdmi clock nameTomi Valkeinen2011-08-011-2/+2
| | | | | | | | The HDMI clock (hdmi_clk) is missing in the current OMAP4 HWMOD database. Fix this in the DSS driver by using the old clock name (dss_48mhz_clk). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* HACK: OMAP: DSS2: clk hack for OMAP2/3Tomi Valkeinen2011-08-015-3/+19
| | | | | | | | | | | | The HWMOD data for OMAP2 and 3 are currently not up to date regarding DSS (OMAP4 HWMOD data is fine). This patch makes the DSS driver to get the opt clocks needed for OMAP2/3 with the old clock names, thus allowing DSS driver to use runtime PM. The HWMOD databases should be fixes ASAP, and this patch can be reverted after that. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSS: Fix context save/restoreTomi Valkeinen2011-07-251-0/+10
| | | | | | | | | | The current method of saving and restoring the context could cause a restore before saving, effectively "restoring" zero values to registers. Add ctx_valid field to indicate if the saved context is valid and can be restored. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DISPC: Fix context save/restoreTomi Valkeinen2011-07-251-59/+38
| | | | | | | | | | | | | | The current method of saving and restoring the context could cause a restore before saving, effectively "restoring" zero values to registers. Add ctx_valid field to indicate if the saved context is valid and can be restored. Also restructure the code to save the ctx_loss_count in save_context(), which makes more sense than the previous method of storing new ctx_loss_count in dispc_need_ctx_restore. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Remove ctx loss count from dss.cTomi Valkeinen2011-07-251-61/+1
| | | | | | | | | | | dss.c only saves 1 register (3 in OMAP3) so the extra overhead from need_ctx_restore & co. is probably bigger than the time spent saving and restoring those few registers every time. So remove the code from dss.c and restore context every time dss has been off. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DISPC: remove finegrained clk enables/disablesTomi Valkeinen2011-07-251-146/+19
| | | | | | | | | | | | dispc.c enables and disables clocks in almost every function to make sure the clocks are enabled when the function is called. This is rather unoptimal way to handle the problem. With pm_runtime other components have to call dispc_runtime_get() to enable dispc clocks before calling any other dispc functions. Thus the finegrained clk enables/disables can be removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Use PM runtime & HWMOD supportTomi Valkeinen2011-07-2511-634/+923
| | | | | | | | | | | | Use PM runtime and HWMOD support to handle enabling and disabling of DSS modules. Each DSS module will have get and put functions which can be used to enable and disable that module. The functions use pm_runtime and hwmod opt-clocks to enable the hardware. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Remove CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESETTomi Valkeinen2011-07-252-25/+0
| | | | | | | | CONFIG_OMAP2_DSS_SLEEP_BEFORE_RESET is used to avoid an unclear bug at DSS reset time. The pm runtime will handle reset in the future, and this code has to be removed. Hopefully we won't see this error anymore. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Remove core_dump_clocksTomi Valkeinen2011-07-251-40/+0
| | | | | | | | | | | | Currently dss.c does all the low level clock handling in the DSS, and thus it contains pointers to all the clocks. This allows dss.c to dump the clock information for all the clocks. With pm_runtime this is no longer the case, as each submodule will handle its clocks independently. Thus remove the core_dump_clocks function as it cannot be used with pm_runtime. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DPI: remove unneeded SYSCK enable/disableTomi Valkeinen2011-07-251-8/+3
| | | | | | | | | | DSI PLL requires sys_clk to function, and DPI enables sys_clk when it wants to use DSI PLL. However, DSI PLL code already handles enabling sys_clk, so DPI's sys_clk code is extra. Remove the unneeded sys_clk handling from dpi.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: rewrite use of context_loss_countTomi Valkeinen2011-07-252-25/+47
| | | | | | | | | | | | | | | The function to get device's context loss count has changed from omap_pm_get_last_off_on_transaction_id() to omap_pm_get_dev_context_loss_count() Change name of the function pointer in omapdss.h accordingly, and use the term "context loss count" instead of "context id" in the code. Restructure the context loss count functions to handle errors properly, and ensure that context is always considered lost if an error happens. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Remove clk optimization at dss initTomi Valkeinen2011-07-251-4/+0
| | | | | | | | | | DSS enables core clocks for the duration of initialization to avoid unnecessary context saves and restores. With PM runtime the clocks cannot be handled in this way, outside the dss module drivers. Thus we need to remove the optimization. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Fix init and unit sequenceTomi Valkeinen2011-07-251-9/+8
| | | | | | | | | | | The initialization order of the DSS modules is important when pm_runtime support is implemented. Currently RFBI is initialized before DISPC, which will cause problems with pm_runtime as RFBI uses DISPC. The same goes for uninitialization order, and dss_uninit needs to be called last, and dispc_uninit just before that. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Clean up probe for DSS & DSITomi Valkeinen2011-07-252-106/+69
| | | | | | | | | | Both dss.c and dsi.c had a probe function, which was almost a dummy one, calling dss_init() and dsi_init(). Remove the init functions by moving the initialization code into probe functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Handle dpll4_m4_ck in dss_get/put_clocksTomi Valkeinen2011-07-251-26/+26
| | | | | | | Get and put for dpll4_m4_ck was handled in dss_init/dss_exit. Move the code to dss_get/put_clocks(), which is a better place to handle it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Fix FIFO threshold and burst size for OMAP4Tomi Valkeinen2011-07-017-40/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DMA FIFO threshold registers and burst size registers have changed for OMAP4. The current code only handles OMAP2/3 case, and so the values are a bit off for OMAP4. A summary of the differences between OMAP2/3 and OMAP4: Burst size: OMAP2/3: 4 x 32 bits / 8 x 32 bits / 16 x 32 bits OMAP4: 2 x 128 bits / 4 x 128 bits / 8 x 128 bits Threshold size: OMAP2/3: in bytes (8 bit units) OMAP4: in 128bit units This patch fixes the issue by creating two new helper functions in dss_features: dss_feat_get_buffer_size_unit() and dss_feat_get_burst_size_unit(). These return (in bytes) the unit size for threshold registers and unit size for burst size register, respectively, and are used to calculate correct values. For the threshold size the usage is straightforward. However, the burst size register has different multipliers for OMAP2/3 and OMAP4. This patch solves the problem by defining the multipliers for the burst size as 2x, 4x and 8x, which fit fine for the OMAP4 burst size definition (i.e. burst size unit for OMAP4 is 128bits), but requires a slight twist on OMAP2/3 by defining the burst size unit as 64bit. As the driver in practice always uses the maximum burst size, and no use case currently exists where we would want to use a smaller burst size, this patch changes the driver to hardcode the burst size when initializing DISPC. This makes the threshold configuration code somewhat simpler. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSI: sync when disabling a displayTomi Valkeinen2011-07-012-4/+6
| | | | | | | | | | | | When the panel driver calls omapdss_dsi_display_disable() it is possible that there are still some unsent packets in the TX fifo. Add dsi_sync_vc() calls in the beginning of omapdss_dsi_display_disable() to make sure the TX fifos are empty. This allows us to remove the msleep(10) hack from panel-taal.c Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add Color Phase Rotation supportTomi Valkeinen2011-07-013-0/+151
| | | | | | | | | | | | | Add Color Phase Rotation (CPR) support and sysfs files to enable CPR and to set the CPR coefficient matrix. CPR is enabled via manager?/cpr_enable file, and the coefficient matrix is set via manager?/cpr_coef file. The values in cpr_coef are in the following order: RR RG RB GR GG GB BR BG BB Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS: Minor cleanup in ovl and mgr cache structsNishant Kamat2011-07-011-96/+62
| | | | | | | | | | The overlay_cache_data and manager_cache_data structs include the elements of omap_overlay_info and omap_overlay_manager_info structs respectively. Include the structs instead of the individual elements to reduce code. Signed-off-by: Nishant Kamat <nskamat@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add new FEAT definitions for features missing from OMAP2Tomi Valkeinen2011-07-014-58/+105
| | | | | | | | OMAP2 doesn't have CPR, PRELOAD nor FIR_COEF_V registers. Add new feature definitions for those, and check the feature before accessing those registers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add FEAT_VENC_REQUIRES_TV_DAC_CLKTomi Valkeinen2011-07-013-7/+13
| | | | | | | | | | | OMAP3430 requires an 96MHz clock to VENC's DAC, but no other OMAP needs it. Add a new feature, FEAT_VENC_REQUIRES_TV_DAC_CLK, which tells if the clock is needed on this platform, and use that feature in venc.c to decide if the clock needs enabling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Reset LANEx_ULPS_SIG2 bits after useTomi Valkeinen2011-07-011-0/+4
| | | | | | | | | | | LANEx_ULPS_SIG2 bits are left on after entering ULPS. This doesn't cause any problems currently, as DSI HW is reset when it is enabled. However, if the reset is not done, operation fails if the bits are still set. So reset the bits after entering ULPS to ensure operation even without HW reset. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Taal: Make driver more fault tolerantTomi Valkeinen2011-07-011-12/+21
| | | | | | | | | | | | | | | | | If ULPS exit fails, and the following reset fails also, Taal driver was left in state where it thinks DSI is enabled while it really isn't, leading to crash. This patch checks the return value of taal_panel_reset, and if that fails, ulps_enabled is left true, causing the driver to retry ulps exit later. Also the return value of taal_wake_up is checked at taal_disable, and if wake up fails, we'll skip the power_off. This could leave the panel into a not-quite-valid state, but there's nothing we can do about it in that situation. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: remove update_mode from omapdssTomi Valkeinen2011-07-014-124/+14
| | | | | | | | Remove the whole update_mode stuff from omapdss driver. If automatic update for manual update displays is needed, it's better implemented in higher layers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: OMAPFB: Implement auto-update modeTomi Valkeinen2011-07-014-56/+202
| | | | | | | | | | | | | | | | | | | | | Implement auto-update mode for manual-update displays. omapfb driver uses a delayed work to update the display with a constant rate. The update mode can be changed via OMAPFB_SET_UPDATE_MODE ioctl, which previously called omapdss but is now handled inside omapfb, and a new sysfs file, "update_mode". The update interval is by default 20 times per second, but can be changed via "auto_update_freq" module parameter. There is also a new module parameter "auto_update", which will make omapfb start manual update displays in auto-update mode. This auto-update mode can be used for testing if the userspace does not support manual update displays properly. However, it is a very inefficient solution, and should be considered more as a hack for testing than something that could be used as a long term solution. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: OMAPFB: Add struct to store per-display dataTomi Valkeinen2011-07-012-21/+34
| | | | | | | | | | Create a new struct omapfb_display_data to contain omapfb's private per-display data. Move the bpp override there. This struct will be used to hold auto/manual update state of a display in the following patches. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSI: Change dummy macros to inline functionsTomi Valkeinen2011-07-011-3/+12
| | | | | | | | | | Using empty macros for performance measurement functions when DSS DEBUG is not enabled causes an unused variable warning. Change the empty macros to empty inline functions to remove the warning. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: remove extra includes from include/video/omapdss.hTomi Valkeinen2011-07-014-0/+4
| | | | | | | | | omapdss.h included platform_device.h and atomic.h, neither of which is needed by omapdss.h. Remove those includes from omapdss.h, and fix the affected .c files which did not include platform_device.h even though they should. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add support for NV12 formatAmber Jain2011-05-233-34/+175
| | | | | | | | | | | | | | | | | | | | Add the support for NV12 color format. Configure base address for UV component of NV12 color format. Change the way chroma scaling is handled for YUV formats on OMAP4 by enabling chroma-resampling for video pipeline and hence using FIR2 register set for scaling UV. Changes to _dispc_set_scaling(), because of the reason above, are: - call _dispc_set_scaling_common() to handle scaling for all color formats except for OMAP4 where it only handles scaling for RGB or Y-component - call _dispc_set_scaling_uv() for special handling required for UV component on OMAP4. - dispc_set_scaling_uv() also resets chroma-resampling bit for RGB color modes. Contains chroma scaling (_dispc_set_scaling_uv) design and implemented by Lajos Molnar <molnar@ti.com> Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add new registers for NV12 supportAmber Jain2011-05-234-2/+349
| | | | | | | | | | | | | | | | | Add new registers specific to UV color component that are introduced in OMAP4. Add simple helper functions to configure the newly added registers. These new registers are mainly: - UV base address registers used specifically for NV12 color-format - FIR registers used for UV-color-component scaling on OMAP4 - Accumulator registers used for UV-color-component scaling Add these new registers to save/restore and DUMPREG functions. Also add two new features for OMAP4: - FEAT_HANDLE_UV_SEPARATE - this is used on OMAP4 as UV color-component requires separate handling. - FEAT_ATTR2 - this is used on OMAP4 to configure new ATTRIBUTES2 register. Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Use for loop where ever possible in SR(), RR()Amber Jain2011-05-231-128/+46
| | | | | | | | Use for loop instead of individual entries for OVL_FIR_COEF_H, OVL_FIR_COEF_HV, OVL_FIR_COEF_V and OVL_CONV_COEF in SR() and RR(). Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Ensure non-zero FIR values are configuredAmber Jain2011-05-231-11/+4
| | | | | | | | | | | | | FIR values can never be zero as per TRM, and the current code writes zero when scaling is not used. It was not causing any problem as scaling was disabled when zero was written. Its still safer to not write zero to it in any case. Now we configure correct FIR values even when scaling is not used (i.e. set FIR to 1024 when scaling is not used), but the scaling enable bits are still kept off if the scaling is not needed. Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add new color formats for OMAP4Amber Jain2011-05-233-34/+117
| | | | | | | | | Add new color formats supported by OMAP4: NV12, RGBA16, RGBX16, ARGB16_1555, XRGB16_1555. NV12 color format is defined here, its support in DSS will be added separately. Signed-off-by: Amber Jain <amber@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP4: DSS2: HDMI: Implement ASoC Codec driver for HDMI audioRicardo Neri2011-05-191-0/+217
| | | | | | | | | | | | | | Implement an ASoC Codec Driver to handle audio configuration. The implementation offers an interface for audio configuration and control to be exposed to ALSA while hidding the HDMI details. The ASoC driver supports the Basic Audio configuration as described in CEA-861-D: 2-channel linear PCM with 32, 44.1 and 48kHz sample rates and 16 bits/sample. It additionally supports 24 bit/sample in 32-bit words. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP4: DSS2: HDMI: Add functionality for audio configurationRicardo Neri2011-05-191-0/+215
| | | | | | | | | | Add functionality for relevant audio configuration. Functions to configure the audio FIFO and DMA as well as functions for the audio core and Audio Info frame are included. This functionality is to be used by the ASoC HDMI audio codec. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP4: DSS2: HDMI: Add enums and structures for audioRicardo Neri2011-05-191-2/+218
| | | | | | | | Add enurations and structures for audio configuration. This includes enumerations for the Audio InfoFrame, I2S, audio FIFO and audio core. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP4: DSS2: HDMI: Add DSS feature for CTS calculationRicardo Neri2011-05-192-1/+2
| | | | | | | | | | | | CTS and N parameters are used to regenerate the audio clock from the TMDS clock at the HDMI sink. In OMAP4430 ES1.0 version the calculation of the CTS parameter is done by the HDMI IP (hardware mode) while in others it must be done by the HDMI driver (software mode). A DSS feature is used to indicate the HDMI driver which mode is used. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP4: DSS2: Create a DSS features structure for OMAP4430 ES1.0Ricardo Neri2011-05-191-1/+26
| | | | | | | | | | | | | | Create a separate DSS features structure for OMAP4430 ES1.0. This structure is used to expose features only present in such silicon version. Specifically, this is required to handle how the HDMI IP calculates the CTS parameter for audio clock regeneration packets. OMAP4430 ES1.0 is the only one that supports computation of the CTS parameter by the HDMI IP (hardware mode). The rest of the revisions require the HDMI driver to perform the computation. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSI: Get line buffer size from DSI_GNQ registerArchit Taneja2011-05-161-4/+32
| | | | | | | | | The line buffer sizes vary across DSI modules, create a function dsi_get_line_buf_size() using DSI_GNQ register to get the size of line buffer used for the DISPC video port data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSI: Get number of DSI data lanes using DSI_GNQ registerArchit Taneja2011-05-163-10/+91
| | | | | | | | | | | | | | On OMAP3, the DSI module has 2 data lanes. On OMAP4, DSI1 has 4 data lanes and DSI2 has 2 data lanes. Introduce function dsi_get_num_data_lanes() which returns the number of data lanes on the dsi interface, introduce function dsi_get_num_data_lanes_dssdev() which returns the number of data lanes used by the omap_dss_device connected to the lanes. Use the DSI_GNQ register on OMAP4 to get the number of data lanes, modify dsi.c to use the number of lanes and the extra data lanes on DSI1. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSI: Use system workqueue for delayed work instead of a private ↵Archit Taneja2011-05-161-18/+7
| | | | | | | | | | | | | | workqueue In the previous DSI driver design, a private workqueue was needed to prevent a deadlock as explained in the commit : 0f16aa0ae6b84d7ae72fbe8999e6a94cb78edd4e . In the current design, the workqueue is only used for queueing delayed work in the case where we don't get a FRAMEDONE interrupt for 250 milliseconds. It is safe to remove the private workqueue amd use the system workqueue instead to schedule the delayed work with the new design where the deadlock can't occur. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSI: Remove DISPC pixel clock related info in dsi_dump_clocks()Archit Taneja2011-05-161-5/+0
| | | | | | | | | dsi_dump_clocks() prints lck and pck rates for the DISPC channel which it is connected to. Remove this since it is already printed by dispc_dump_clocks() in debugfs. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: OMAPFB: Reduce stack usageTomi Valkeinen2011-05-121-34/+61
| | | | | | | | | | omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct fb_ops allocated from stack. This caused the stack usage grow quite high. Use kzalloc to allocate the structs instead. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: OMAPFB: remove dead codeTomi Valkeinen2011-05-121-29/+0
| | | | | | Remove old unused code lying inside #if 0. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: RFBI: cleanupTomi Valkeinen2011-05-122-128/+3
| | | | | | | The RFBI driver is quite messy. Remove dead and unneeded code and add statics to functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: RFBI: add omap_rfbi_configureTomi Valkeinen2011-05-121-1/+7
| | | | | | | Add omap_rfbi_configure() which the panel driver can use to reconfigure the data element size and the number of data lines in the RFBI bus. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: RFBI: clock enable/disable changesTomi Valkeinen2011-05-121-24/+4
| | | | | | | | | | | | RFBI enables and disables clocks inside almost every function to get a finegrained control to the clocks. However, the current understanding is that this is not necessary power-management-wise. Change the clocking scheme so that RFBI clocks are enabled when the omapdss_rfbi_display_enable is called, and disabled when omapdss_rfbi_display_disable is called. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: RFBI: add rfbi_bus_lockTomi Valkeinen2011-05-121-0/+16
| | | | | | | Add similar bus lock to RFBI as is in DSI. The panel driver can use the bus lock to mark that the RFBI bus is currently in use. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add missing dummy functionsTomi Valkeinen2011-05-121-0/+24
| | | | | | | dpi.c does not compile if DSI is not compiled in. Add the missing dummy functions so that dpi.c compiles. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Taal: Use device name in backlight_device_registerArchit Taneja2011-05-121-2/+2
| | | | | | | | | | | | | Panel Taal driver uses the string "taal" to register for a backlight device. This causes backlight_device_register() to fail when a second taal panel is added. Use dev_name(&dssdev->dev) as a parameter instead of the string. Note: This will break backlight related sysfs commands. Use the name as generated by the DSS2 driver, in the form "displayi", which represents the ith registered display device. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OpenPOWER on IntegriCloud