aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2
Commit message (Collapse)AuthorAge
...
| * | | OMAPDSS: DSI: make OMAP2_DSS_DSI depend on ARCH_OMAP5Tomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | Change omapdss Kconfig file to make OMAP2_DSS_DSI depend on ARCH_OMAP5. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: DSI: Add code to disable PHY DCCTomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP5 DSI PHY has DCC (Duty Cycle Corrector) block, and by default DCC is enabled and thus the PLL clock is divided by 2 to get the DSI DDR clk. This divider has been 4 for all previous OMAPs, and changing it needs some reorganization of the code. The DCC can be disabled, and in that case the divider is back to the old 4. This patch adds dss feature for the DCC, and adds code to always disable the DCC. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: DSI: Add new linebuffer size for OMAP5Tomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | OMAP5's DSI has a larger line buffer than earlier OMAPs. This patch adds support for this to the DSI driver. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: DSI: Add FEAT_DSI_PLL_REFSELTomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add FEAT_DSI_PLL_REFSEL. OMAP5's DSI PLL needs configuration to select the reference clock to be used. We always use SYSCLK. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: DSI: Add FEAT_DSI_PLL_SELFREQDCOTomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add FEAT_DSI_PLL_SELFREQDCO. OMAP5's DSI PLL has a new configuration option that needs to be programmed depending on the PLL's output clock frequency. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
| * | | OMAPDSS: Add support for DPI source selectionTomi Valkeinen2012-09-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can select the video source for DPI output as follows: OMAP2/3: always LCD1 OMAP4: LCD2 or DIGIT OMAP5: LCD1/LCD2/LCD3/DIGIT This patch adds support to select the source, and makes dpi.c call the function to set the source. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Anders <x0132446@ti.com>
| * | | 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
| * | 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-09 10:05:00 -0400