summaryrefslogtreecommitdiff
path: root/drivers/video/omap2/dss/venc.c
Commit message (Collapse)AuthorAgeFilesLines
* OMAPDSS: VENC: Replace dssdev->manager with dssdev->output->manager referencesArchit Taneja2012-09-261-5/+9
| | | | | | | | | | | With addition of output entities, a device connects to an output, and an output connects to overlay manager. Replace the dssdev->manager references with dssdev->output->manager to access the manager correctly. When enabling the VENC output, check whether the output entity connected to display is not NULL. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: outputs: Create and register output instancesArchit Taneja2012-09-261-0/+24
| | | | | | | | | | | | | | | | | Add output structs to output driver's private data. Register output instances by having an init function in the probes of the platform device drivers for different outputs. The *_init_output for each output registers the output and fill up the output's plaform device, type and id fields. The *_uninit_output functions unregister the output. In the probe of each interface driver, the output entities are initialized before the *_probe_pdata() functions intentionally. This is done to ensure that the output entity is prepared before the panels connected to the output are registered. We need the output entities to be ready because OMAPDSS will try to make connections between overlays, managers, outputs and devices during the panel's probe. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: alloc dssdevs dynamicallyTomi Valkeinen2012-09-181-4/+13
| | | | | | | | | | | | | | | | | | | | | | | 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: explicitely initialize dssdev->channel for new displaysTomi Valkeinen2012-09-181-0/+2
| | | | | | | | | | | 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-181-10/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: omap_dss_register_device() doesn't take display indexTomi Valkeinen2012-09-181-1/+1
| | | | | | | | | | | | | | | | 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: fix set_timingsTomi Valkeinen2012-09-071-13/+0
| | | | | | | | | | | | | | 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: remove unnecessary includesTomi Valkeinen2012-09-071-1/+0
| | | | | | Remove unnecessary includes from omapdss. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: VENC: Remove cpu_is_xxxx checksChandrabhanu Mahapatra2012-08-221-11/+0
| | | | | | | | | | | | 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: VENC: Maintian copy of video output polarity info in private dataArchit Taneja2012-08-161-1/+12
| | | | | | | | | | | | 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-161-2/+13
| | | | | | | | | | | | 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: VENC: Maintain our own timings field in driver dataArchit Taneja2012-08-151-5/+7
| | | | | | | | | | | | | | | | | | | The VENC driver currently relies on the timings in omap_dss_device struct to configure the DISPC and VENC blocks accordingly. This makes the VENC interface driver dependent on the omap_dss_device struct. Make the VENC driver data maintain it's own timings field. The panel driver is expected to call omapdss_venc_set_timings() to set these timings before the panel is enabled. Call omapdss_venc_set_timings() before enabling venc output, this is done to atleast have the venc output configured to the panel's default timings if the DSS user didn't explicitly call the venc panel driver's set_timings op. Make the VENC panel driver configure the new timings is the omap_dss_device struct(dssdev->panel.timings). The VENC driver is responsible for maintaining only it's own copy of timings. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: VENC: Split VENC into interface and panel driverArchit Taneja2012-08-151-155/+53
| | | | | | | | | | | | | | | The current venc.c driver contains both the interface and panel driver code. This makes the driver hard to read, and difficult to understand the work split between the interface and panel driver and the how the locking works. This also makes it easier to clearly define the VENC interface ops called by the panel driver. Split venc.c into venc.c and venc_panel.c representing the interface and panel driver respectively. This split is done along the lines of the HDMI interface and panel drivers. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: Add interlace parameter to omap_video_timingsArchit Taneja2012-06-291-0/+4
| | | | | | | | | | | Add a parameter called interlace which tells whether the timings are in interlaced or progressive mode. This aligns the omap_video_timings struct with the Xorg modeline configuration. It also removes the hack needed to write to divide the manager height by 2 if the connected interface is VENC. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=nTomi Valkeinen2012-06-291-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: add clk_prepare_enable and clk_disable_unprepareRajendra Nayak2012-06-291-2/+2
| | | | | | | | | | | | | | | In preparation of OMAP moving to Common Clk Framework(CCF) change clk_enable() and clk_disable() calls to clk_prepare_enable() and clk_disable_unprepare() in omapdss. This can be safely done, as omapdss never enables or disables clocks in atomic context. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: <linux-fbdev@vger.kernel.org> Cc: Paul Walmsley <paul@pwsan.com> Cc: Mike Turquette <mturquette@linaro.org> [tomi.valkeinen@ti.com: updated patch description] Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Apply VENC timings even if panel is disabledArchit Taneja2012-05-221-0/+2
| | | | | | | | | | | | | | | | | | | | The VENC interfaces uses it's venc_set_timing() function to take in a new set of timings. If the panel is disabled, it does not disable and re-enable the interface. Currently, the manager timings are applied in venc_power_on(), these are not called by set_timings if the panel is disabled. When checking overlay and manager data, the DSS driver uses the last applied manager timings, and not the timings held by omap_dss_device struct. Hence, there is a need to apply the new manager timings even if the panel is disabled. Apply the manager timings if the VENC panel is disabled. This is similar to the commit below which fixed the same issue for HDMI/DPI interfaces: fcc36619901064a76e15a545ea36d38ba0e54192 Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENCArchit Taneja2012-05-221-5/+1
| | | | | | | | | | | | | | | | | | | | DSS2 driver uses the timings in manager's private data to check the validity of overlay and manager infos written by the user. For VENC interface, we divide the Y resolution by half when writing to the DISPC_DIGIT_SIZE register as the content is interlaced. However, the height of the manager/display with respect to the content shown through VENC still remains the same. The VENC driver divides the y_res parameter in omap_video_timings by half, and then applies the configuration. This leads to manager's private data storing the wrong Y resolution. Hence, overlay related checks fail. Ensure that manager's private data stores the original timings, and the Y resolution is halved only when we write to the DISPC register. This is a hack, the proper solution would be to pass some sort of interlace parameter which makes the call whether we should divide y_res or not. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove compiler warnings when CONFIG_BUG=nTomi Valkeinen2012-05-221-0/+1
| | | | | | | | | | | | | | If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many places in code expect the execution to stop, and this causes compiler warnings about uninitialized variables and returning from a non-void function without a return value. This patch fixes the warnings by initializing the variables and returning properly after BUG() lines. However, the behaviour is still undefined after the BUG, but this is the choice the user makes when using CONFIG_BUG=n. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: separate pdata based initializationTomi Valkeinen2012-05-111-19/+26
| | | | | | | Move the platform-data based display device initialization into a separate function, so that we may later add of-based initialization. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: init omap_dss_devices internallyTomi Valkeinen2012-05-111-1/+7
| | | | | | | Now that each output driver creates their own display devices, the output drivers can also initialize those devices. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: interface drivers register their panel devicesTomi Valkeinen2012-05-111-1/+17
| | | | | | | | | | | | | | | | | | | | | Currently the higher level omapdss platform driver gets the list of displays in its platform data, and uses that list to create the omap_dss_device for each display. With DT, the logical way to do the above is to list the displays under each individual output, i.e. we'd have "dpi" node, under which we would have the display that uses DPI. In other words, each output driver handles the displays that use that particular output. To make the current code ready for DT, this patch modifies the output drivers so that each of them creates the display devices which use that output. However, instead of changing the platform data to suit this method, each output driver is passed the full list of displays, and the drivers pick the displays that are meant for them. This allows us to keep the old platform data, and thus we avoid the need to change the board files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add __init & __exitTomi Valkeinen2012-05-111-5/+5
| | | | | | | Now that we are using platform_driver_probe() we can add __inits and __exits all around. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdiTomi Valkeinen2012-05-111-2/+1
| | | | | | | | Now that the core.c doesn't fail if output driver's init fails, we can change the uses of platform_driver_register to platform_driver_probe. This will allow us to use __init in the following patches. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: move the creation of debugfs filesTomi Valkeinen2012-05-111-1/+3
| | | | | | | | Instead of having an ugly #ifdef mess in the core.c for creating debugfs files, add a dss_debugfs_create_file() function that the dss drivers can use to create the debugfs files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove uses of dss_runtime_get/putTomi Valkeinen2012-05-111-11/+1
| | | | | | | | | Now that the omapdss_core device is the parent for all other dss devices, we don't need to use the dss_runtime_get/put anymore. Instead, enabling omapdss_core will happen automatically when a child device is enabled. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: remove return from platform_driver_unregTomi Valkeinen2012-05-111-1/+1
| | | | | | | | | For unknown reasons we seem to have a return in each of the omapdss's uninit functions, which is a void function. Remove the returns. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: VENC: allow switching venc output type at runtimeGrazvydas Ignotas2012-05-111-1/+53
| | | | | | | | | | | | | | VENC output type (composite/svideo) doesn't have to be fixed by board wiring, it is possible to also provide composite signal through svideo luminance connector (software enabled), which is what pandora does. Having to recompile the kernel for users who have TV connector types that don't match default board setting is very inconvenient, especially for users of a consumer device, so add support for switching VENC output type at runtime over a new sysfs file output_type. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Apply manager timings instead of direct DISPC writesArchit Taneja2012-05-091-1/+1
| | | | | | | | | | | Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the interface drivers. The latter function ensures that the timing related DISPC registers are configured according to the shadow register programming model. Remove the call to dispc_mgr_go() in dpi_set_timings() as the manager's go bit is set by dss_mgr_set_timings(). Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPDSS: DISPC: Use a common function to set manager timingsArchit Taneja2012-04-231-2/+5
| | | | | | | | | | | | | | | | Currently, a LCD manager's timings is set by dispc_mgr_set_lcd_timings() and TV manager's timings is set by dispc_set_digit_size(). Use a common function called dispc_mgr_set_timings() which sets timings for both type of managers. We finally want the interface drivers to use an overlay manager function to configure it's timings, having a common DISPC function would make things cleaner. For LCD managers, dispc_mgr_set_timings() sets LCD size and blanking values, for TV manager, it sets only the TV size since blanking values don't exist for TV. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: provide default get_timings function for panelsGrazvydas Ignotas2012-04-231-7/+0
| | | | | | | | | With this we can eliminate some duplicate code in panel drivers. Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and tpo-td043mtea1 gain support of reading timings over sysfs. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: VENC: Check for errors from regulator_enable()Mark Brown2012-04-231-1/+3
| | | | | | | | | It is possible for regulator_enable() to fail and if it does fail that's generally a bad sign for anything we try to do with the hardware afterwards so check for and immediately return an error if regulator_enable() fails. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: cleanup probe functionsTomi Valkeinen2012-02-211-9/+12
| | | | | | | | | | | | Now that dss is using devm_ functions for allocation in probe functions, small reordering of the allocations allows us to clean up the probe functions more. This patch moves "unmanaged" allocations after the managed ones, and uses plain returns instead of gotos where possible. This lets us remove a bunch of goto labels, simplifying the probe's error handling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge commit 'v3.3-rc4'Tomi Valkeinen2012-02-211-1/+1
|\
| * OMAPDSS: use sync versions of pm_runtime_putTomi Valkeinen2012-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | omapdss doesn't work properly on system suspend. The problem seems to be the fact that omapdss uses pm_runtime_put() functions when turning off the hardware, and when system suspend is in process only sync versions are allowed. Using non-sync versions normally and sync versions when suspending would need rather ugly hacks to convey the information of suspending/not-suspending to different functions. Optimally the driver wouldn't even need to care about this, and the PM layer would handle syncing when suspend is in process. This patch changes all omapdss's pm_runtime_put calls to pm_runtime_put_sync. This fixes the suspend problem, and probably the performance penalty of always using sync versions is negligible. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Kevin Hilman <khilman@ti.com>
* | OMAPDSS: use devm_ functionsJulia Lawall2012-01-251-5/+3
| | | | | | | | | | | | | | | | | | | | The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: VENC: fix NULL pointer dereference in DSS2 VENC sysfs debug attr on ↵Danny Kukawka2012-01-251-0/+5
|/ | | | | | | | | | | | | | OMAP4 Commit ba02fa37de80bea10d706f39f076dd848348320a disabled the venc driver registration on OMAP4. Since the driver never gets probed/initialised your get a dereferenceed NULL pointer if you try to get info from /sys/kernel/debug/omapdss/venc Return info message about disabled venc if venc_dump_regs() gets called. Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: check the return value of dss_mgr_enable()Tomi Valkeinen2011-12-021-3/+23
| | | | | | | Now that dss_mgr_enable returns an error value, check it in all the places dss_mgr_enable is used, and bail out properly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: hide manager's enable/disable()Tomi Valkeinen2011-12-021-2/+2
| | | | | | | | | | | omap_overlay_manager struct contains enable() and disable() functions. However, these are only meant to be used from inside omapdss, and thus it's bad to expose the functions. This patch adds dss_mgr_enable() and dss_mgr_disable() functions to apply.c, which handle enabling and disabling the output. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: DISPC: Get correct pixel clock for TV managerArchit Taneja2011-09-301-3/+5
| | | | | | | | | | | | | | dispc_mgr_pclk_rate() is used to calculate minimum required functional clock for scaling in calc_fclk() and calc_fclk_five_taps(). This function returns the correct pixel clock for LCD and LCD2 managers, but not for TV manager. Extend this function so that it gets the correct pixel clock for TV manager. This also prevents the crash we get when we try to scale overlays connected to TV manager. The current code leads to a BUG() being executed if we call dispc_mgr_pclk_rate() for the TV manager. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: remove unneeded fck enable/disablesTomi Valkeinen2011-09-201-14/+0
| | | | | | | | | | | | | | Now that the HWMOD fmwk handles the fcks of DSS modules properly, the DSS driver no longer needs to explicitely enable/disable the fck. This patch removes the enables/disables of fck from dispc, dsi and dss. The clk_get(fck) is still needed there, as the modules need to know the frequency of the clock. For hdmi and venc this patch also removes the clk_get(fck), as they don't need the clock at all. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Revert "HACK: OMAP: DSS2: clk hack for OMAP2/3"Tomi Valkeinen2011-09-201-4/+1
| | | | | | | | This reverts commit 9ede365aa6f74428a1f69c21ca1cf21213167576. The hack is no longer needed, as the HWMOD data has been fixed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* HACK: OMAP: DSS2: clk hack for OMAP2/3Tomi Valkeinen2011-08-011-1/+4
| | | | | | | | | | | | The HWMOD data for OMAP2 and 3 are currently not up to date regarding DSS (OMAP4 HWMOD data is fine). This patch makes the DSS driver to get the opt clocks needed for OMAP2/3 with the old clock names, thus allowing DSS driver to use runtime PM. The HWMOD databases should be fixes ASAP, and this patch can be reverted after that. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Use PM runtime & HWMOD supportTomi Valkeinen2011-07-251-23/+142
| | | | | | | | | | | | Use PM runtime and HWMOD support to handle enabling and disabling of DSS modules. Each DSS module will have get and put functions which can be used to enable and disable that module. The functions use pm_runtime and hwmod opt-clocks to enable the hardware. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Add FEAT_VENC_REQUIRES_TV_DAC_CLKTomi Valkeinen2011-07-011-6/+10
| | | | | | | | | | | OMAP3430 requires an 96MHz clock to VENC's DAC, but no other OMAP needs it. Add a new feature, FEAT_VENC_REQUIRES_TV_DAC_CLK, which tells if the clock is needed on this platform, and use that feature in venc.c to decide if the clock needs enabling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: remove update_mode from omapdssTomi Valkeinen2011-07-011-17/+0
| | | | | | | | Remove the whole update_mode stuff from omapdss driver. If automatic update for manual update displays is needed, it's better implemented in higher layers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: VENC: Add missing start/stop_device callsTomi Valkeinen2011-05-111-0/+12
| | | | | | | | VENC code was missing omap_dss_start/stop_device calls. This didn't cause any problems as VENC could not be compiled as a module, but nevertheless it's better to add the calls. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: VENC: Remove sleeps at venc enable/disableTomi Valkeinen2011-05-111-6/+0
| | | | | | | VENC code had 50ms sleep after enabling the output and 100ms sleep after disabling the output. I don't see any reason for these sleeps. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: VENC: make 20ms venc bug-fix sleep optionalTomi Valkeinen2011-05-111-0/+3
| | | | | | | | There's a 20ms sleep after VENC reset. It's unknown what bug this circumvents and on what platforms. Add a Kconfig option to disable the sleep. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: Move display.h to include/video/Tomi Valkeinen2011-05-111-1/+1
| | | | | | | arch/arm/plat-omap/include/plat/display.h is an include for the OMAP DSS driver. A more logical place for it is in include/video. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
View Lorry Controller Status