summaryrefslogtreecommitdiff
path: root/drivers/video/omap2
AgeCommit message (Collapse)Author
2013-06-17OMAPDSS: Add panel dev pointer to dssdevTomi Valkeinen
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>
2013-06-17OMAPDSS: implement display sysfs without dss busTomi Valkeinen
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>
2013-06-17OMAPDSS: don't use dss bus in suspend/resumeTomi Valkeinen
We have support functions to suspend and resume all the displays that are used with system suspend. These functions use the dss bus to iterate the display devices. As we aim to remove the custom dss bus totally, this patch removes the explicit use of dss bus from these functions. Instead the for_each_dss_dev() macro is used to go through the devices. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: use the panel list in omap_dss_get_next_deviceTomi Valkeinen
omap_dss_get_next_device() uses the dss bus to iterate over the displays. This patch changes omap_dss_get_next_device() to use the new panel list instead. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: add panel listTomi Valkeinen
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>
2013-06-17OMAPDSS: remove dssdev uses in trivial casesTomi Valkeinen
In the future the "dssdev" parameter passed to output drivers will change its meaning. Instead of being a pointer to the panel device, it's a pointer to the output instance. To make the transition easier, some of the uses for this dssdev parameter can be easily removed. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: add videomode conversion supportTomi Valkeinen
Add helper functions to convert between omapdss specific video timings and the common videomode. Eventually omapdss will be changed to use only the common video timings, and these helper functions will make the transition easier. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: VENC: clean up regulator initTomi Valkeinen
Clean up the VENC driver's regulator init to remove the (unused) omap_dss_device parameter, renaming the function to a more sensible name, and making the code slightly clearer. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: SDI: fix regulators for DTTomi Valkeinen
SDI requires a regulator to operate. This regulator is, for some reason, currently attached to the virtual omapdss device, instead of the SDI device. This does not work for DT, as the regulator mappings need to be described in the DT data, and the virtual omapdss device is not present there. Fix the issue by acquiring the regulator in the SDI device. To retain compatibility with the current board files, the old method of getting the regulator is kept. The old method can be removed when the board files have been changed to pass the regulator to SDI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: SDI: clean up regulator initTomi Valkeinen
Clean up the SDI driver's regulator init to remove the (unused) omap_dss_device parameter, renaming the function to a more sensible name, and making the code slightly clearer. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: HDMI: add hdmi_init_regulatorTomi Valkeinen
Separate regulator init code into its own function for clarity. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: DPI: fix regulators for DTTomi Valkeinen
On some platforms DPI requires a regulator to be enabled to power up the output pins. This regulator is, for some reason, currently attached to the virtual omapdss device, instead of the DPI device. This does not work for DT, as the regulator mappings need to be described in the DT data, and the virtual omapdss device is not present there. Fix the issue by acquiring the regulator in the DPI device. To retain compatibility with the current board files, the old method of getting the regulator is kept. The old method can be removed when the board files have been changed to pass the regulator to DPI. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: DPI: cleanup pll & regulator initTomi Valkeinen
Split regulator and DSI PLL init code to their own functions for clarity. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: DSI: cleanup regulator initTomi Valkeinen
Separate the regulator initialization code to its own function, removing duplicate code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: CORE: use devm_regulator_getTomi Valkeinen
Use devm_regulator_get() instead of regulator_get() to simplify code. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: Implement display (dis)connect supportTomi Valkeinen
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>
2013-06-17OMAPDRM: fix overlay manager handlingTomi Valkeinen
Currently omapdrm creates crtcs, which map directly to DSS overlay managers, only on demand at init time. This would make it difficult to manage connecting the display entities in the future, as the code cannot just search for a suitable overlay manager. We cannot fix this the sane way, which would be to create crtcs for each overlay manager, because we need an overlay for each crtc. With limited number of overlays, that's not possible. So the solution for now is to detach the overlay manager from the crtc. crtcs are still created on demand at init time, but all overlay managers are always initialized by the omapdss. This way we can create and connect whole display pipelines from the overlay manager to the display, regardless of which crtcs omapdrm would create. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: split overlay manager creationTomi Valkeinen
Split the function that creates overlay manager structs into two: one that creates just the structs, and one that creates the sysfs files for the manager. This will help us use the overlay manager structs with omapdrm in the following patches, while still leaving the sysfs files out. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: add helpers to get mgr or output from displayTomi Valkeinen
Add two helper functions that can be used to find either the DSS output or the overlay manager that is connected to the given display. This hides how the output and the manager are actually connected, making it easier to change the connections in the future. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: clean up dss_[ovl|mgr]_get_device()Tomi Valkeinen
Minor cleanup for the dss_[ovl|mgr]_get_device() functions to make them more readable. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: fix dss_get_ctx_loss_count for DTTomi Valkeinen
When using DT, dss device does not have platform data. However, dss_get_ctx_loss_count() uses dss device's platform data to find the get_ctx_loss_count function pointer. To fix this, dss_get_ctx_loss_count() needs to be changed to get the platform data from the omapdss device, which is a "virtual" device and always has platform data. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: add omap_dss_find_output_by_node()Tomi Valkeinen
Add a support function to find a DSS output by given DT node. This is used in later patches to link the panels to DSS outputs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: add omap_dss_find_output()Tomi Valkeinen
Add a support function to find a DSS output by given name. This is used in later patches to link the panels to DSS outputs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: only probe pdata if there's oneTomi Valkeinen
omapdss output drivers always read the platform data. This crashes when there's no platform data when using DT. Add a check to read the platform data only if it exists. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-06-17OMAPDSS: add pdata->default_display_nameTomi Valkeinen
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>
2013-05-29Merge branch 'fbdev-3.10-fixes' of git://gitorious.org/linux-omap-dss2/linux ↵Jean-Christophe PLAGNIOL-VILLARD
into linux-fbdev/for-3.10-fixes Pull Tomi fixes for ps3fb and omap2 Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
2013-05-28treewide: Fix typo in printkMasanari Iida
Correct spelling typo in various part of drivers Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-23OMAPDSS: Fix crash with DT bootTomi Valkeinen
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>
2013-05-18drivers/video/omap2/dss: don't check resource with devm_ioremap_resourceWolfram Sang
devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-05-18drivers/video/omap2: don't check resource with devm_ioremap_resourceWolfram Sang
devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
2013-05-02Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm updates from Dave Airlie: "This is the main drm pull request for 3.10. Wierd bits: - OMAP drm changes required OMAP dss changes, in drivers/video, so I took them in here. - one more fbcon fix for font handover - VT switch avoidance in pm code - scatterlist helpers for gpu drivers - have acks from akpm Highlights: - qxl kms driver - driver for the spice qxl virtual GPU Nouveau: - fermi/kepler VRAM compression - GK110/nvf0 modesetting support. Tegra: - host1x core merged with 2D engine support i915: - vt switchless resume - more valleyview support - vblank fixes - modesetting pipe config rework radeon: - UVD engine support - SI chip tiling support - GPU registers initialisation from golden values. exynos: - device tree changes - fimc block support Otherwise: - bunches of fixes all over the place." * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (513 commits) qxl: update to new idr interfaces. drm/nouveau: fix build with nv50->nvc0 drm/radeon: fix handling of v6 power tables drm/radeon: clarify family checks in pm table parsing drm/radeon: consolidate UVD clock programming drm/radeon: fix UPLL_REF_DIV_MASK definition radeon: add bo tracking debugfs drm/radeon: add new richland pci ids drm/radeon: add some new SI PCI ids drm/radeon: fix scratch reg handling for UVD fence drm/radeon: allocate SA bo in the requested domain drm/radeon: fix possible segfault when parsing pm tables drm/radeon: fix endian bugs in atom_allocate_fb_scratch() OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not found OMAPDSS: VENC: Add error handling for venc_probe_pdata OMAPDSS: HDMI: Add error handling for hdmi_probe_pdata OMAPDSS: RFBI: Add error handling for rfbi_probe_pdata OMAPDSS: DSI: Add error handling for dsi_probe_pdata OMAPDSS: SDI: Add error handling for sdi_probe_pdata OMAPDSS: DPI: Add error handling for dpi_probe_pdata ...
2013-05-02OMAPDSS: TFP410: return EPROBE_DEFER if the i2c adapter not foundTomi Valkeinen
If the I2C adapter needed by the TFP410 device is not available yet, return EPROBE_DEFER so that the device will get probed again. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: VENC: Add error handling for venc_probe_pdataTomi Valkeinen
Add proper error handling for venc_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the VENC driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: HDMI: Add error handling for hdmi_probe_pdataTomi Valkeinen
Add proper error handling for hdmi_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the HDMI driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: RFBI: Add error handling for rfbi_probe_pdataTomi Valkeinen
Add proper error handling for rfbi_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the RFBI driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: DSI: Add error handling for dsi_probe_pdataTomi Valkeinen
Add proper error handling for dsi_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the DSI driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: SDI: Add error handling for sdi_probe_pdataTomi Valkeinen
Add proper error handling for sdi_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the SDI driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: DPI: Add error handling for dpi_probe_pdataTomi Valkeinen
Add proper error handling for dpi_probe_pdata(). This will cause EPROBE_DEFER to be properly passed upwards, causing the DPI driver to be probed again later if a resource was missing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: VENC: use platform_driver_register()Tomi Valkeinen
Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: HDMI: use platform_driver_register()Tomi Valkeinen
Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: RFBI: use platform_driver_register()Tomi Valkeinen
Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: DSI: use platform_driver_register()Tomi Valkeinen
Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: SDI: use platform_driver_register()Tomi Valkeinen
Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: DPI: use platform_driver_register()Tomi Valkeinen
Use platform_driver_register() instead of platform_driver_probe() so that we can support EPROBE_DEFER. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPFB: defer probe if no displaysTomi Valkeinen
omapfb requires the panel drivers to have been probed when omapfb is initialized. omapfb does not support insertion of new panels after its probe. This causes a problem in case omapdss or the panel probes have been deferred due to EPROBE_DEFER error, as omapfb won't find any displays. As a quick fix, this patch changes the omapfb probe so that if omapfb does not find any displays, it'll return EPROBE_DEFER. This is not perfect, as with a board with no displays, omapfb will get deferred forever. Also, if the board has multiple displays, but only some of them have been probed, omapfb will start and leave the unprobed displays out. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPFB: use module_platform_driver()Tomi Valkeinen
Instead of using platform_driver_probe(), use module_platform_driver() so that we can support deferred probing. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: Makefile: move omapfb after panelsTomi Valkeinen
omapfb requires the panels to have been probed before omapfb's probe. We currently manage that by having omapfb in late initcall level. However, a much simpler way is to just change the makefile so that omapfb is after the panel drivers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-02OMAPDSS: DPI: fix compilation if DSI not compiled inTomi Valkeinen
Commit 100c826235793345efe06b3558cc9d36166b1e26 (OMAPDSS: DPI: use new clock calculation code) breaks dpi.c compilation if DSI is not enabled in the kernel configuration. Fix compilation by adding dummy inline functions for the ones that dpi.c references. The functions will never be called, as dpi.c knows that there is no DSI device available. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-04-26Merge branch '3.10/fb-mmap' into for-nextTomi Valkeinen
Merge topic branch to get vm_iomap_memory into use. Conflicts: drivers/video/fbmon.c
2013-04-24fbdev/omapfb: use vm_iomap_memory()Tomi Valkeinen
Use vm_iomap_memory() instead of [io_]remap_pfn_range(). vm_iomap_memory() gives us much simpler API to map memory to userspace, and reduces possibilities for bugs. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>