aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2
Commit message (Collapse)AuthorAge
...
| | * OMAPDSS: move dss feats to the end of dss.cTomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | Move dss_features to the end of dss.c the same way they are in dispc.c, so that we don't have to declare prototypes for static feat-related functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: Add basic omap5 features to dss and dispcArchit Taneja2012-09-24
| | | | | | | | | | | | | | | | | | | | | Add basic omap5 features for dss and dispc. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * OMAPDSS: DSI: improve DSI clock calcs for DISPCTomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit ee144e645a081daad5de1ccac77f0a0e98e6a67b added dsi_pll_calc_ddrfreq() which calculates PLL dividers based on given DSI bus clock speed. The function works ok, but it can be improved for the DISPC clock calc. The current version calculates the clock going from the PLL to the DISPC simply by setting the clock as close to DISPC maximum as possible, and the pixel clock is calculated based on that. This patch changes the function to calculate DISPC clock more dynamically, iterating through different DISPC clocks and pixel clock values, and thus we'll get more suitable pixel clocks. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | Merge omapdss single-dssdev seriesTomi Valkeinen2012-09-25
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This series contains patches that change how omapdss's panel devices (omap_dss_device) are initialized and registered. There are two patches that change behaviour, the rest are just cleanups: The patch "omap_dss_register_device() doesn't take display index" affects the number for the "displayX" sysfs files. This hopefully doesn't affect the userspace, as the number has never been a clear indication of what the particular display is. The patch "register only one display device per output" affects how panel devices are created. Currently we support multiple panels per output, i.e. you could have DVI and an LCD displays using the same DPI output, as long as the DVI and LCD are not used at the same time. This patch changes the omapdss driver to only register one display device per output. If there are multiple displays for the output, either the first one is picked or, if def_display has been defined in kernel parameters and the def_display is one of the displays for this output, the def_display is picked. See the patch for more information. OMAPDSS: alloc dssdevs dynamically OMAPDSS: cleanup dss_recheck_connections further OMAPDSS: cleanup dss_recheck_connections OMAPDSS: handle errors in dss_init_device OMAPDSS: explicitely initialize dssdev->channel for new displays OMAPDSS: register only one display device per output OMAPDSS: Add dss_get_default_display_name() OMAPDSS: omap_dss_register_device() doesn't take display index
| | * | OMAPDSS: alloc dssdevs dynamicallyTomi Valkeinen2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently create omap_dss_devices statically in board files, and use those devices directly in the omapdss driver. This model prevents us from having the platform data (which the dssdevs in board files practically are) as read-only, and it's also different than what we will use with device tree. This patch changes the model to be in line with DT model: we allocate the dssdevs dynamically, and initialize them according to the data in the board file's dssdev (basically we memcopy the dssdev fields). The allocation and registration is done in the following steps in the output drivers: - Use dss_alloc_and_init_device to allocate and initialize the device. The function uses kalloc and device_initialize to accomplish this. - Call dss_copy_device_pdata to copy the data from the board file's dssdev - Use dss_add_device to register the device. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: cleanup dss_recheck_connections furtherTomi Valkeinen2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cleanup dss_recheck_connections, move and rename it to a static dss_init_connections function inside display.c. Improve the function to return errors, and implement a matching dss_uninit_connections that can be used to free the mgr->dssdev link. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: cleanup dss_recheck_connectionsTomi Valkeinen2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dss_recheck_connections is quite a mess. With the previous commit that initializes the channel field for HDMI and VENC displays, we can greatly simplify the dss_recheck_connections. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: handle errors in dss_init_deviceTomi Valkeinen2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add error handling to dss_init_device(), which has, for some reason, been missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: explicitely initialize dssdev->channel for new displaysTomi Valkeinen2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HDMI and VENC outputs always use the DIGIT output from DISPC. The dssdev struct contains "channel" field which is used to specify the DISPC output for the display, but this was not used for HDMI and VENC. This patch fills the channel field explicitely for HDMI and VENC displays so that we can always rely on the channel field. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: register only one display device per outputTomi Valkeinen2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have boards with multiple panel devices connected to the same physical output, of which only one panel can be enabled at one time. Examples of these are Overo, where you can use different daughter boards that have different LCDs, and 3430SDP which has an LCD and a DVI output and a physical switch to select the active display. These are supported by omapdss so that we add all the possible display devices at probe, but the displays are inactive until somebody enables one. At this point the panel driver starts using the DSS, thus reserving the physcal resource and excluding the other panels. This is problematic: - Panel drivers can't allocate their resources properly at probe(), because the resources can be shared with other panels. Thus they can be only reserved at enable time. - Managing this in omapdss is confusing. It's not natural to have child devices, which may not even exist (for example, a daughterboard that is not connected). Only some boards have multiple displays per output, and of those, only very few have possibility of switching the display during runtime. Because of the above points: - We don't want to make omapdss and all the panel drivers more complex just because some boards have complex setups. - Only few boards support runtime switching, and afaik even then it's not required. So we don't need to support runtime switching. Thus we'll change to a model where we will have only one display device per output and this cannot be (currently) changed at runtime. We'll still have the possibility to select the display from multiple options during boot with the default display option. This patch accomplishes the above by changing how the output drivers register the display device. Instead of registering all the devices given from the board file, we'll only register one. If the default display option is set, the output driver selects that display from its displays. If the default display is not set, or the default display is not one of the output's displays, the output driver selects the first display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: Add dss_get_default_display_name()Tomi Valkeinen2012-09-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add function dss_get_default_display_name() which returns the name of the default display, given from the board file or via module parameters. The default display name can be used by output drivers to decide which display is the wanted one. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| | * | OMAPDSS: omap_dss_register_device() doesn't take display indexTomi Valkeinen2012-09-18
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to have all the displays of the board in one list, and we made a "displayX" directory in the sysfs, where X was the index of the display in the list. This doesn't work anymore with device tree, as there's no single list to get the number from, and it doesn't work very well even with non-DT as we need to do some tricks to get the index nowadays. This patch changes omap_dss_register_device() so that it doesn't take disp_num as a parameter anymore, but uses a private increasing counter for the display number. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * / OMAPDSS: Do not require a VDDS_DSI regulator on AM35xxRaphaël Assénat2012-09-25
| |/ | | | | | | | | | | | | | | | | | | | | | | On our AM3505 based board, dpi.c complains that there is no VDDS_DSI regulator and the framebuffer cannot be enabled. However, this check does not seem to apply to AM3505/17 chips. This patch adds new features list for AM35xxx, which is the same as for OMAP3 except the VDDS_DSI is removed. Signed-off-by: Raphael Assenat <raph@8d.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * OMAPFB: Clear framebuffers before they are registeredArchit Taneja2012-09-11
| | | | | | | | | | | | | | | | | | | | | | | | | | The framebuffers are cleared with the function omapfb_clear_fb(), which internally calls cfb_fillrect(). The boot logo is copied on to the framebuffer when the fb device is registered with fb framework. omapfb_clear_fb() is called after the framebuffer is registered, leading to the boot logo getting cleared. Clear the framebuffers using omapfb_clear_fb() before registering the framebuffer devices. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * Merge branch 'fbdev-for-linus' of git://github.com/schandinat/linux-2.6Tomi Valkeinen2012-09-11
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge omapfb and OMAP SDI fixes: * OMAPFB: fix framebuffer console colors * OMAPDSS: Fix SDI PLL locking Conflicts: drivers/video/omap2/dss/sdi.c
| * | OMAPDSS: fix dss_ovl_unset_managerTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we removed fifomerge support, we also changed dss_ovl_disable so that it doesn't wait for the hardware to be finished with the overlay. This may cause a problem when changing the overlay's manager, as changing the manager is an immediate change. Thus if the overlay is still being used by the HW when the manager is changed, there may be glitches on the screen. This patch adds a wait into dss_ovl_unset_manager, which ensures the overlays are disabled in the HW. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: fix set_timingsTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | set_timings function of DSS's output drivers are not consistent. Some of them disable the output, set the timings, and re-enable the output. Some set the timings on the fly, while the output is enabled. And some just store the given timings, so that they will be taken into use next time the output is enabled. We require the DISPC output to be disabled when changing the timings, and so we can change all the output drivers' set_timings to just store the given timings. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: Use WB fifo for GFX overlayTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP4's GFX overlay has smaller fifo than the rest of the overlays (including writeback "overlay"). This seems to be the reason for underflows in some more demanding scenarios. We can avoid the problems by using the WB fifo for GFX overlay, and vice versa. WB usage is not supported yet, but when it will, it should perform just fine with smaller fifo as there are no hard realtime constraints with WB. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: Improve fifo management codeTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP4+ allows assigning the overlay FIFOs freely, but that is not supported by omapdss yet. This patch takes a step forward by improving the fifo management to be more flexible. dispc.c is changed to keep track of the sizes of each fifo, and also the overlay using each fifo. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | Revert "OMAPDSS: APPLY: add fifo merge support funcs"Tomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit fb0119742291b6f30cd97026ee137b2d3d1f4de8. Adding fifo merge feature as an omapdss internal configuration was a mistake. We cannot hide from the users of omapdss the complexities of fifo merge. The previous commit removed fifo merge itself, and this removes the remaining fifo merge support functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | Revert "OMAPDSS: APPLY: add fifo-merge support"Tomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 1d71f42b35ed66d90a9a39bc515bb16cfe2d4a46. Adding fifo merge feature as an omapdss internal configuration was a mistake. We cannot hide from the users of omapdss the complexities of fifo merge. This commit removes the fifo merge support, which luckily is easily done as it was handled totally inside apply.c. Note that this is not a 1:1 revert, but some resolving was needed for the dss_ovl_setup_fifo. The plan is to try fifo merge again later when it is more clear how the hardware acts in various situations, and how the omapdrm wants to use fifo merge. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: clean up dss_mgr_set_timingsTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | dss_mgr_set_timings() can only be called when the output is not active. This means that most of the code in the function is extra, as there's no need to write the values to registers, etc, because that will be handled when the output will be enabled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: clean up dss_mgr_set_lcd_configTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | dss_mgr_set_lcd_config() can only be called when the output is not active. This means that most of the code in the function is extra, as there's no need to write the values to registers, etc, because that will be handled when the output will be enabled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: split manager sysfs codeTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | Separate sysfs code for managers to a separate file. This is a bit cleaner, and will allow us later to easily switch off the sysfs support via Kconfig option. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: split overlay sysfs codeTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | Separate sysfs code for overlays to a separate file. This is a bit cleaner, and will allow us later to easily switch off the sysfs support via Kconfig option. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: TFP410: use devm_gpio_request_oneTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | Use devm_ version instead of the regular gpio_request_one to simplify the error handling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: Taal: Reogranize for device treeTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | Reorganize taal driver to make it easier to integrate device tree code. Instead of storing the panel's platform data, we'll "parse" the platform data and store the required information in driver's own data. This way adding device tree data parsing is simple. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: VRAM: Remove clearing with sDMATomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently vram.c clears the allocated memory automatically using OMAP system DMA. In an effort to reduce OMAP dependencies, we'll do the memory clear with CPU from now on. The previous patch implemented memory clear in the omapfb driver, and this patch removes the now obsolete clear functionality from vram.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>
| * | OMAPFB: clear framebuffers with CPUTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently vram.c clears the allocated memory automatically using OMAP system DMA. In an effort to reduce OMAP dependencies, we'll do the memory clear with CPU from now on. This patch implements clearing of the framebuffer in omapfb, using cfb_fillrect() to do the actual clear. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: remove unnecessary includesTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | Remove unnecessary includes from omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: Taal: use devm_* functionsTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | Use devm_ functions in panel-taal.c's probe when possible. Also reorder the initialization sequence so that devm_ allocations are done before things that require explicit freeing. This simplifies the probe and remove functions. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: fix use of dssdev->capsTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recent commit dca2b1522ccab28d03fb79f6e70e70ea78033d52 (OMAPDSS: DSI: Maintain copy of operation mode in driver data) broke DSI for video mode displays. The commit changed the way dssdev->caps are initialized, and the result was that every DSI display is initialized with manual-update and tear-elim caps. The code that sets dssdev->caps is not very good, even when fixed. omapdss driver shouldn't be writing dssdev->caps at all. This patch fixes the problem with video mode displays by moving the initialization of dssdev->caps to the panel driver. The same change is done for RFBI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: DSI: calculate dsi clockTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the way to configure clocks related to DSI (both DSI and DISPC clocks) happens via omapdss platform data. The reason for this is that configuring the DSS clocks is a very complex problem, and it's impossible for the SW to know requirements about things like interference. However, for general cases it should be fine to calculate the dividers for clocks in the SW. The calculated clocks are probably not perfect, but should work. This patch adds support to calculate the dividers when using DSI command mode panels. The panel gives the required DDR clock rate and LP clock rate, and the DSI driver configures itself and DISPC accordingly. This patch is somewhat ugly, though. The code does its job by modifying the platform data where the clock dividers would be if the board file gave them. This is not how it's going to be in the future, but allows us to have quite simple patch and keep the backward compatibility. It also allows the developer to still give the exact dividers from the board file when there's need for that, as long as the panel driver does not override them. There are also other areas for improvement. For example, it would be better if the panel driver could ask for a DSI clock in a certain range, as, at least command mode panels, the panel can work fine with many different clock speeds. While the patch is not perfect, it allows us to remove the hardcoded clock dividers from the board file, making it easier to bring up a new panel and to use device tree from omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: Add DSI fclk maximum to dss_featuresTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | Add max value of DSI functional clock to dss_features, so that DSI driver can use it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: HDMI: use vdda_hdmi_dacTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The HDMI driver requires vdda_hdmi_dac power for operation, but does not enable it. This has worked because the regulator has been always enabled. But this may not always be the case, as I encountered when implementing HDMI device tree support. This patch changes the HDMI driver to use the vdda_hdmi_dac. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: HDMI: Add delay to wait for 5V powerTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | TPD12S015A spec says to wait 300us after setting CT_CP_HPD gpio for the 5V power output to reach 90% of the voltage. This patch adds the delay to the driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | OMAPDSS: HDMI: Move GPIO handling to HDMI driverTomi Valkeinen2012-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently manage HDMI GPIOs in the board files via platform_enable/disable calls. This won't work with device tree, and in any case the correct place to manage the GPIOs is in the HDMI driver. This patch moves the handling of the GPIOs to the HDMI driver. The GPIO handling is moved to the common hdmi.c file, and this probably needs to be revisited when adding OMAP5 HDMI support to see if the GPIO handling needs to be moved to IP specific files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
| * | Merge tag 'v3.6-rc4'Tomi Valkeinen2012-09-03
| |\ \ | | | | | | | | | | | | Merge 3.6-rc4 to get latest OMAP and device tree fixes.
| * | | OMAPDSS: DPI: Remove cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The OMAP3 checks have been removed and replaced by a dss feature FEAT_DPI_USES_VDDS_DSI for cleaner implementation. The patches "OMAP: DSS2: enable VDDS_DSI when using DPI" (8a2cfea8cc) by Tomi Valkeinen <tomi.valkeinen@nokia.com> and "ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c" (4041071571) by Russell King <rmk+kernel@arm.linux.org.uk> had introduced these checks. As it is evident from these patches a dependency exists for some DSS pins on VDDS_DSI which is better shown by dss feature FEAT_DPI_USES_VDDS_DSI. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: VENC: Remove cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP4 checks are removed from VENC to provide it a cleaner interface. These checks were introduced by patches "HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to prevent crash" (ba02fa37de) by Tomi Valkeinen <tomi.valkeinen@ti.com> and "OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4" (cc1d3e032d) by Danny Kukawka <danny.kukawka@bisect.de> to prevent VENC from crashing OMAP4 kernel. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: DSS: Cleanup cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the cpu_is checks have been moved to dss_init_features function providing a much more generic and cleaner interface. The OMAP version and revision specific initializations in various functions are cleaned and the necessary data are moved to dss_features structure which is local to dss.c. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: DSS: Remove redundant functionsChandrabhanu Mahapatra2012-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Functions dss_calc_clock_rates() and dss_get_clock_div() are removed as these functions have become redundant and no longer used. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: DISPC: Cleanup cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the cpu_is checks have been moved to dispc_init_features function providing a much more generic and cleaner interface. The OMAP version and revision specific functions and data are initialized by dispc_features structure which is local to dispc.c. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: HDMI: fix initial HDMI enableTomi Valkeinen2012-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 7849398fa28c21dad24292b838b059a862f99f16 introduced a bug, causing the following error to be reported: [ 370.827819] cannot lock PLL [ 370.830749] CFG1 0x1e [ 370.833160] CFG2 0x602004 [ 370.835876] CFG4 0x40000 [ 370.838562] omapdss HDMI: Failed to lock PLL However, HDMI output is still enabled. The problem is that we enable the HDMI video output temporarily when reading EDID or detecting if a HDMI cable is connected (ugh), and the commit above changes the behavior of the driver so that the video timings are not yet configured at the point when EDID is read. This patch fixes the problem by configuring the initial VGA timings at HDMI probe. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: VENC: Maintian copy of video output polarity info in private dataArchit Taneja2012-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VENC driver currently relies on the omap_dss_device struct to configure the video output polarity. This makes the VENC interface driver dependent on the omap_dss_device struct. Make the VENC driver data maintain it's own polarity field. A panel driver is expected to call omapdss_venc_invert_vid_out_polarity() before enabling the interface. Signed-off-by: Archit Taneja <archit@ti.com>
| * | | OMAPDSS: VENC: Maintain copy of venc type in driver dataArchit Taneja2012-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VENC driver currently relies on the omap_dss_device struct to configure the venc type. This makes the VENC interface driver dependent on the omap_dss_device struct. Make the VENC driver data maintain it's own 'venc type' field. A panel driver is expected to call omapdss_venc_set_type() before enabling the interface or changing the type via display sysfs attributes. Signed-off-by: Archit Taneja <archit@ti.com>
| * | | OMAPDSS: RFBI: Maitain copy of rfbi timings in driver dataArchit Taneja2012-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RFBI driver currently relies on the omap_dss_device struct to receive the rfbi specific timings requested by the panel driver. This makes the RFBI interface driver dependent on the omap_dss_device struct. Make the RFBI driver data maintain it's own rfbi specific timings field. The panel driver is expected to call omapdss_rfbi_set_interface_timings() to configure the rfbi timings before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| * | | OMAPDSS: DSI: Maintain copy of video mode timings in driver dataArchit Taneja2012-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to receive the video mode timings requested by the panel driver. This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own video mode timings field. The panel driver is expected to call omapdss_dsi_set_videomode_timings() to configure the video mode timings before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
| * | | OMAPDSS: DSI: Rename dsi_videomode_data to dsi_videomode_timingsArchit Taneja2012-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The struct omap_dss_dsi_videomode_data holds fields which need to be configured for DSI to operate in video mode. Rename the struct to dsi_videomode_timings. One reason to do this is because most of the fields in the struct are timings related. The other reason is to create a generic op for output specific timings. This generic op can be considered as a way to set custom or private timings for the output. In the case of OMAP, DSI and RFBI require some more timings apart from the relgular DISPC timings. The structs omap_dss_videomode_timings and rfbi_timings can be considered as these output specific timings respectively. Signed-off-by: Archit Taneja <archit@ti.com>
| * | | OMAPDSS: DSI: Maintain copy of operation mode in driver dataArchit Taneja2012-08-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DSI driver currently relies on the omap_dss_device struct to know the mode of operation of the DSI protocol(command or video mode). This makes the DSI interface driver dependent on the omap_dss_device struct. Make the DSI driver data maintain it's own operation mode field. The panel driver is expected to call omapdss_dsi_set_operation_mode() before the interface is enabled. Signed-off-by: Archit Taneja <archit@ti.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-10-13 03:20:43 -0400