aboutsummaryrefslogtreecommitdiffstats
path: root/include/video/omapdss.h
Commit message (Collapse)AuthorAge
* OMAPDSS: DSI: Fix HSYNC, VSYNC and DE polarities between DISPC and DSIArchit Taneja2012-06-29
| | | | | | | | | | | | | | | | | | For DSI operation in videomode, DISPC logic levels for the signals HSYNC, VSYNC and DE need to be specified to DSI via the fields VP_HSYNC_POL, VP_VSYNC_POL and VP_DE_POL in DSI_CTRL registers. This information is completely internal to DSS as logic levels for the above signals hold no meaning on the DSI bus. Hence a DSI panel driver should be totally oblivious of these fields. Fix the logic levels/polarities in the DISPC and DSI registers to a default value. This is done by overriding these fields in omap_video_timings struct filled by the panel driver for DISPC, and use the equivalent default values when programming DSI_CTRL registers. Also, remove the redundant polarity related fields in omap_dss_dsi_videomode_data. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Add interlace parameter to omap_video_timingsArchit Taneja2012-06-29
| | | | | | | | | | | Add a parameter called interlace which tells whether the timings are in interlaced or progressive mode. This aligns the omap_video_timings struct with the Xorg modeline configuration. It also removes the hack needed to write to divide the manager height by 2 if the connected interface is VENC. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Remove omap_panel_config enum from omap_dss_deviceArchit Taneja2012-06-29
| | | | | | | | | | | omap_panel_config contains fields which are finally written to DISPC_POL_FREQo registers. These are now held by omap_video_timings and are set when the manager timings are applied. Remove the omap_panel_config enum, and remove all it's references from panel or interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Add some new fields to omap_video_timingsArchit Taneja2012-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Some panel timing related fields are contained in omap_panel_config in the form of flags. The fields are: - Hsync logic level - Vsync logic level - Data driven on rising/falling edge of pixel clock - Output enable/Data enable logic level - HSYNC/VSYNC driven on rising/falling edge of pixel clock Out of these parameters, Hsync and Vsync logic levels are a part of the timings in the Xorg modeline configuration. So it makes sense to move the to omap_video_timings. The rest aren't a part of modeline, but it still makes sense to move these since they are related to panel timings. These fields stored in omap_panel_config in dssdev are configured for LCD panels, and the corresponding LCD managers in the DISPC_POL_FREQo registers. Add the above fields in omap_video_timings. Represent their state via new enums. Add these parameters to the omap_video_timings instances in the panel drivers. Keep the corresponding IVS, IHS, IPC, IEO, RF and ONOFF flags in omap_panel_config for now. The struct will be removed later. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Remove passive matrix LCD support (part 3)Archit Taneja2012-06-29
| | | | | | | | | | Remove omap_lcd_display_type enum The enum omap_lcd_display_type is used to configure the lcd display type in DISPC. Remove this enum and always set display type to TFT by creating function dss_mgr_set_lcd_type_tft(). Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Remove passive matrix LCD support (part 2)Archit Taneja2012-06-29
| | | | | | | | | | | Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag. We don't support passive matrix displays any more. Remove this flag from all the panel drivers. Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Add LCD3 overlay manager and Clock and IRQ supportChandrabhanu Mahapatra2012-06-29
| | | | | | | | | | | | | | | | | | | The support for LCD3 manager has been added into the manager module. LCD3 panel has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just like those in LCD and LCD2 panels. These registers control the Display Controller (DISPC) module for LCD3 output. The three LCDs support Display Serial Interface (DSI), Remote Frame Buffer Interface (RFBI) and Parallel CMOS Output Interface (DPI). These LCDs can be connected through parallel output interface using DISPC and RFBI or DPI. For serial interface DSS uses DSI. The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL register which has been enabled. The clock switch chooses between DSS_CLK and DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3, DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have been added specific to the new manager. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Add support for LCD3 channelChandrabhanu Mahapatra2012-06-29
| | | | | | | | | | | OMAP5 Display Subsystem (DSS) architecture comes with a additional LCD3 channel with its own dedicated overlay manager. The current patch adds LCD3 channel and basic register support for LCD3 channel. It adds register addresses for various Display Controller (DISPC) registers like DISPC_DEFAULT_COLOR, DISPC_TIMING_H, DISPC_DIVISORo, etc. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove enum omap_dss_overlay_managersTomi Valkeinen2012-06-28
| | | | | | | | | | | | We have two almost the same enums: omap_channel and omap_dss_overlay_managers. omap_channel is used almost everywhere, and omap_channel assigns explicit values to the enum values which are needed for proper operation. omap_dss_overlay_managers is only used in one place, so it's easy to remove it, which is what this patch does. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Support rotation through TILERChandrabhanu Mahapatra2012-05-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner. Physical memory can be mapped to a portion of OMAP's system address space called TILER address space. The TILER address space is split into 8 views. Each view represents a rotated or mirrored form of the mapped physical memory. When a DISPC overlay's base address is programmed to one of these views, the TILER fetches the pixels according to the orientation of the view. A view is further split into 4 containers, each container holds elements of a particular size. Rotation can be achieved at the granularity of elements in the container. For more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM. Rotation type TILER has been added which is used to exploit the capabilities of these 8 views for performing various rotations. When fetching from addresses mapped to TILER space, the DISPC DMA can fetch pixels in either 1D or 2D bursts. The fetch depends on which TILER container we are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts, and page mode sized containers require 1D bursts. The DSS2 user is expected to provide the Tiler address of the view that it is interested in. This is passed to the paddr and p_uv_addr parameters in omap_overlay_info. It is also expected to provide the stride value based on the view's orientation and container type, this should be passed to the screen_width parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is used to calculate the required row_inc for DISPC. x_predecim and y_predecim are also used to calculate row_inc and pix_inc thereby adding predecimation support for TILER. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Provide an interface for audio supportRicardo Neri2012-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: clean up the omapdss platform data messTomi Valkeinen2012-05-11
| | | | | | | | | | | | | | | | | 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>
* Merge branch 'for-l-o-3.5'Tomi Valkeinen2012-05-10
|\ | | | | | | | | | | | | | | 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-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: provide default get_timings function for panelsGrazvydas Ignotas2012-04-23
| | | | | | | | | | | | | | | | | | With this we can eliminate some duplicate code in panel drivers. Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and tpo-td043mtea1 gain support of reading timings over sysfs. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: add set_min_bus_tput pointer to omapdss's platform dataTomi Valkeinen2012-04-23
|/ | | | | | | | | omapdss driver needs to use the omap_pm_set_min_bus_tput(), so add a new entry for that in omapdss's platform data, and set it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Acked-by: Kevin Hilman <khilman@ti.com>
* OMAPDSS: HDMI: PHY burnout fixTomi Valkeinen2012-01-26
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: HDMI: Disable DDC internal pull upMythri P K2012-01-05
| | | | | | | | | | Disables the internal pull resistor for SDA and SCL which are enabled by default, as there are external pull up's in 4460 and 4430 ES2.3 SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@linaro.org> Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: HDMI: Move duplicate code from boardfileMythri P K2012-01-05
| | | | | | | | Move duplicate HDMI mux_init code from omap4 and panda board file to display file. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Add comments about blocking of ovl/mgr functionsTomi Valkeinen2011-12-02
| | | | | | Add comments specifying what ovl/mgr functions may block. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: remove device_changed fieldTomi Valkeinen2011-12-02
| | | | | | | omap_overlay_manager contains device_changed field, which no longer has any use. So remove the field and the few places where it is touched. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: move channel-field to extra_info setTomi Valkeinen2011-12-02
| | | | | | | | | | | | Setting overlay's output channel is currently handled at the same time as other overlay attributes. This is not right, as the normal attributes should only affect one overlay and manager, but changing the channel affects two managers. This patch moves the channel field into the "extra_info" set, handled together with enabled-status. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: move ovl->info to apply.cTomi Valkeinen2011-12-02
| | | | | | | | | | struct omap_overlayr contains info and info_dirty fields, both of which should be internal to apply.c. This patch moves those fields into ovl_priv data, and names them user_info and user_info_dirty. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: move mgr->info to apply.cTomi Valkeinen2011-12-02
| | | | | | | | | | struct omap_overlay_manager contains info and info_dirty fields, both of which should be internal to apply.c. This patch moves those fields into mgr_priv data, and names them user_info and user_info_dirty. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: rewrite overlay enable/disableTomi Valkeinen2011-12-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Overlays are currently enabled and disabled with a boolean in the struct omap_overlay_info. The overlay info is set with ovl->set_overlay_info(), and made into use with mgr->apply(). This doesn't work properly, as the enable/disable status may affect also other overlays, for example when using fifo-merge. Thus the enabling and disabling of the overlay needs to be done outside the normal overlay configuration. This patch achieves that by doing the following things: 1) Add function pointers to struct omap_overlay: enable(), disable() and is_enabled(). These are used to do the obvious. The functions may block. 2) Move the "enabled" field from struct omap_overlay to ovl_priv_data. 3) Add a new route for settings to be applied to the HW, called "extra_info". The status of the normal info and extra_info are tracked separately. The point here is to allow the normal info to be changed and applied in non-blocking matter, whereas the extra_info can only be changed when holding the mutex. This makes it possible to, for example, set the overlay enable flag, apply it, and wait until the HW has taken the flag into use. This is not possible if the enable flag would be in the normal info, as a new value for the flag could be set at any time from the users of omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: move mgr->enabled to mgr_priv_dataTomi Valkeinen2011-12-02
| | | | | | | | | | struct omap_overlay_manager contains "enabled"-field, used to track if the manager is enabled or not. This field should be internal to apply.c. This patch moves the field to mgr_priv_data, and applies the necessary locking when accessing the field. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DSI: call mgr_enable/disable for cmd mode displaysTomi Valkeinen2011-12-02
| | | | | | | | | | | | | | | | | | The current code uses dsi_video_mode_enable/disable functions to enable/disable DISPC output for video mode displays. For command mode displays we have no notion in the DISPC side of whether the panel is enabled, except when a dss_mgr_start_update() call is made. However, to properly maintain the DISPC state in apply.c, we need to know if a manager used for a manual update display is currently in use. This patch achieves that by changing dsi_video_mode_enable/disable to dsi_enable/disable_video_output, which is called by both video and command mode displays. For video mode displays it starts the actual pixel stream, as it did before. For command mode displays it doesn't do anything else than mark that the manager is currently in use. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: store overlays in a list for each managerTomi Valkeinen2011-12-02
| | | | | | | | | | | | | Current way of handling overlay-manager links is a bit strange: each manager has a static array, containing pointers to all the overlays (even those used by other managers). The overlays contain a pointer to the manager being used. This patch makes the system a bit saner: each manager has a linked list of overlays, and only the overlays linked to that manager are in the list. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: store managers in an arrayTomi Valkeinen2011-12-02
| | | | | | | | | Overlay managers are stored in a linked list. There's no need for this list, as an array would do just as fine. This patch changes the code to use an array for overlay managers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: APPLY: track whether a manager is enabledTomi Valkeinen2011-12-02
| | | | | | | | Add "enabled" field to struct omap_overlay_manager, which tells if the output is enabled or not. This will be used in apply.c in the following patches. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hide manager's enable/disable()Tomi Valkeinen2011-12-02
| | | | | | | | | | | omap_overlay_manager struct contains enable() and disable() functions. However, these are only meant to be used from inside omapdss, and thus it's bad to expose the functions. This patch adds dss_mgr_enable() and dss_mgr_disable() functions to apply.c, which handle enabling and disabling the output. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove partial update from DSITomi Valkeinen2011-12-02
| | | | | | | | | | | | | | | | | Partial update for manual update displays has never worked quite well: * The HW has limitations on the update area, and the x and width need to be even. * Showing a part of a scaled overlay causes artifacts. * Makes the management of dispc very complex Considering the above points and the fact that partial update is not used anywhere, this and the following patches remove the partial update support. This will greatly simplify the following re-write of the apply mechanism to get proper locking and additional features like fifo-merge. This patch removes the partial update from the dsi.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* ARM: OMAP: HWMOD: Unify DSS resets for OMAPsTomi Valkeinen2011-11-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: DISPC: zorder support for DSS overlaysArchit Taneja2011-10-03
| | | | | | | | | | | | | | | | | 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>
* OMAPDSS: DISPC: VIDEO3 pipeline supportArchit Taneja2011-10-03
| | | | | | | | | | | 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>
* OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility settingArchit Taneja2011-10-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: remove vaddr from overlay infoTomi Valkeinen2011-09-30
| | | | | | | | | | | | | | | 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>
* OMAP: DSS2: add detect() to omap_dss_driver structTomi Valkeinen2011-09-30
| | | | | | detect() can be used to probe if the display is connected. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: add read_edid() to omap_dss_driver structTomi Valkeinen2011-09-30
| | | | | | read_edid() can be used to get the EDID information from the display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DISPC: Add missing IRQ definitionsTomi Valkeinen2011-09-30
| | | | | | | Add IRQ definitions for missing OMAP4 IRQs: FRAMEDONEWB, FRAMEDONETV, WBBUFFEROVERFLOW. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: DSI: Add comment about regnTomi Valkeinen2011-09-30
| | | | | | | 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>
* OMAP: DSS2: HDMI: change regn definitionTomi Valkeinen2011-09-30
| | | | | | | | | | | | | | | 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>
* OMAP: DSS2: DSI Video mode supportArchit Taneja2011-09-30
| | | | | | | | | | | | | | | | | | | | 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>
* OMAP: DSS2: Create an enum for DSI pixel formatsArchit Taneja2011-09-30
| | | | | | | | | | | | | | | | | | | 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>
* OMAP: DSS2: DSI: Introduce generic read functionsArchit Taneja2011-09-30
| | | | | | | | | | | | | | | | | | 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>
* OMAP: DSS2: DSI: Remove functions dsi_vc_dcs_read_1() and dsi_vc_dcs_read_2()Archit Taneja2011-09-30
| | | | | | | | | | 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>
* OMAP: DSS2: DSI: Introduce generic write functionsArchit Taneja2011-09-30
| | | | | | | | | | | | | 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>
* OMAP: DSS2: Create enum for DSI operation modesArchit Taneja2011-09-30
| | | | | | | | 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>
* OMAP: DSS2: Add GLOBAL_ALPHA & PRE_MULT_ALPHA to ovl capsTomi Valkeinen2011-09-30
| | | | | | | | | | | | | 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>
* OMAP: DSS2: Remove support for non-DISPC overlaysTomi Valkeinen2011-09-30
| | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-26 21:49:11 -0500