summaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2/dss/core.c
Commit message (Collapse)AuthorAgeFilesLines
* omapdss: HDMI: Rename hdmi driver files to nicer namesArchit Taneja2013-10-091-2/+2
| | | | | | | | Replace the ti_hdmi_4xxx* notation for OMAP4 HDMI driver with hdmi4. Rename the hdmi.c encoder driver to hdmi4.c. Rename ti_hdmi.h to hdmi.h Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge tag 'fbdev-3.12-omap-legacy-removal' of ↵Linus Torvalds2013-09-051-320/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux Pull OMAP specific fbdev changes from Tomi Valkeinen: "I've got this pull request separate from the main fbdev pull request, as this contains a bunch of OMAP board file changes and thus could possibly be rejected in case of bad conflicts. The removal of the old display drivers depend on the board file changes, so Tony Lindgren suggested taking them together via fbdev tree. These are in linux-next, and also Tony didn't see any conflicts with any of the branches he had, so they should go in clean. - Change the OMAP board files to use the new OMAP display drivers - Remove all the old drivers, and the related auxiliary code" * tag 'fbdev-3.12-omap-legacy-removal' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (35 commits) OMAPDSS: rename omap_dss_device's 'device' field to 'dst' OMAPDSS: rename omap_dss_device's 'output' to 'src' OMAPDSS: DSS: remove legacy dss bus support OMAPDSS: RFBI: remove code related to old panel model OMAPDSS: VENC: remove code related to old panel model OMAPDSS: SDI: remove code related to old panel model OMAPDSS: DSI: remove code related to old panel model OMAPDSS: HDMI: remove code related to old panel model OMAPDSS: DPI: remove code related to old panel model OMAPDSS: remove all old panel drivers OMAPDSS: DPI: change regulator handling OMAPDSS: SDI: change regulator handling OMAPDSS: fix DPI and SDI device ids OMAPDSS: remove omap_dss_device->channel field OMAPDSS: RFBI: Mark RFBI as broken ARM: OMAP2+: Remove old display drivers from omap2plus_defconfig ARM: OMAP: AM3517EVM: use new display drivers ARM: OMAP: Zoom: use new display drivers ARM: OMAP: Pandora: use new display drivers ARM: OMAP: OMAP3EVM: use new display drivers ...
| * OMAPDSS: DSS: remove legacy dss bus supportTomi Valkeinen2013-08-301-287/+4
| | | | | | | | | | | | | | | | | | With all the old panels removed and all the old panel model APIs removed from the DSS encoders, we can now remove the custom omapdss-bus which was used in the old panel model. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: DPI: change regulator handlingTomi Valkeinen2013-08-291-18/+0
| | | | | | | | | | | | | | | | | | | | | | | | Regulator handling for DPI and SDI is currently handled in the core.c, using the 'virtual' omapdss platform device. Nowadays we have proper devices for both DPI and SDI, and so we can handle the regulators inside the respective drivers. This patch moves the regulator handling for DPI into dpi.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
| * OMAPDSS: SDI: change regulator handlingTomi Valkeinen2013-08-291-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | Regulator handling for DPI and SDI is currently handled in the core.c, using the 'virtual' omapdss platform device. Nowadays we have proper devices for both DPI and SDI, and so we can handle the regulators inside the respective drivers. This patch moves the regulator handling for SDI into sdi.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* | PTR_RET is now PTR_ERR_OR_ZERO(): Replace most.Rusty Russell2013-07-151-1/+1
|/ | | | | | | | | | | | Sweep of the simple cases. Cc: netdev@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: Julia Lawall <julia.lawall@lip6.fr> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Acked-by: David S. Miller <davem@davemloft.net> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* OMAPDSS: combine omap_dss_output into omap_dss_deviceTomi Valkeinen2013-06-171-2/+2
| | | | | | | | | | | | | | | | | | | | We currently have omap_dss_device, which represents an external display device, sometimes an external encoder, sometimes a panel. Then we have omap_dss_output, which represents DSS's output encoder. In the future with new display device model, we construct a video pipeline from the display blocks. To accomplish this, all the blocks need to be presented by the same entity. Thus, this patch combines omap_dss_output into omap_dss_device. Some of the fields in omap_dss_output are already found in omap_dss_device, but some are not. This means we'll have DSS output specific fields in omap_dss_device, which is not very nice. However, it is easier to just keep those output specific fields there for now, and after transition to new display device model is made, they can be cleaned up easier than could be done now. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Add panel dev pointer to dssdevTomi Valkeinen2013-06-171-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are about to remove the dss bus support, which also means that the omap_dss_device won't be a real device anymore. This means that the embedded "dev" struct needs to be removed from omap_dss_device. After we've finished the removal of the dss bus, we see the following changes: - struct omap_dss_device won't be a real Linux device anymore, but more like a "display entity". - struct omap_dss_driver won't be a Linux device driver, but "display entity ops". - The panel devices/drivers won't be omapdss devices/drivers, but platform/i2c/spi/etc devices/drivers, whichever fits the control mechanism of the panel. - The panel drivers will create omap_dss_device and omap_dss_driver, fill the required fields, and register the omap_dss_device to omapdss. - omap_dss_device won't have an embedded dev struct anymore, but a dev pointer to the actual device that manages the omap_dss_device. The model described above resembles the model that has been discussed with CDF (common display framework). For the duration of the conversion, we temporarily have two devs in the dssdev, the old "old_dev", which is a full embedded device struct, and the new "dev", which is a pointer to the device. "old_dev" will be removed in the future. For devices belonging to dss bus the dev is initialized to point to old_dev. This way all the code can just use the dev, for both old and new style panels. Both the new and old style panel drivers work during the conversion, and only after the dss bus support is removed will the old style panels stop to compile. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: implement display sysfs without dss busTomi Valkeinen2013-06-171-28/+0
| | | | | | | | | | | | | We aim to remove the custom omapdss bus totally, as it's quite a strange construct and won't be compatible with common display framework. One problem on the road is that we have sysfs files for each display, and they depend on the omapdss bus. This patch creates the display sysfs files independent of the omapdss bus. This gives us backwards compatibility without using the omapdss bus for the sysfs files. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add panel listTomi Valkeinen2013-06-171-0/+2
| | | | | | | | | | | | | | | | | We currently use the omapdss bus (which contains all the available displays) to iterate the displays. As the omapdss bus is on its way out, this needs to be changed. Instead of using the dss bus to iterate displays, this patch adds our own list of displays which we manage. The panels on the dss bus are automatically added to this new list. An "alias" field is also added to omap_dss_device. This field is set to "display%d", the same way as omap_dss_device's dev name is set. This alias is later used to keep backward compatibility, when the embedded dev is no longer used. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: CORE: use devm_regulator_getTomi Valkeinen2013-06-171-12/+2
| | | | | | Use devm_regulator_get() instead of regulator_get() to simplify code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Implement display (dis)connect supportTomi Valkeinen2013-06-171-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We currently have two steps in panel initialization and startup: probing and enabling. After the panel has been probed, it's ready and can be configured and later enabled. This model is not enough with more complex display pipelines, where we may have, for example, two panels, of which only one can be used at a time, connected to the same video output. To support that kind of scenarios, we need to add new step to the initialization: connect. This patch adds support for connecting and disconnecting panels. After probe, but before connect, no panel ops should be called. When the connect is called, a proper video pipeline is established, and the panel is ready for use. If some part in the video pipeline is already connected (by some other panel), the connect call fails. One key difference with the old style setup is that connect() handles also connecting to the overlay manager. This means that the omapfb (or omapdrm) no longer needs to figure out which overlay manager to use, but it can just call connect() on the panel, and the proper overlay manager is connected by omapdss. This also allows us to add back the support for dynamic switching between two exclusive panels. However, the current panel device model is not changed to support this, as the new device model is implemented in the following patches and the old model will be removed. The new device model supports dynamic switching. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add pdata->default_display_nameTomi Valkeinen2013-06-171-0/+2
| | | | | | | | | | | | | | We can currently set the default display (i.e. the initial display) in the omapdss platform data by using a pointer to the default omap_dss_device. Internally omapdss uses the device's name to resolve the default display. As it's difficult to get the omap_dss_device pointer in the future, after we've changed the omapdss device model, this patch adds a new way to define the default display, by using the name of the display. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* Merge branch 'fbdev-3.10-fixes' of git://gitorious.org/linux-omap-dss2/linux ↵Jean-Christophe PLAGNIOL-VILLARD2013-05-291-1/+19
|\ | | | | | | | | | | | | | | into linux-fbdev/for-3.10-fixes Pull Tomi fixes for ps3fb and omap2 Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
| * OMAPDSS: Fix crash with DT bootTomi Valkeinen2013-05-231-1/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When booting with DT, there's a crash when omapfb is probed. This is caused by the fact that omapdss+DT is not yet supported, and thus omapdss is not probed at all. On the other hand, omapfb is always probed. When omapfb tries to use omapdss, there's a NULL pointer dereference crash. The same error should most likely happen with omapdrm and omap_vout also. To fix this, add an "initialized" state to omapdss. When omapdss has been probed, it's marked as initialized. omapfb, omapdrm and omap_vout check this state when they are probed to see that omapdss is actually there. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
* | drivers: video: omap2: dss: Use PTR_RET functionAlexandru Gheorghiu2013-04-101-4/+1
|/ | | | | | | | Use PTR_RET function instead of IS_ERR and PTR_ERR. Patch found using coccinelle. Signed-off-by: Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: use omapdss_compat_init() in other driversTomi Valkeinen2012-12-071-4/+0
| | | | | | | | | omapdss_compat_init() and omapdss_compat_uninit() is called internally by omapdss. This patch moves the calls to omapfb, omap_vout and omapdrm drivers. omapdrm driver can later remove the call after non-compat support has been implemented in omapdrm. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: move display sysfs init to compat layerTomi Valkeinen2012-12-071-7/+0
| | | | | | Move creation of the sysfs files for displays to the compat layer. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: move ovl & ovl-mgr init to apply.cTomi Valkeinen2012-12-071-6/+0
| | | | | | | | | | Overlay and overlay_manager structs will only be needed in the compat mode. This patch moves initialization of overlay and overlay_manager structs to apply.c, so that they are handled in omapdss_compat_init(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add omapdss_compat_init()Tomi Valkeinen2012-12-071-1/+3
| | | | | | | | | | | | Add two new exported functions, omapdss_compat_init and omapdss_compat_uninit, which are to be used by omapfb, omap_vout to enable compatibility mode for omapdss. The functions are called by omapdss internally for now, and moved to other drivers later. The compatibility mode is implemented fully in the following patches. For now, enabling compat mode only sets up the private data in apply.c. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Use only "omapdss_dss" platform device to get context lost countArchit Taneja2012-11-291-15/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When enabling a hwmod, omap_hwmod refers to the register mentioned in the hwmod struct's member 'prcm.omap4.context_offs' to see whether context was lost or not. It increments the context lost count for the hwmod and then clears the register. All the DSS hwmods have the same register(RM_DSS_DSS_CONTEXT) as context_offs. When DSS is enabled, the first hwmod to be enabled is the "dss_core" hwmod since it's corresponding platform device is the parent platform device("omapdss_dss"). The dss_core hwmod updates it's context lost count correctly and clears the register. When the hwmods corresponding to the children platform devices are enabled, they see that the register is clear, and don't increment their context lost count. Therefore, all the children platform devices never report a loss in context. The DISPC driver currently gets the context lost count for DSS power domain from it's corresponding platform device instance("omapdss_dispc"). The DISPC platform device is one of the child devices, and it's corresponding hwmod("dss_dispc") doesn't report the context lost count correctly. Modify dss_get_ctx_loss_count() such that it always takes the "omapdss_dss" platform device as it's input, move the function to dss.c so that it has access to that platform device. Signed-off-by: Archit Taneja <archit@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add dss_get_core_pdev()Tomi Valkeinen2012-11-271-0/+5
| | | | | | | | Add dss_get_core_pdev() which returns the platform device for dss core device. The following patches use the core pdev to register sysfs files in the compat code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: fix DPI & DSI init orderTomi Valkeinen2012-11-051-6/+6
| | | | | | | | | | | | | | | DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver is added first, which causes DPI initialization to fail when it tries to get the DSI PLL. This patch changes the init order to fix this. A better solution would be to separate DSI PLL and DSI drivers. They have dependencies, though, but we could still have DSI PLL as an independent entity that we could initialize before any of the output drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: export dss_get_def_display_name()Tomi Valkeinen2012-10-291-1/+2
| | | | | | | | Export dss_get_def_display_name() with the name of omapdss_get_def_display_name() so that omapfb can use it after the next patch which moves default display handling to omapfb. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: get the dss version from core pdevTomi Valkeinen2012-10-241-1/+8
| | | | | | | | | | | | The output drivers get the omapdss hw version from the platform data for their respective output device. This doesn't work with DT, as there's no platform data for them. Add a new function, omapdss_get_version(), which returns the dss version from the core device, which will have platform data on DT also. The function is exported so that users of omapdss can also use it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge branch '3.8/dss-version'Tomi Valkeinen2012-10-181-1/+1
|\ | | | | | | Merge omapdss code to remove cpu_is_* checks from the driver.
| * OMAPDSS: use omapdss_version in dss_features.cTomi Valkeinen2012-10-161-1/+1
| | | | | | | | | | | | | | Pass the omapdss_version to dss_features.c and use it to select the proper dss features. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: Correct check for the callback pointer in dss_dsi_disable_pads()Peter Ujfalusi2012-10-171-1/+1
| | | | | | | | | | | | | | | | Appear to be a copy-paste bug: the code was checking board_data->dsi_enable_pads while calling board_data->dsi_disable_pads. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: Remove dss_debug variableChandrabhanu Mahapatra2012-10-121-5/+0
| | | | | | | | | | | | | | | | | | | | | | All the debug prints have been replaced with pr_debug(). Thus, the dependency on dss_debug variable is replaced with dyndbg in dynamic debugging mode and DEBUG flag otherwise. So, the dss_debug variable is removed along with checks for DEBUG flag. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: Create new debug config optionsChandrabhanu Mahapatra2012-10-121-3/+3
|/ | | | | | | | | | | | The config option CONFIG_OMAP2_DSS_DEBUG_SUPPORT has been removed and replaced with CONFIG_OMAP2_DSS_DEBUG and CONFIG_OMAP2_DSS_DEBUGFS. CONFIG_OMAP2_DSS_DEBUG enables DEBUG flag and CONFIG_OMAP2_DSS_DEBUGFS enables creation of debugfs for OMAPDSS. Both the config options are disabled by default and can be enabled independently of one another as per convenience. Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com> Reviewed-by: Sumit Semwal <sumit.semwal@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: alloc dssdevs dynamicallyTomi Valkeinen2012-09-181-36/+36
| | | | | | | | | | | | | | | | | | | | | | | 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-181-5/+0
| | | | | | | | | 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: handle errors in dss_init_deviceTomi Valkeinen2012-09-181-1/+3
| | | | | | | Add error handling to dss_init_device(), which has, for some reason, been missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Add dss_get_default_display_name()Tomi Valkeinen2012-09-181-0/+5
| | | | | | | | | 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-181-4/+5
| | | | | | | | | | | | | | | | 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: Use PM notifiers for system suspendTomi Valkeinen2012-07-081-16/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabledTomi Valkeinen2012-06-041-2/+1
| | | | | | | | | | | | | | | If CONFIG_DEBUG_FS or CONFIG_OMAP2_DSS_DEBUG_SUPPORT is disabled, the build fails: drivers/video/omap2/dss/core.c:197:50: error: static declaration of 'dss_debugfs_create_file' follows non-static declaration drivers/video/omap2/dss/dss.h:166:5: note: previous declaration of 'dss_debugfs_create_file' was here This patch fixes the dummy dss_debugfs_create_file() so that the driver builds. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: interface drivers register their panel devicesTomi Valkeinen2012-05-111-33/+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: change default_device handlingTomi Valkeinen2012-05-111-5/+9
| | | | | | | | | | | | | | | | | | | | We currently have a two ways to set a "default panel device" for dss, to which the overlays are connected when the omapdss driver is loaded: - in textual format (name of the display) as cmdline parameter - as a pointer to the panel device from board file via pdata The current code handles this in a bit too complex way by using both of the above methods during runtime. However, with DT we don't have pdata anymore, so the code handling the second case won't work anymore. The current code has also the problem that it modifies the platform_data. This patch simplifies the code a bit by using the pointer method only inside the probe function, and stores the name of the panel device. This way we only need to handle the textual format during operation and also avoid modifying the platform_data. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: add __init & __exitTomi Valkeinen2012-05-111-2/+2
| | | | | | | 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: move the creation of debugfs filesTomi Valkeinen2012-05-111-28/+18
| | | | | | | | 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: handle output-driver reg/unreg more dynamicallyTomi Valkeinen2012-05-111-52/+59
| | | | | | | | Initialize and uninitialize the output drivers by using arrays of pointers to the init/uninit functions. This simplifies the code slightly. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: create DPI & SDI driversTomi Valkeinen2012-05-111-0/+18
| | | | | | | | | | | | | | | We currently have separate device/driver for each DSS HW module. The DPI and SDI outputs are more or less parts of the DSS or DISPC hardware modules, but in SW it makes sense to represent them as device/driver pairs similarly to all the other outputs. This also makes sense for device tree, as each node under dss will be a platform device, and handling DPI & SDI somehow differently than the rest would just make the code more complex. This patch modifies the dpi.c and sdi.c to create drivers for the platform devices. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: use platform_driver_probe for core/dispc/dssTomi Valkeinen2012-05-111-2/+1
| | | | | | | | The platform devices for omapdss, dss and dispc drivers are always present, so we can use platform_driver_probe instead of platform_driver_register. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: clean up the omapdss platform data messTomi Valkeinen2012-05-111-0/+35
| | | | | | | | | | | | | | | | | The omapdss pdata handling is a mess. This is more evident when trying to use device tree for DSS, as we don't have platform data anymore in that case. This patch cleans the pdata handling by: - Remove struct omap_display_platform_data. It was used just as a wrapper for struct omap_dss_board_info. - Pass the platform data only to omapdss device. The drivers for omap dss hwmods do not need the platform data. This should also work better for DT, as we can create omapdss device programmatically in generic omap boot code, and thus we can pass the pdata to it. - Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads that the dss hwmod drivers can call. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: provide default get_timings function for panelsGrazvydas Ignotas2012-04-231-0/+2
| | | | | | | | | 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: Ensure OPP100 when DSS is operationalTomi Valkeinen2012-04-231-0/+10
| | | | | | | | | | | | | | | | | | | | | | Most of the DSS clocks have restrictions on their frequency based on the OPP in use. For example, maximum frequency for a clock may be 180MHz in OPP100, but 90MHz in OPP50. This means that when a high enough pixel clock or function clock is required, we need to use OPP100. However, there's currently no way in the PM framework to make that kind of request. The closest we get is to ask for very high bus throughput from the PM framework, which should effectively force OPP100. This patch is a simple version for handling the problem. Instead of asking for OPP100 only when needed, this patch asks for OPP100 whenever DSS is active. This obviously is not an optimal solution for cases with small displays where OPP50 would work just fine. However, a proper solution is a complex one, and this patch is a short term solution for the problem. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Acked-by: Kevin Hilman <khilman@ti.com>
* OMAPDSS: register dss drivers in module initTomi Valkeinen2012-03-211-58/+77
| | | | | | | | | | | | | | | | | We do the dss driver registration in a rather strange way: we have the higher level omapdss driver, and we use that driver's probe function to register the drivers for the rest of the dss devices. There doesn't seem to be any reason for that, and additionally the soon-to-be-merged patch "ARM: OMAP: omap_device: remove omap_device_parent" will break omapdss initialization with the current registration model. This patch changes the registration for all drivers to happen at the same place, in the init of the module. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
* Merge branch 'fbdev-next' of git://github.com/schandinat/linux-2.6Linus Torvalds2012-01-141-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'fbdev-next' of git://github.com/schandinat/linux-2.6: (175 commits) module_param: make bool parameters really bool (drivers/video/i810) Revert "atmel_lcdfb: Adjust HFP calculation so it matches the manual." OMAPDSS: HDMI: Disable DDC internal pull up OMAPDSS: HDMI: Move duplicate code from boardfile OMAPDSS: add OrtusTech COM43H4M10XTC display support OMAP: DSS2: Support for UMSH-8173MD TFT panel ASoC: OMAP: HDMI: Move HDMI codec trigger function to generic HDMI driver OMAPDSS: HDMI: Create function to enable HDMI audio ASoC: OMAP: HDMI: Correct signature of ASoC functions ASoC: OMAP: HDMI: Introduce driver data for audio codec grvga: fix section mismatch warnings video: s3c-fb: Don't keep device runtime active when open video: s3c-fb: Hold runtime PM references when touching registers video: s3c-fb: Take a runtime PM reference when unblanked video: s3c-fb: Disable runtime PM in error paths from probe video: s3c-fb: Use s3c_fb_enable() to enable the framebuffer video: s3c-fb: Make runtime PM functional again drivers/video: fsl-diu-fb: merge fsl_diu_alloc() into map_video_memory() drivers/video: fsl-diu-fb: add default platform ops functions drivers/video: fsl-diu-fb: remove broken reference count enabling the display ...
| * OMAPDSS: create apply.cTomi Valkeinen2011-12-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Create a new file, apply.c, and move code about handling the apply-mechanism and configuration of the managers and overlays from manager.c to apply.c. Not all related code is moved in this patch, but only the core apply/configure functions. The later patches move rest of the code from overlay.c and manager.c, adding necessary locking at the same time. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
OpenPOWER on IntegriCloud