aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2
Commit message (Collapse)AuthorAge
...
| * | | | 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
| * | OMAPFB: fix framebuffer console colorsGrazvydas Ignotas2012-08-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | omapfb does not currently set pseudo palette correctly for color depths above 16bpp, making red text invisible, command like echo -e '\e[0;31mRED' > /dev/tty1 will display nothing on framebuffer console in 24bpp mode. This is because temporary variable is declared incorrectly, fix it. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Cc: stable@vger.kernel.org # v3.x Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * | OMAPDSS: Fix SDI PLL lockingTomi Valkeinen2012-08-23
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f476ae9dab3234532d41d36beb4ba7be838fa786 (OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface) broke the SDI output, as it causes the SDI PLL locking to fail. LCLK and PCLK divisors are located in shadow registers, and we normally write them to DISPC registers when enabling the output. However, SDI uses pck-free as source clock for its PLL, and pck-free is affected by the divisors. And as we need the PLL before enabling the output, we need to write the divisors early. It seems just writing to the DISPC register is enough, and we don't need to care about the shadow register mechanism for pck-free. The exact reason for this is unknown. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* | 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.
| * Merge branch 'for-florian' of git://gitorious.org/linux-omap-dss2/linux into ↵Florian Tobias Schandinat2012-07-25
| |\ | | | | | | | | | | | | | | | | | | | | | fbdev-next Conflicts: drivers/video/omap2/dss/core.c drivers/video/omap2/dss/dispc.c
| * \ Merge branch 'fbdev-for-linus' into fbdev-nextFlorian Tobias Schandinat2012-07-08
| |\ \
| | * | OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=nTomi Valkeinen2012-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If runtime PM is not enabled in the kernel config, pm_runtime_get_sync() will always return 1 and pm_runtime_put_sync() will always return -ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to print a warning. One option would be to ignore errors returned by pm_runtime_put_sync() totally, as they only say that the call was unable to put the hardware into suspend mode. However, I chose to ignore the returned -ENOSYS explicitly, and print a warning for other errors, as I think we should get notified if the HW failed to go to suspend properly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jassi Brar <jaswinder.singh@linaro.org> Cc: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| | * | OMAPDSS: Use PM notifiers for system suspendTomi Valkeinen2012-07-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current way how omapdss handles system suspend and resume is that omapdss device (a platform device, which is not part of the device hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses the suspend and resume callbacks from platform_driver to handle system suspend. It does this by disabling all enabled panels on suspend, and resuming the previously disabled panels on resume. This presents a few problems. One is that as omapdss device is not related to the panel devices or the DSS HW devices, there's no ordering in the suspend process. This means that suspend could be first ran for DSS HW devices and panels, and only then for omapdss device. Currently this is not a problem, as DSS HW devices and panels do not handle suspend. Another, more pressing problem, is that when suspending or resuming, the runtime PM functions return -EACCES as runtime PM is disabled during system suspend. This causes the driver to print warnings, and operations to fail as they think that they failed to bring up the HW. This patch changes the omapdss suspend handling to use PM notifiers, which are called before suspend and after resume. This way we have a normally functioning system when we are suspending and resuming the panels. This patch, I believe, creates a problem that somebody could enable or disable a panel between PM_SUSPEND_PREPARE and the system suspend, and similarly the other way around in resume. I choose to ignore the problem for now, as it sounds rather unlikely, and if it happens, it's not fatal. In the long run the system suspend handling of omapdss and panels should be thought out properly. The current approach feels rather hacky. Perhaps the panel drivers should handle system suspend, or the users of omapdss (omapfb, omapdrm) should handle system suspend. Note that after this patch we could probably revert 0eaf9f52e94f756147dbfe1faf1f77a02378dbf9 (OMAPDSS: use sync versions of pm_runtime_put). But as I said, this patch may be temporary, so let's leave the sync version still in place. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Jassi Brar <jaswinder.singh@linaro.org> Tested-by: Jassi Brar <jaswinder.singh@linaro.org> Tested-by: Joe Woodward <jw@terrafix.co.uk> Signed-off-by: Archit Taneja <archit@ti.com> [fts: fixed 2 brace coding style issues] Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
| * | | Merge tag 'omapdss-for-3.5-rc2' of git://gitorious.org/linux-omap-dss2/linuxLinus Torvalds2012-06-13
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull omapdss build problem fix from Tomi Valkeinen: "Small fixes for omapdss driver. Most importantly, fixes a build problem when debugfs or omapdss debug support is turned off, and fixes a suspend related crash." This has apparently been annoying rmk for a while.. * tag 'omapdss-for-3.5-rc2' of git://gitorious.org/linux-omap-dss2/linux: OMAPDSS: fix registration of DPI and SDI devices OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters OMAPDSS: fix bogus WARN_ON in dss_runtime_put() OMAPDSS: Taal: fix compilation warning OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled
* | | | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-03-22 20:12:32 -0400