summaryrefslogtreecommitdiff
path: root/include/video
AgeCommit message (Collapse)Author
2012-03-12OMAPDSS: HDMI: PHY burnout fixTomi Valkeinen
commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd upstream. A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board if the HDMI PHY is kept powered on when the cable is not connected. This patch solves the problem by adding hot-plug-detection into the HDMI IP driver. This is not a real HPD support in the sense that nobody else than the IP driver gets to know about the HPD events, but is only meant to fix the HW bug. The strategy is simple: If the display device is turned off by the user, the PHY power is set to OFF. When the display device is turned on by the user, the PHY power is set either to LDOON or TXON, depending on whether the HDMI cable is connected. The reason to avoid PHY OFF when the display device is on, but the cable is disconnected, is that when the PHY is turned OFF, the HDMI IP is not "ticking" and thus the DISPC does not receive pixel clock from the HDMI IP. This would, for example, prevent any VSYNCs from happening, and would thus affect the users of omapdss. By using LDOON when the cable is disconnected we'll avoid the HW bug, but keep the HDMI working as usual from the user's point of view. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2011-11-08ARM: OMAP: HWMOD: Unify DSS resets for OMAPsTomi Valkeinen
This patch adds a custom DSS reset function used on OMAPs from OMAP2 forward. The function doesn't actually do a reset, it only waits for the reset to complete. The reason for this is that on OMAP4 there is no possibility to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets all the other DSS modules also, thus breaking the HWMOD model where every DSS module is handled independently. This fixes the problem with DSS reset on OMAP4, caused by the fact that because there's no SW reset for dss_core on OMAP4, the HWMOD framework doesn't try to reset dss_core and thus the DSS clocks were never enabled at the same time. This causes causes the HWMOD reset to fail for dss_dispc and dss_rfbi. The common reset function will also allow us to fix another problem in the future: before doing a reset we need to disable DSS outputs, which are in some cases enabled by the bootloader, as otherwise DSS HW seems to get more or less stuck, requiring a power reset to recover. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> [paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o unconditionally to avoid an error when !CONFIG_OMAP2_DSS] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-10-15Merge branch 'for-florian' of git://gitorious.org/linux-omap-dss2/linux into ↵Florian Tobias Schandinat
fbdev-next
2011-10-03OMAPDSS: DISPC: zorder support for DSS overlaysArchit Taneja
Add zorder support on OMAP4, this feature allows deciding the visibility order of the overlays based on the zorder value provided as an overlay info parameter or a sysfs attribute of the overlay object. Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is supported for the overlay or not. Use dss feature FEAT_ALPHA_FREE_ZORDER if the caps are not available. Ensure that all overlays that are enabled and connected to the same manager have different zorders. Swapping zorders of 2 enabled overlays currently requires disabling one of the overlays. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-10-03OMAPDSS: DISPC: VIDEO3 pipeline supportArchit Taneja
Add support for VIDEO3 pipeline on OMAP4: - Add VIDEO3 pipeline information in dss_features and omapdss.h - Add VIDEO3 pipeline register coefficients in dispc.h - Create a new overlay structure corresponding to VIDEO3. - Make changes in dispc.c for VIDEO3 Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-10-03OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility settingArchit Taneja
On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On OMAP4, alpha blending is always enabled by default, if the above bits are set, we switch to an OMAP3 compatibility mode where the zorder values in the pipeline attribute registers are ignored and a fixed priority is configured. Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled" for more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4 alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is expected to check for the ZORDER cap, if an overlay doesn't have this cap, the user is expected to set the parameter partial_alpha_enabled. If the overlay has ZORDER cap, the DSS2 user can assume that alpha blending is already enabled. Don't support OMAP3 compatibility mode for now. Trying to read/write to alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits. Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports alpha blending or not. Replace this with checks for VIDEO1 pipeline. Cc: linux-media@vger.kernel.org Cc: Lajos Molnar <molnar@ti.com> Signed-off-by: Archit Taneja <archit@ti.com> Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAPDSS: remove vaddr from overlay infoTomi Valkeinen
overlay_info struct, used to configure overlays, currently includes both physical and virtual addresses for the pixels. The vaddr was added to support more exotic configurations where CPU would be used to update a display, but it is not currently used and there has been no interest in the feature. Using CPU to update a screen is also less interesting now that OMAP4 has two LCD outputs. This patch removes the vaddr field, and modifies the users of omapdss accordingly. This makes the use of omapdss a bit simpler, as the user doesn't need to think if it needs to give the vaddr. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAPDSS: Add N800 panel driverTomi Valkeinen
This is a driver for N800's display, ported from the old omapfb. This is a slightly lighter version of the driver as not all features of the old driver can be ported without big changes to DSS2, and also because some of the HW features used in the old driver are unclear (e.g. the power management part). That said, the new driver works fine for basic use. Architecturally the driver is not as neat as it could be. N800's display HW consists of a display buffer chip and a panel, and ideally they would be represented by separate, independent drivers. This is not currently possible, and this driver contains both buffer chip and panel driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAPDSS: Taal: remove external backlight supportTomi Valkeinen
Taal panel driver supports two kinds of backlight control: 1) using DSI commands sent to the panel to control the backlight, 2) calling function pointers going to the board file to control the backlight. The second option is a bit hacky, and will no longer be needed when the PWM driver supports the backlight features. After that we can use the standard PWM backlight driver. This patch removes the second backlight control mechanism, and adds a boolean field, use_dsi_backlight, to nokia_dsi_panel_data which the board file can use to inform whether the panel driver should use DSI commands to control the backlight. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: add panel-dvi driverTomi Valkeinen
We have currently panel-generic-dpi driver, which is a combined driver for dummy panels and also for DVI output. The aim is to split the panel-generic-dpi into two, one for fixed size dummy panels connected via DPI, and the other (this) for variable resolution output which supports DDC channel (in practice a DVI framer chip connected to DPI output). Original i2c code by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: add detect() to omap_dss_driver structTomi Valkeinen
detect() can be used to probe if the display is connected. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: add read_edid() to omap_dss_driver structTomi Valkeinen
read_edid() can be used to get the EDID information from the display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: DISPC: Add missing IRQ definitionsTomi Valkeinen
Add IRQ definitions for missing OMAP4 IRQs: FRAMEDONEWB, FRAMEDONETV, WBBUFFEROVERFLOW. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: DSI: Add comment about regnTomi Valkeinen
regn divider is one greater than the REGN divider in TRM. Add a comment to point this out. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: HDMI: change regn definitionTomi Valkeinen
regn divider is currently programmed to the registers without change, but when calculating clock frequencies it is used as regn+1. To make this similar to how DSI handles the dividers this patch changes the regn value to be used as such for calculations, but the value programmed to registers is regn-1. This simplifies the clock frequency calculations, makes it similar to DSI, and also allows us to use regn value 0 as undefined. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: DSI Video mode supportArchit Taneja
Add initial support for DSI video mode panels: - Add a new structure omap_dss_dsi_videomode_data in the member "panel" in omap_dss_device struct. This allows panel driver to configure dsi video_mode specific parameters. - Configure basic DSI video mode timing parameters: HBP, HFP, HSA, VBP, VFP, VSA, TL and VACT. - Configure DSI protocol engine registers for video_mode support. - Introduce functions dsi_video_mode_enable() and dsi_video_mode_disable() which enable/disable video mode for a given virtual channel and a given pixel format type. Things left for later - Add functions to check for errors in video mode timings provided by panel. - Configure timing registers required for command mode interleaving. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: Create an enum for DSI pixel formatsArchit Taneja
Currently, DSI pixel info is only represented by the pixel size in bits using the pixel_size parameter in omap_dss_device struct's ctrl member. This is not sufficient information for DSI video mode usage, as two of the supported formats(RGB666 loosely packed, and RGB888) have the same pixel container size, but different data_type values for the video mode packet header. Create enum "omap_dss_dsi_pixel_format" which describes the pixel data format the panel is configured for. Create helper function dsi_get_pixel_size() which returns the pixel size of the given pixel format. Modify functions omapdss_default_get_recommended_bpp() and dss_use_replication() to use dsi_get_pixel_size(). Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: DSI: Introduce generic read functionsArchit Taneja
Introduce read functions which use generic Processor-to-Peripheral transaction types. These are needed by some devices which may not support corresponding DCS commands. Add function dsi_vc_generic_send_read_request() which can send a short packet with 0, 1 or 2 bytes of request data and the corresponding generic data type. Rename function dsi_vc_dcs_read_rx_fifo() to dsi_vc_read_rx_fifo() and modify it to take the enum "dss_dsi_content_type" as an argument to use either DCS or GENERIC Peripheral-to-Processor transaction types while parsing data read from the device. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: DSI: Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2()Archit Taneja
Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2(), these are used when the panel is expected to return 1 and 2 bytes respecitvely. This was manily used for debugging purposes. These functions should be implemented in the panel driver if needed. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: DSI: Introduce generic write functionsArchit Taneja
Intoduce enum "dss_dsi_content_type" to differentiate between DCS and generic content types. Introduce short and long packet write functions which use generic Processor-to-Peripheral transaction types. These are needed by some devices which may not support corresponding DCS commands. Create common write functions which allow code reuse between DCS and generic write functions. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: Create enum for DSI operation modesArchit Taneja
Create an enum for DSI operation modes, use this to set the capabilities of the device in dsi_init_display(). Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: Add GLOBAL_ALPHA & PRE_MULT_ALPHA to ovl capsTomi Valkeinen
Add OMAP_DSS_OVL_CAP_GLOBAL_ALPHA and OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA to overlay capabilities. Use these instead of FEAT_GLOBAL_ALPHA, FEAT_GLOBAL_ALPHA_VID1 and FEAT_PRE_MULT_ALPHA in code. Remove FEAT_GLOBAL_ALPHA_VID1 and FEAT_PRE_MULT_ALPHA which are no longer used. FEAT_GLOBAL_ALPHA is still used to decide if the HW has global alpha register. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Archit Taneja <archit@ti.com>
2011-09-30OMAP: DSS2: Remove support for non-DISPC overlaysTomi Valkeinen
Remove support for non-DISPC overlays and overlay managers. The support to possibly have non-DISPC overlays and managers was made to make it possible to use CPU and/or sDMA to update RFBI or DSI command mode displays. It is ok to remove the support, because: - No one has used the feature. - Display update without DISPC is very slow, so it is debatable if the update would even be usable. - Removal cleans up code. - If such a feature is needed later, it is better implemented outside omapdss driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Archit Taneja <archit@ti.com>
2011-09-30OMAP: DSS2: Handle manager change in applyTomi Valkeinen
Currently when changing the manager of an overlay, set_manager() directly calls dispc to set the overlay's destination. Change this to be more in line with other overlay configurations, and this will also remove the need to have dispc clocks enabled when calling set_manager(). A new field is added to overlay struct, "manager_changed". This is similar to "display_changed" field in manager struct, and is used to inform apply that the manager has changed and thus write to the registers is needed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-30OMAP: DSS2: DSI: Improve dsi_mux_pads parametersTomi Valkeinen
dsi_mux_pads() needs to know about the DSI HW module and the DSI lanes used. Split the function into two, enable and disable, which take necessary arguments, and add empty implementations for both. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-09-14OMAP: DSS2: Add picodlp panel driverMayuresh Janorkar
PicoDLP is a micro projector from TI. DLP used in OMAP4 is dpp2600 (DLP Pico Projector) The DLP requires commands to be sent over i2c for configurations. To know more about dpp2600 commands please visit: https://focus.ti.com/myti/docs/extranet.tsp?sectionId=403 The picodlp module consists of a dss driver and an i2c_client. To know more please visit: http://www.omappedia.org/wiki/PicoDLP_projector_guide Based on original design from Mythri P K <mythripk@ti.com> Signed-off-by: Mayuresh Janorkar <mayur@ti.com> Signed-off-by: Mythri P K <mythripk@ti.com> [tomi.valkeinen@ti.com: squashed commits] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-08-30Merge branch 'sh-mobile-lcdc' of git://linuxtv.org/pinchartl/fbdev into ↵Florian Tobias Schandinat
fbdev-next
2011-08-24udlfb: add more comprehensive support for DPMS FB_BLANK_* modesBernie Thompson
Fixes earlier problems where monitor would not return from blank Test with any DisplayLink-based USB 2.0 graphics adapter sudo nano /sys/class/graphics/fb?/blank and write out single digit FB_BLANK_* code from include/linux/fb.h Supports on (0), blank (1), suspend (2,3), powerdown (4) Signed-off-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
2011-08-19fbdev: sh_mobile_lcdc: Replace hardcoded register values with macrosLaurent Pinchart
Instead of hardcoding register values through the driver, define macros for individual register bits using the register name and the bit name, and use the macros. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2011-07-25OMAP: DSS2: Remove unused opt_clock_availableTomi Valkeinen
opt_clock_available() is no longer needed, so remove it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-07-25OMAP: DSS2: rewrite use of context_loss_countTomi Valkeinen
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>
2011-07-01OMAP: DSS2: Add Color Phase Rotation supportTomi Valkeinen
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>
2011-07-01OMAP: DSS2: remove update_mode from omapdssTomi Valkeinen
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>
2011-07-01OMAP: DSS2: remove extra includes from include/video/omapdss.hTomi Valkeinen
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>
2011-05-24Merge branches 'common/fbdev' and 'common/fbdev-meram' of ↵Paul Mundt
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6
2011-05-24Merge branch 'for-paul' of git://gitorious.org/linux-omap-dss2/linuxPaul Mundt
Conflicts: drivers/video/omap2/dss/dsi.c drivers/video/omap2/dss/dss_features.c drivers/video/omap2/dss/dss_features.h Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-23sh_mobile_meram: Add support for NV24 framebuffersDamian
Since the NV24 framebuffer has a CbCr plane that is twice as wide as the Y plane, it needs to be handled as a special case. Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-23sh_mobile_meram: MERAM framework for LCDCDamian
Based on the patch by Takanari Hayama <taki@igel.co.jp> Adds support framework necessary to use Media RAM (MERAM) caching functionality with the LCDC. The MERAM is accessed through up to 4 Interconnect Buffers (ICBs). ICB numbers and MERAM address ranges to use are specified in by filling in the .meram_cfg member of the LCDC platform data Signed-off-by: Damian Hobson-Garcia <dhobsong@igel.co.jp> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
2011-05-23OMAP: DSS2: Add support for NV12 formatAmber Jain
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>
2011-05-23OMAP: DSS2: Add new color formats for OMAP4Amber Jain
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>
2011-05-16OMAP: DSS2: DSI: Get number of DSI data lanes using DSI_GNQ registerArchit Taneja
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>
2011-05-12OMAP: DSS2: RFBI: add omap_rfbi_configureTomi Valkeinen
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>
2011-05-12OMAP: DSS2: RFBI: add rfbi_bus_lockTomi Valkeinen
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>
2011-05-12OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4Archit Taneja
Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol engine and DISPC Functional clock. Do the following: - Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the dsi module number as an argument. - Create debugfs files for dsi2, split the corresponding debugfs functions. - Allow DPI to use these new clock sources. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: Pass platform_device as an argument in dsi functionsArchit Taneja
The DSI interface is represented as a platform device, using the DSI platform driver(dsi.c). The current DSI driver design is capable of running only one instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which can be represented as instances of "omapdss_dsi" platform device. Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes the panel is connected to. Modify dsi.c functions to take the device's platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev() and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number respectively, and return the platform_device pointer. Currently, the dsi struct is declared globally and is accessed when dsi data is needed. The new pdev argument will be used later to provide the platform device's dsi related data. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-12OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions exported by dsiArchit Taneja
Add pointer to omap_dss_device struct as an argument in the functions which are exported to dsi panel drivers. This argument will tell the DSI driver which DSI interface's data it has to choose. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-11OMAP: DSS2: Taal: Implement ULPS functionalityTomi Valkeinen
ULPS is a low power state where the DSI lanes are kept at ground. This patch implements ULPS by having a DSI bus inactivity timer which triggers the entry to ULPS. ULPS exit will happen automatically when the driver needs to do something on the DSI lanes. The ulps_timeout is configurable from board file or via sysfs. Additionally another sysfs file, "ulps", can be used to check the current ULPS state, or to manually enter or exit ULPS. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-11OMAP: DSS2: Taal: Implement configurable ESD intervalTomi Valkeinen
ESD check in Taal driver is currently on/off feature with hardcoded interval. This patch changes it to a configurable interval, which can be set from the board file. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-11OMAP: DSS2: DSI: Add DSI pad muxing supportTomi Valkeinen
Add dsi_mux_pads function pointer to omap_dss_board_info, and use the function pointer in DSI code to configure the DSI pads either to normal DSI operation, or to pull down when in ULPS. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-05-11OMAP: DSS2: DSI: add parameter to enter ulps on disableTomi Valkeinen
Add parameter to omapdss_dsi_display_disable() which the panel driver can use to tell if the DSI lanes should be put to ULPS before disabling the interface. This can be used to skip ULPS entry in cases where the panel doesn't care about ULPS state, for example when the panel will be reset, or when the display interface will be enabled again right after the disable. This will speed up the operation considerably in cases where entering ULPS would fail with timeout, and the panel driver isn't even interested in entering ULPS. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>