aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2
Commit message (Collapse)AuthorAge
...
* OMAPDSS: remove declarations for non-existing functionsTomi Valkeinen2012-11-27
| | | | | | | Remove dispc_mgr_is_channel_enabled() and dss_mgr_get_timings() declarations, as the function doesn't exist. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge tag 'omapdss-for-3.7-rc' of git://gitorious.org/linux-omap-dss2/linuxTomi Valkeinen2012-11-26
|\ | | | | | | | | | | | | omapdss fixes for 3.7-rc Conflicts: drivers/video/omap2/dss/dss.c
| * OMAPDSS: do not fail if dpll4_m4_ck is missingAaro Koskinen2012-11-22
| | | | | | | | | | | | | | | | | | | | | | Do not fail if dpll4_m4_ck is missing. The clock is not there on omap24xx, so this should not be a hard error. The patch retains the functionality before the commit 185bae10 (OMAPDSS: DSS: Cleanup cpu_is_xxxx checks). Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPFB: Fix possible null pointer dereferencingTushar Behera2012-11-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 952cbaaa9b8beacc425f9aedf370468cbb737a2c (OMAPFB: Change dssdev->manager references) added checks for OMAPFB_WAITFORVSYNC ioctl to verify that the display, output and overlay manager exist. However, the code erroneously uses && for each part, which means that OMAPFB_WAITFORVSYNC may crash the kernel if no display, output or manager is associated with the framebuffer. This patch fixes the issue by using ||. Signed-off-by: Tushar Behera <tushar.behera@linaro.org> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: HDMI: fix missing unlock on error in hdmi_dump_regs()Wei Yongjun2012-10-26
| | | | | | | | | | | | | | | | | | Add the missing unlock on the error handling path in function hdmi_dump_regs(). Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * omapdss: dss: Fix clocks on OMAP363xLaurent Pinchart2012-10-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 185bae1095188aa199c9be64d6030d8dbfc65e0a ("OMAPDSS: DSS: Cleanup cpu_is_xxxx checks") broke the DSS clocks configuration by erroneously using the clock parameters applicable to all other OMAP34xx SoCs for the OMAP363x. This went unnoticed probably because the cpu_is_omap34xx() class check wasn't seen as matching the OMAP363x subclass. Fix it by checking for the OMAP363x subclass before checking for the OMAP34xx class. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPDSS: DSI: fix dsi_get_dsidev_from_id()Tomi Valkeinen2012-10-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If dsi_get_dsidev_from_id() is called with a DSI module id that does not exist on the board, the function will crash as omap_dss_get_output() will return NULL. This happens on omap3 boards when dumping DSI clocks, as the dumping code will try to get the dsidev for DSI modules 0 and 1, but omap3 only has DSI module 0. Also clean up the id -> output mapping, so that if the function is called with invalid module ID it will return NULL. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Archit Taneja <archit@ti.com>
* | OMAPFB: fix compilation errorTomi Valkeinen2012-11-23
| | | | | | | | | | | | | | | | | | | | | | | | omapfb compilation fails on x86 (but not on omap): drivers/video/omap2/omapfb/omapfb-ioctl.c: In function ‘omapfb_ioctl’: drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: error: ‘SZ_1M’ undeclared (first use in this function) drivers/video/omap2/omapfb/omapfb-ioctl.c:861:23: note: each undeclared identifier is reported only once for each function it appears in Fix this by including linux/sizes.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: panel-n8x0: register the DSS driver after SPI probeAaro Koskinen2012-11-22
| | | | | | | | | | | | | | | | | | Register the DSS driver after SPI probe. This simplifies the initialization. This is similar to what is being done e.g. in panel-acx565akm. Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: Add a dispc_features struct for OMAP5Archit Taneja2012-11-20
| | | | | | | | | | | | | | | | | | Add a dispc_features struct for OMAP5. Previously, OMAP5 used the same struct as OMAP4. The new struct for OMAP5 contains the updated register field offset and maximum limit for overlay manager width and height. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: Add overlay manager width and height limits as a dispc featureArchit Taneja2012-11-20
| | | | | | | | | | | | | | | | | | | | | | The overlay manager width and height vary in OMAP5 from previous OMAPs in terms of maximum limit and register field positions. Add parameters in dispc_features for these. Also remove params related to manager width and height from dss_features, as we want to maintain a feature list for individual IPs. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPFB: Delete if statement evaluating a constant.Matthias Brugger2012-11-19
| | | | | | | | | | | | | | | | Variable r is never set to any value different to zero. Delete the if statement as it will never executed. Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | Merge branch '3.8/vram-conversion' of git://gitorious.org/linux-omap-dss2/linuxTomi Valkeinen2012-11-16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: drivers/video/omap2/dss/Kconfig drivers/video/omap2/omapfb/omapfb-ioctl.c drivers/video/omap2/omapfb/omapfb-main.c Merge changes to make omapfb use common dma_alloc, and remove omap's custom vram allocator.
| * | OMAP: remove vram allocatorTomi Valkeinen2012-11-13
| | | | | | | | | | | | | | | | | | | | | OMAP specific vram allocator is no longer in use, and we can remove all the vram code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPFB: use dma_alloc_attrs to allocate memoryTomi Valkeinen2012-11-13
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use dma_alloc_attrs to allocate memory instead of omap specific vram allocator. After this we can remove the omap vram allocator. There are some downsides to this change: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support "passing" a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram". 4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | Revert "OMAPDSS: HDMI: Create platform device for audio support"Tomi Valkeinen2012-11-16
| | | | | | | | | | | | | | | | This reverts commit 14840b9a83c6a56629db2ba0ec247503e975f143. The commit breaks audio, and a new version will be applied later. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: APPLY: Remove unnecessary call to mg_clear_shadow_dirtyArchit Taneja2012-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing a manual update in dss_mgr_start_update, we clear the shadow dirty flags. Although there isn't any harm in clearing them. The need to clear them out here should never arrive. When applying configurations for a manual update manager, we never do any register writes, i.e, calls to dss_mgr_write_regs and dss_mgr_write_regs_extra never happen while applying. We do all these writes only when we call dss_mgr_start_update. Hence, there is never a time when the shadow registers are dirty. Remove the call to mg_clear_shadow_dirty. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: APPLY: Remove unnecessary variable in dss_apply_irq_handlerArchit Taneja2012-11-12
| | | | | | | | | | | | | | | | The bool was_updating is never really used for anything. It is set to the current value of mp->updating, but not used anywhere. Remove this variable. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: APPLY: Don't treat an overlay's channel out as shadow bitsArchit Taneja2012-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An overlay's channel out field isn't a shadow register. The TRM says that it's taken into effect immediately. This understanding was missing and channel out was treated as a shadow parameter, and in overlay's private data as extra info. Program channel out bits directly in dss_ovl_set_manager(). In order to do this safely, we need to be totally sure that the overlay is disabled in hardware. For auto update managers, we can assume that the overlay was truly disabled at dss_ovl_unset_manager() through the wait_pending_extra_info_updates() call. However, when unsetting manager for an overlay that was previously connected to a manager in manual update, we can't be sure if the overlay is truly disabled. That is, op->enabled might not reflect the actual state of the overlay in hardware. The older manager may require a manual update transfer to truly disable the overlay. We expect the user of OMAPDSS to take care of this, in OMAPDSS, we make sure that an overlay's manager isn't unset if there if extra_info is still dirty for that overlay. The wrong understanding of channel out bits also explains the reason why we see sync lost when changing an overlay's manager which was previously connected to a manual update manager. The following sequence of events caused this: - When we disable the overlay, no register writes are actually done since the manager is manual update, op->enabled is set to false, and the extra_info_dirty flag is set. However, in hardware, the overlay is still enabled in both shadow and working registers. - When we unset the manager, the software just configures the overlay's manager to point to NULL. - When we set the overlay to a new manager(which is in auto update) through dss_ovl_set_manager, the check for op->enabled passes, the channel field in extra info is set to the new manager. When we do an apply on this manager, the new channel out field is set in the hardware immediately, and since the overlay enable bit is still set in hardware, the new manager sees that the overlay is enabled, and tries to retrieve pixels from it, this leads to sync lost as it might be in the middle of processing a frame when we set the channel out bit. The solution to this was to ensure that user space does another update after disabling the overlay, this actually worked because the overlay was now truly disabled, and an immediate write to channel out didn't impact since the manager saw the new overlay as disabled, and doesn't try to retrieve pixels from it. Remove channel as an extra_info field. Make dss_ovl_unset_manager more strict about the overlay being disabled when detaching the manager. For overlays connected to a manual update manager, unset_manager fails if we need another update to disable the overlay. We still need to a manual update to ensure the overlay is disabled to get change the overlay's manager. We could work on doing a dummy update by using DISPC's capability to gate the different video port signals. This is left for later. Remove the comment about the sync lost issue. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DISPC: Use output width and height to calculate row/pix inc for ↵Archit Taneja2012-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | writeback When calculating row and pixel increments for graphics and video pipes, we need to consider the dimensions of the input frame to know how to read from the buffer. Hence, we need to calculate these parameters from the input to the pipeline. For writeback, the row and pixel increments need to be calculated based on the output of the writeback pipeline, i.e, the dimensions of the frame after scaling. Ensure that dispc driver uses values of out_width and out_height when calling calc_dma/calc_tiler_rotation_offset. For graphics and video pipes, the original code passed the original height as frame_height to calc_dma_rotation_offset, and not the predecimated height. This is left as it is for now. We need to figure out why pre decimated height isn't needed. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DISPC: Don't allow predecimation for writebackArchit Taneja2012-11-12
| | | | | | | | | | | | | | | | | | Since writeback writes to a buffer instead of reading from one, predecimation doesn't make sense for it. Configure the width and height predecimation limits to 1 if the plane is writeback. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DISPC: Fix calc_scaling_44xx() bugs for writeback pipelineArchit Taneja2012-11-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dispc_ovl_calc_scaling_44xx() doesn't work correctly for writeback. There are two issues with it: - the function tries to calculate pixel clock for the input plane using dispc_plane_pclk_rate(), calling this with writeback as input plane results in a BUG(), this function shouldn't be called for writeback at all. Fix this by calculating pixel clock only when we are not in mem to mem mode. - the maximum input_width is the product of the downscale ratio supported and the and the given output_width. This was calculated incorrectly by dividing output_width with maxdownscale. Fix this. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HACK: look for regulators with omap4 namesTomi Valkeinen2012-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally the omapdss driver gets the regulators using the regulator names assigned for omapdss. However, in an effort to get a minimal DSS support for DT enabled kernel on selected boards, we will add omapdss devices and platform data the old way even for DT kernel. This causes the problem that omapdss cannot find the regulators using omapdss's regulator names. This patch creates a temporary workaround for DSI and HDMI by trying to get the regulators also using native OMAP4 regulator names. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: Remove __exit macro from hdmi_uninit_displayRicardo Neri2012-11-07
| | | | | | | | | | | | | | | | | | | | | | This function is now used in the driver init path to handle probe errors properly. Thus, it may be possible to use this function outside the exit path. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Reported-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DISPC: fix sparse warningTomi Valkeinen2012-11-07
| | | | | | | | | | | | | | | | | | | | Fix sparse warning: drivers/video/omap2/dss/dispc.c:3320:6: warning: symbol 'dispc_dump_irqs' was not declared. Should it be static? Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
* | OMAPDSS: HDMI: Create platform device for audio supportRicardo Neri2012-11-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Creating the accessory devices, such as audio, from the HDMI driver allows to regard HDMI as a single entity with audio an display functionality. This intends to follow the design of drivers such as MFD, in which a single entity handles the creation of the accessory devices. Such devices are then used by domain-specific drivers; audio in this case. Also, this is in line with the DT implementation of HDMI, in which we will have a single node to describe this feature of the OMAP SoC. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: Add op to get audio DMA port address offsetRicardo Neri2012-11-06
| | | | | | | | | | | | | | | | | | It could be possible that the DMA port differs accross diferent HDMI IPs. Thus, add an IP-specific function to obtain the address offset and size of the DMA data port. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: Uninit display on device add errorRicardo Neri2012-11-06
| | | | | | | | | | | | | | The display must be uninitialized in order to free the requested GPIOs. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: Handle panel init error at probeRicardo Neri2012-11-06
| | | | | | | | | | | | | | | | | | Do not blindly assume that the panel could be initialized. While there, group mutex initialization at a single place. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: Make panel return dssdev register errorsRicardo Neri2012-11-06
| | | | | | | | | | | | | | Do not assume blindly that the DSS driver was registered successfully. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: Convert to devm_request_and_ioremapRicardo Neri2012-11-06
| | | | | | | | | | | | | | | | Using devm_request_and_ioremap provides better memory handling and improves readability. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: HDMI: Rename resource variable at probe.Ricardo Neri2012-11-06
| | | | | | | | | | | | | | Minor cleanup to give to the resource variable a more proper name. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: APPLY: Fix the usage of wait_for_completion_timeoutChuansheng Liu2012-11-06
| | | | | | | | | | | | | | | | | | | | The return value of wait_for_completion_timeout() is always >= 0 with unsigned int type. So the condition "ret < 0" or "ret >= 0" is pointless. Signed-off-by: liu chuansheng <chuansheng.liu@intel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DISPC: Fix the usage of wait_for_completion_timeoutChuansheng Liu2012-11-06
| | | | | | | | | | | | | | | | | | | | The return value of wait_for_completion_timeout() is always >= 0 with unsigned int type. So the condition "ret < 0" or "ret >= 0" is pointless. Signed-off-by: liu chuansheng <chuansheng.liu@intel.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DISPC: fix DS variable nameTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | check_horiz_timing_omap3() has a variable named 'DS'. i386 uses DS name for something else, causing a compilation error. As 'DS' is not a very good local variable name in the first place, let's change it to 'ds', fixing the issue. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DPI: always use DSI PLL if availableTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | | | We currently get the decision whether to use PRCM or DSI PLL clock for DPI from the board file. This is not a good way to handle it, and it won't work with device tree. This patch changes DPI to always use DSI PLL if it's available. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DPI: verify if DSI PLL is operationalTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | | | | | The SoCs that have DSI module should have a working DSI PLL. However, some rare boards have not connected the powers to the DSI PLL. This patch adds a function that tries to power up the DSI PLL, and reports if that doesn't succeed. DPI uses this function to fall back to PRCM clocks if DSI PLL doesn't work. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pllTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we can just check if dpi.dsidev != NULL. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: hide dss_select_dispc_clk_source()Tomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dss.c currently exposes functions to configure the dispc source clock and lcd source clock. There are configured separately from the output drivers. However, there is no safe way for the output drivers to handle dispc clock, as it's shared between the outputs. Thus, if, say, the DSI driver sets up DSI PLL and configures both the dispc and lcd clock sources to that DSI PLL, the resulting dispc clock could be too low for, say, HDMI. Thus the output drivers should really only be concerned about the lcd clock, which is what the output drivers actually use. There's lot to do to clean up the dss clock handling, but this patch takes one step forward and removes the use of dss_select_dispc_clk_source() from the output drivers. After this patch, the output drivers only configure the lcd source clock. On omap4+ the dispc src clock is never changed from the default PRCM source. On omap3, where the dispc and lcd clocks are actually the same, setting the lcd clock source sets the dispc clock source. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: setup default dss fckTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't currently set the dss fck when starting up. This is not a problem, as we setup the fck later when configuring the pixel clocks. Or this is how it was for omap2, for the rest of the omaps this may not be so. For DSI, HDMI and also for DPI when using DSI PLL, we don't need to change the dss fck, and thus it may be left unconfigured. Usually the dss fck is already setup fine by default, but we can't trust this. This patch sets the dss fck to maximum at probe time. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: add dss_calc_clock_rates() backTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | dss_calc_clock_rates() was removed earlier as it was not used, but it is needed for DSI PLL calculations, so this patch adds it back. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DSI: workaround for HSDiv problemTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | It looks like on many OMAP versions powers for both HSClk and HSDiv to be enabled to have a functional HSDiv. This patch fixes the issue by forcing both powers on. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: DSI: skip odd dividers when pck >= 100MHzTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI PLL and HSDivider can be used to generate the pixel clock for LCD overlay manager, which then goes to DPI output. On the DPI output pin the voltage of the signal is shifted from the OMAP's internal minimal voltage to 1.8V range. The shifting is not instant, and the higher the clock frequency, the less time there is to shift the signal to nominal voltage. If the HSDivider's divider is greater than one and odd, the resulting pixel clock does not have 50% duty cycle. For example, with a divider of 3, the duty cycle is 33%. When combining high frequency (in the area of 140MHz+) and non-50% duty cycle, it has been observed the the shifter does not have enough time to shift the voltage enough, and this leads to bad signal which is rejected by monitors. As a workaround this patch makes the divider calculation skip all odd dividers when the required pixel clock is over 100MHz. The limit of 100MHz is a guesstimate. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: fix DPI & DSI init orderTomi Valkeinen2012-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver is added first, which causes DPI initialization to fail when it tries to get the DSI PLL. This patch changes the init order to fix this. A better solution would be to separate DSI PLL and DSI drivers. They have dependencies, though, but we could still have DSI PLL as an independent entity that we could initialize before any of the output drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | Merge branch '3.8/misc-2'Tomi Valkeinen2012-11-05
|\ \ | | | | | | | | | Merge omapdss miscellaneous patches.
| * | OMAPDSS: DISPC: remove dssdev depependency from error handlerTomi Valkeinen2012-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dispc error handler tries to "fix" issues by disabling and enabling panel. This is problematic, as we're trying to remove the dependency from omapdss to the omap_dss_devices. It's also racy, and doesn't really fix anything. This patch removes the use of omap_dss_device from the error handler, and just disables and enables the associated overlay manager. This should produce similar results as the previous solution, without using dssdev. However, the error handling is still horrible. But the problem boils down to one question, to which I don't have a clear answer: what to do when a HW error happens? Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: DISPC: fix loop in error handlerTomi Valkeinen2012-10-29
| | | | | | | | | | | | | | | | | | | | | | | | The dispc's error handler has a loop inside another loop, and both use the same loop variable. This is clearly wrong, and this patch makes a new variable for the inner loop. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: fix DSI2 PLL clk namesTomi Valkeinen2012-10-29
| | | | | | | | | | | | | | | | | | | | | dss_generic_clk_source_names is missing the names for clocks from DSI2 PLL. Add them. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPFB: improve mode selection from EDIDTomi Valkeinen2012-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current omapfb code goes over all the modes found from the monitors EDID data, and searches for a mode that is compatible with the DSS hardware and has the highest x-res. While this works ok as such, it proves problematic when using DSI PLL for pixel clock. Calculating DSI PLL dividers is not the fastest of the operations, and while doing it for one mode is usually ok, doing it for 20 modes is noticable. Also, the first mode given in the EDID data should be the native mode of the monitor, and thus also the best mode, so if that can be used, no need to look further. This patch changes the code to use the first mode that is compatible with the DSS hardware. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPFB: remove use of extended edid blockTomi Valkeinen2012-10-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It seems that using the second EDID block causes more problems than is of any help. The first mode in the extended block will get FB_MODE_IS_FIRST set, which will override the first mode from the first EDID block, thus making the default videomode selection not to work properly. This patch removes the use of the extended edid block for now. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-10-22 14:52:14 -0400