- 30 Sep, 2011 40 commits
-
-
Archit Taneja authored
dispc_mgr_pclk_rate() is used to calculate minimum required functional clock for scaling in calc_fclk() and calc_fclk_five_taps(). This function returns the correct pixel clock for LCD and LCD2 managers, but not for TV manager. Extend this function so that it gets the correct pixel clock for TV manager. This also prevents the crash we get when we try to scale overlays connected to TV manager. The current code leads to a BUG() being executed if we call dispc_mgr_pclk_rate() for the TV manager. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Archit Taneja authored
Create a helper function called dispc_mgr_is_lcd() which returns true if the manager is LCD or LCD2. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Archit Taneja authored
dispc_ovl_enable_replication() and dispc_ovl_set_fifo_threshold() are currently called in configure_overlay(). These are the only functions which cause DISPC register writes of overlay parameters outside of dispc_ovl_setup(). Move these to dispc_ovl_setup() and pass replication, fifo_low and fifo_high thresholds as arguments to dispc_ovl_setup() in order to be aligned with other overlay parameters. No functional changes are made. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Archit Taneja authored
dispc_ovl_setup() currently takes a large number of overlay arguments, most of these are members of the overlay_info struct. Replace these arguments by passing a overlay_info pointer instead. In configure_overlay(), we create an overlay_info struct called new_oi, this is a copy of the overlay cache's overlay_info member. Update the new_oi parameters which could have been possibly changed in configure_overlay(). Pass its pointer pointer to dispc_ovl_setup(). Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Use the new read_edid() function to get EDID information from the display (when available), and use the information to use a suitable mode at initialization time. Hot-plug is not yet supported, so the timings selected at init time will stay even if the monitor would be changed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Add i2c bus number for DVI output for boards with DVI output where the i2c bus has been confirmed to be connected and working. The driver uses this to detect if a panel is connected and to read EDID. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Remove the "generic" panel config entry, which is not used. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
OMAP3 Stalker board has definitions for LCD, but uses the generic driver without any information what kind of LCD it has. The board should use a particular panel type from panel-generic-dpi driver, not the generic one. As I haven't gotten response the signer-off of stalker board about the issue, this patch removes the LCD support from the board file. This will allow us to clean up the panel-generic-dpi driver and make it support only fixed size panels. CC: Jason Lam <lzg@ema-tech.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Multiple OMAP3/4 boards have a DVI framer output. This patch makes the boards use the new panel-dvi driver, instead of the panel-generic-dpi driver. Separate drivers for fixed size panels and DVI framer gives us cleaner driver code. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
Implement detect() by checking the hot plug detect status. The implementation is not very good, as it always turns on the HDMI output to get the detection working. HDMI driver needs improvements so that we could enable only core parts of it. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
check_timings() is supposed to be used to verify if timings are ok or not. Currently the HDMI driver prints error messages if the timings are not ok. This is not right, as it is no error to give invalid timings to check_timings(). Remove the error prints. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Clean up reading of EDID by passing direct address to the block being read, instead of start address of the whole EDID memory area. Rewrite the loop which reads the EDID. This also fixes the checksum calculation, which used to calculate the checksum only for the first block. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Split the DDC initialization off from hdmi_core_ddc_edid() into a separate function hdmi_core_ddc_init(). This cleans up the implementation. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
OMAPFB handles EDID parsing now, using the common helper functions in fbdev. We can remove the EDID parsing from HDMI driver. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Implement read_edid() for HDMI by implementing necessary functions to hdmi.c and to hdmi_omap4_panel.c. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Currently the set_timings code for hdmi is quite strange. The display is disabled in hdmi_omap4_panel.c before setting timings, and enabled in hdmi.c after setting the timings. Furthermore, the timings were not permanent, and disabling and enabling the display would lose them. This patch makes the set_timings handling a bit better. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
detect() can be used to probe if the display is connected. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
read_edid() can be used to get the EDID information from the display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Enabling HDMI output often causes sync lost errors, and almost always causes timeout errors being printed from dispc_mgr_enable_digit_out(). The sync lost problem seems to go lessen greatly if we first enable the HDMI output, and only then enable the DISPC output. However, as this is only based on observations, the fix may not be perfect as the problem may lie somewhere else. Nevertheless, HDMI works better with this patch. This will also fix the dispc's dispc_mgr_enable_digit_out(), as the code waits for two VSYNCs after enabling the output. If the HDMI output is disabled (as it was previously), there are no VSYNCs and dispc_mgr_enable_digit_out() will print timeout errors. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
dispc_mgr_enable_digit_out() didn't handle HDMI case very well. Improve the function to use FRAMEDONETV interrupt to see when HDMI has been disabled. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Add dss_get_hdmi_venc_clk_source(), which can be used to get the value programmed with dss_select_hdmi_venc_clk_source(). This can be used to find out if the digit output is going to VENC or HDMI. For OMAP2/3 dss_get_hdmi_venc_clk_source() always returns DSS_VENC_TV_CLK. Cc: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
Add IRQ definitions for missing OMAP4 IRQs: FRAMEDONEWB, FRAMEDONETV, WBBUFFEROVERFLOW. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
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>
-
Tomi Valkeinen authored
Use default regn and regm2 dividers in the hdmi driver if the board file does not define them. Cc: Mythri P K <mythripk@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Tomi Valkeinen authored
The current driver had a hardcoded minimum value of 2 for pixel clock divisor (PCD). This doesn't seem to be right. OMAP4 TRM says that PCD can be 1 when not downscaling, and inverted pixel clock (IPC) is off. OMAP3 TRM says the same, but also in the register descriptions that PCD value 1 is invalid. OMAP2 TRM says PCD 2 is the minimum. OMAP2 is still untested, but for both OMAP3 and OMAP4 PCD of 1 seems to work fine. This patch adds a new DSS feature, FEAT_PARAM_DSS_PCD, which is used to find the minimum and maximum PCD. The minimum is set to 2 for OMAP2, and 1 for OMAP3/4. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
As the panel driver will remain generic across OMAP's renaming it to hdmi_panel.c Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
HDMI IP fundamentally has replaceable core PHY and PLL blocks. These blocks might vary across OMAP's but the end functionality such as to enable or disable PLL, PHY, function to read EDID would remain the same. Thus to make the current hdmi DSS driver compatible with different OMAP's having different IP blocks( A combination of different core, PHY, PLL blocks), function pointer approach is introduced. With function pointer, relevant IP dependent functions are mapped to the generic functions used by DSS during the initialization based on the OMAP compiled. Thus making hdmi DSS driver IP agnostic. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
Functions that are included in HDMI IP driver is renamed to have IP specific names so that it will not conflict with similar functions from other IP. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
Move HDMI IP dependent audio functions from HDMI DSS file to IP library. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
Split the current HDMI driver to move the HDMI IP dependent ( PLL/PHY/Core configuration code) to a new IP file (ti_hdmi_4xxx_ip.c. This is to separate IP dependent OMAP agnostic code from OMAP specific DSS dependent code. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
Clean up to move the EDID definition from the IP dependent header file to hdmi.c Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
Some of the header file definitions that are there in the hdmi.h are generic and can be used across OMAP's, Thus moving generic definition to new file. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
As hdmi has few additional parameters such as vsync and hsync polarity which is missing in DSS timing structure, define HDMI timings structure for hdmi to use instead of OMAP DSS timing structure. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
As the pll and the video configuration info are part of the ip_data, pll and video structures are moved to the ip_data structure. Also the pll and video configuration functions are modified accordingly to take care of the structure movement. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Mythri P K authored
As the base_address of the HDMI might differ across SoC's, offset of the HDMI logical blocks(PHY, PLL and Core) and base address procured from the platform data are passed dynamically to the functions that modify HDMI IP registers. Signed-off-by: Mythri P K <mythripk@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Archit Taneja authored
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>
-
Archit Taneja authored
dsi_vc_send_null() currently sends a long packet with data type MIPI_DSI_NULL_PACKET and packet length 4. Modify it to send a zero length long packet. This leads to sending only the long packet header and no payload packets and hence the transfer completes faster. The function can be modified later if there is a need to send null packets of a non-zero length. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Archit Taneja authored
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>
-