summaryrefslogtreecommitdiffstats
path: root/drivers/video/omap2/omapfb/omapfb-main.c
Commit message (Collapse)AuthorAgeFilesLines
* video: move fbdev to drivers/video/fbdevTomi Valkeinen2014-04-171-2656/+0
| | | | | | | | | | | | | | | | | | | | The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Rob Clark <robdclark@gmail.com> Acked-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch '3.15/dss-dt' into 3.15/fbdevTomi Valkeinen2014-03-201-17/+50
|\ | | | | | | Merge OMAP DSS DT support
| * OMAPFB: search for default display with DT aliasTomi Valkeinen2014-03-191-1/+22
| | | | | | | | | | | | | | | | | | Improve the search for the default display in two ways: * compare the given display name to the display's alias * if no display name is given, look for "display0" DT alias Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
| * OMAPFB: clean up default display searchTomi Valkeinen2014-03-191-17/+29
| | | | | | | | | | | | | | | | Separate the code for finding the default display into a function for clarity and to make it easier to extend it in the future. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* | OMAPDSS: convert pixel clock to common videomode styleTomi Valkeinen2014-03-051-4/+4
|/ | | | | | | | | | | | | omapdss has its own video-timings struct, but we want to move the common videomode. The first step is to change the omapdss's pixelclock unit from kHz to Hz. Also, omapdss uses "pixel_clock" field name, whereas the common videomode uses "pixelclock" field name. This patch changes the field name also, as that makes it easy to spot any non-converted pixel_clock uses. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: disable overlays on driver removalTomi Valkeinen2014-01-131-0/+10
| | | | | | | | | | | | | When omapfb module is removed, the driver will turn off all the displays it manages. However, it leaves the overlays enabled. While the overlays are obviously disabled as the displays are disabled, it causes issues when the driver module is loaded again, as at that point the overlays are still enabled on the hardware level. The result is that even if the SW thinks overlays are disabled, they are actually enabled. Fix this by making sure the overlays are disabled at module removal. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: give informative print when probe succeedsTomi Valkeinen2014-01-131-0/+9
| | | | | | | | | | | | | It is quite common to have omapfb probe deferred because of a missing resource, and to get omapfb probed succesfully a bit later. This works fine. However, omapfb does not give any print on a successful probe, so if the omapfb is actually never probed again after deferral, this is not shown in the log. To help debugging, add a simple print from omapfb at the end of its probe, saying which display it is using and in which resolution. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: use EPROBE_DEFER if default display is not presentTomi Valkeinen2013-06-171-1/+1
| | | | | | | | | | | | | | | Currently omapfb returns EPROBE_DEFER if no displays have been probed at the time omapfb is probed. However, sometimes some of the displays have been probed at that time, but not all. We can't return EPROBE_DEFER in that case, because then one missing driver would cause omapfb to defer always, preventing any display from working. However, if the user has defined a default display, we can presume that the driver for that display is eventually loaded. Thus, this patch changes omapfb to return EPROBE_DEFER in case default display is not found. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Implement display (dis)connect supportTomi Valkeinen2013-06-171-11/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 helpers to get mgr or output from displayTomi Valkeinen2013-06-171-9/+7
| | | | | | | | | | 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>
* Merge branch 'fbdev-3.10-fixes' of git://gitorious.org/linux-omap-dss2/linux ↵Jean-Christophe PLAGNIOL-VILLARD2013-05-291-0/+3
|\ | | | | | | | | | | | | | | 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-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2013-05-021-27/+5
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * OMAPFB: defer probe if no displaysTomi Valkeinen2013-05-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAPFB: use module_platform_driver()Tomi Valkeinen2013-05-021-25/+3
| | | | | | | | | | | | | | 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>
| * OMAPDSS: add output->dispc_channelTomi Valkeinen2013-04-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DISPC channel used for each output is currently passed in panel platform data from the board files. To simplify this, and to make the panel drivers less dependent on OMAP, this patch changes omapdss to resolve the channel independently. The channel is resolved based on the OMAP version and, in case of DSI, the DSI module id. This resolved channel is stored into a new field in output, dispc_channel. The few places where dssdev->channel was used are changed to use output->recommended_channel. After this patch, dssdev->channel is obsolete. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Archit Taneja <archit@ti.com>
* | fbdev/omapfb: use vm_iomap_memory()Tomi Valkeinen2013-04-241-23/+7
|/ | | | | | | | 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>
* Revert "OMAPFB: simplify locking"Tomi Valkeinen2012-12-131-10/+30
| | | | | | | | | This reverts commit b41deecbda70067b26a3a7704fdf967a7940935b. The simpler locking causes huge latencies when two processes use the omapfb, even if they use different framebuffers. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: fix error handling in omapfb_find_best_mode()Tomi Valkeinen2012-12-131-0/+6
| | | | | | | | | | omapfb_find_best_mode() doesn't check for the return value of kmalloc. Fix this. This also removes the smatch warning: drivers/video/omap2/omapfb/omapfb-main.c:2256 omapfb_find_best_mode() error: potential null dereference 'specs'. (kzalloc returns null) Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: use devm_kzalloc to allocate omapfb2_deviceTomi Valkeinen2012-12-131-2/+2
| | | | | | | | | | Use devm_kzalloc to allocate omapfb2_device. This fixes possible memory leak: drivers/video/omap2/omapfb/omapfb-main.c:2553 omapfb_probe() warn: possible memory leak of 'fbdev' Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: use omapdss_compat_init() in other driversTomi Valkeinen2012-12-071-0/+6
| | | | | | | | | 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>
* OMAPFB: connect ovl managers to all dssdevsTomi Valkeinen2012-12-071-14/+24
| | | | | | | | | | | | | | | Commit 5d89bcc341771d95e3a2996218e5949a6627f59e (OMAPDSS: remove initial display code from omapdss) moved setting up the initial overlay, overlay manager, output and display connections from omapdss to omapfb. However, currently omapfb only handles the connection related to the default display, which means that no overlay managers are connected to other displays. This patch changes omapfb to go through all dssdevs, and connect an overlay manager to them. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: remove warning when trying to alloc at certain paddressTomi Valkeinen2012-12-071-3/+3
| | | | | | | | | | | | | | | | omapfb gives a WARN_ONCE if a predefined physical address is given for allocating the framebuffer memory, as this is not currently supported. However, the same warning happens if omapfb fails to allocate memory during runtime, as when the allocation has failed, omapfb tries to re-allocate the old memory with the physical address of the old memory area. Remove the warning from omapfb_alloc_fbmem, as it serves no purpose on the failure case above, and move it to omapfb_parse_vram_param, so that we only warn if physical address is given via omapfb module parameters. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: simplify lockingTomi Valkeinen2012-12-071-30/+10
| | | | | | | | | | | | | | | | | | | | | | | Kernel lock verification code has lately detected possible circular locking in omapfb. The exact problem is unclear, but omapfb's current locking seems to be overly complex. This patch simplifies the locking in the following ways: - Remove explicit omapfb mem region locking. I couldn't figure out the need for this, as long as we take care to take omapfb lock. - Get omapfb lock always, even if the operation is possibly only related to one fb_info. Better safe than sorry, and normally there's only one user for the fb so this shouldn't matter. - Make sure fb_info lock is taken first, then omapfb lock. With this patch the warnings about possible circular locking does not happen anymore. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
* OMAPFB: move dssdev->sync call out from omapfb_realloc_fbmemTomi Valkeinen2012-12-071-4/+0
| | | | | | | | | | | | | | Currently omapfb_realloc_fbmem() calls dssdev->sync to ensure any possible frame update is finished. This patch moves the call to dssdev->sync from omapfb_realloc_fbmem to the callers of omapfb_realloc_fbmem. This keeps dssdev related calls out from omapfb_realloc_fbmem, which makes sense as the function should only deal with fb memory. Also, this seems to avoid a lockdep warning about possible circular locking. However, the exact reason for that warning is still unclear. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: Delete if statement evaluating a constant.Matthias Brugger2012-11-191-4/+0
| | | | | | | | Variable r is never set to any value different to zero. Delete the if statement as it will never executed. Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Merge branch '3.8/vram-conversion' of git://gitorious.org/linux-omap-dss2/linuxTomi Valkeinen2012-11-161-33/+36
|\ | | | | | | | | | | | | | | | | | | Conflicts: drivers/video/omap2/dss/Kconfig drivers/video/omap2/omapfb/omapfb-ioctl.c drivers/video/omap2/omapfb/omapfb-main.c Merge changes to make omapfb use common dma_alloc, and remove omap's custom vram allocator.
| * OMAPFB: use dma_alloc_attrs to allocate memoryTomi Valkeinen2012-11-131-33/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use dma_alloc_attrs to allocate memory instead of omap specific vram allocator. After this we can remove the omap vram allocator. There are some downsides to this change: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support "passing" a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as "there's enough vram". 4) "vram" kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use "cma" parameter. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPFB: improve mode selection from EDIDTomi Valkeinen2012-10-291-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current omapfb code goes over all the modes found from the monitors EDID data, and searches for a mode that is compatible with the DSS hardware and has the highest x-res. While this works ok as such, it proves problematic when using DSI PLL for pixel clock. Calculating DSI PLL dividers is not the fastest of the operations, and while doing it for one mode is usually ok, doing it for 20 modes is noticable. Also, the first mode given in the EDID data should be the native mode of the monitor, and thus also the best mode, so if that can be used, no need to look further. This patch changes the code to use the first mode that is compatible with the DSS hardware. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPFB: remove use of extended edid blockTomi Valkeinen2012-10-291-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | It seems that using the second EDID block causes more problems than is of any help. The first mode in the extended block will get FB_MODE_IS_FIRST set, which will override the first mode from the first EDID block, thus making the default videomode selection not to work properly. This patch removes the use of the extended edid block for now. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: remove initial display code from omapdssTomi Valkeinen2012-10-291-11/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently omapdss driver sets up the initial connections between overlays, overlay manager and a panel, based on default display parameter coming from the board file or via module parameters. This is unnecessary, as it's the higher level component that should decide what display to use and how. This patch removes the code from omapdss, and implements similar code to omapfb. The def_disp module parameter and the default display platform_data parameter are kept in omapdss, but omapdss doesn't do anything with them. It will just return the default display name with dss_get_default_display_name() call, which omapfb uses. This is done to keep the backward compatibility. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPDSS: remove omap_dss_device's suspend/resumeTomi Valkeinen2012-10-241-5/+3
| | | | | | | | | | | | | | | | | | | | The panel drivers contain enable, disable, suspend and resume calls. The suspend and resume are effectively identical to disable and enable. This patch removes panel suspend and enable code from omapdss and the panel drivers, and replaces their use with enable and disable. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAPFB: use omap_vrfb_supported()Tomi Valkeinen2012-10-171-5/+1
| | | | | | | | | | | | Replace cpu_is_*() check with omap_vrfb_supported(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | OMAP: move arch/arm/plat-omap/include/plat/vrfb.hTomi Valkeinen2012-10-171-1/+1
|/ | | | | | | | | Now that vrfb driver is not omap dependent anymore, we can move vrfb.h from arch/arm/plat-omap/include/plat to include/video/omapvrfb.h. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
* Merge tag 'fbdev-updates-for-3.7' of git://github.com/schandinat/linux-2.6Linus Torvalds2012-10-121-2/+30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull fbdev updates from Florian Tobias Schandinat: "This includes: - large updates for OMAP - basic OMAP5 DSS support for DPI and DSI outputs - large cleanups and restructuring - some update to Exynos and da8xx-fb - removal of the pnx4008 driver (arch removed) - various other small patches" Fix up some trivial conflicts (mostly just include line changes, but also some due to the renaming of the deferred work functions by Tejun). * tag 'fbdev-updates-for-3.7' of git://github.com/schandinat/linux-2.6: (193 commits) gbefb: fix compile error video: mark nuc900fb_map_video_memory as __devinit video/mx3fb: set .owner to prevent module unloading while being used video: exynos_dp: use clk_prepare_enable and clk_disable_unprepare drivers/video/exynos/exynos_mipi_dsi.c: fix error return code drivers/video/savage/savagefb_driver.c: fix error return code video: s3c-fb: use clk_prepare_enable and clk_disable_unprepare da8xx-fb: save and restore LCDC context across suspend/resume cycle da8xx-fb: add pm_runtime support video/udlfb: fix line counting in fb_write OMAPDSS: add missing include for string.h OMAPDSS: DISPC: Configure color conversion coefficients for writeback OMAPDSS: DISPC: Add manager like functions for writeback OMAPDSS: DISPC: Configure writeback FIFOs OMAPDSS: DISPC: Configure writeback specific parameters in dispc_wb_setup() OMAPDSS: DISPC: Configure overlay-like parameters in dispc_wb_setup OMAPDSS: DISPC: Add function to set channel in for writeback OMAPDSS: DISPC: Don't set chroma resampling bit for writeback OMAPDSS: DISPC: Downscale chroma if plane is writeback OMAPDSS: DISPC: Configure input and output sizes for writeback ...
| * OMAPFB: remove manager->device referencesArchit Taneja2012-09-261-2/+4
| | | | | | | | | | | | | | | | | | | | | | With the introduction of output entities, managers will now connect to outputs. Use the helper op for overlays named get_device. This will abstract away the information on how to get the device from an overlay. Using the helper function will reduce the number of pointer dereferences a user of OMAPDSS needs to do and reduce risk of a NULL dereference. Signed-off-by: Archit Taneja <archit@ti.com>
| * OMAPFB: Clear framebuffers before they are registeredArchit Taneja2012-09-111-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAPFB: clear framebuffers with CPUTomi Valkeinen2012-09-071-0/+26
| | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAPFB: fix framebuffer console colorsGrazvydas Ignotas2012-08-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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 Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* | mm: kill vma flag VM_RESERVED and mm->reserved_vm counterKonstantin Khlebnikov2012-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A long time ago, in v2.4, VM_RESERVED kept swapout process off VMA, currently it lost original meaning but still has some effects: | effect | alternative flags -+------------------------+--------------------------------------------- 1| account as reserved_vm | VM_IO 2| skip in core dump | VM_IO, VM_DONTDUMP 3| do not merge or expand | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP 4| do not mlock | VM_IO, VM_DONTEXPAND, VM_HUGETLB, VM_PFNMAP This patch removes reserved_vm counter from mm_struct. Seems like nobody cares about it, it does not exported into userspace directly, it only reduces total_vm showed in proc. Thus VM_RESERVED can be replaced with VM_IO or pair VM_DONTEXPAND | VM_DONTDUMP. remap_pfn_range() and io_remap_pfn_range() set VM_IO|VM_DONTEXPAND|VM_DONTDUMP. remap_vmalloc_range() set VM_DONTEXPAND | VM_DONTDUMP. [akpm@linux-foundation.org: drivers/vfio/pci/vfio_pci.c fixup] Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Carsten Otte <cotte@de.ibm.com> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Cc: Eric Paris <eparis@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Hugh Dickins <hughd@google.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: James Morris <james.l.morris@oracle.com> Cc: Jason Baron <jbaron@redhat.com> Cc: Kentaro Takeda <takedakn@nttdata.co.jp> Cc: Matt Helsley <matthltc@us.ibm.com> Cc: Nick Piggin <npiggin@kernel.dk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Robert Richter <robert.richter@amd.com> Cc: Suresh Siddha <suresh.b.siddha@intel.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Venkatesh Pallipadi <venki@google.com> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* | ARM: OMAP2+: Prepare for irqs.h removalTony Lindgren2012-09-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the interrupts should only be defined in the platform_data, and eventually coming from device tree, there's no need to define them in header files. Let's remove the hardcoded references to irqs.h and fix up the includes so we don't rely on headers included in irqs.h. Note that we're defining OMAP_INTC_START as 0 to the interrupts. This will be needed when we enable SPARSE_IRQ. For some drivers we need to add #include <plat/cpu.h> for now until these drivers are fixed to remove cpu_is_omapxxxx() usage. While at it, sort som of the includes the standard way, and add the trailing commas where they are missing in the related data structures. Note that for drivers/staging/tidspbridge we just define things locally. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | OMAPFB: fix framebuffer console colorsGrazvydas Ignotas2012-08-231-1/+1
|/ | | | | | | | | | | | | 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>
* OMAPFB: Map interlace field in omap_video_timings with fb vmode flagsArchit Taneja2012-06-291-3/+5
| | | | | | | | | | Use the interlace field in omap_video_timings to configure/retrieve corresponding fb mode flags in fb_var_screeninfo and fb_videomode. The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and FB_VMODE_NONINTERLACED. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPFB: Map the newly added omap_video_timings fields with fb sync flagsArchit Taneja2012-06-291-4/+39
| | | | | | | | | | | | | | | | Use the newly added fields in omap_video_timings(hsync, vsync and data_enable logic levels and data, hsync and vsync latching related info) to configure/retrieve corresponding sync flags in fb_var_screeninfo and fb_videomode. Out of the new fields, hsync_level and vsync_level can be mapped to the fb sync flags FB_SYNC_HOR_HIGH_ACT and FB_SYNC_VERT_HIGH_ACT. When converting fb mode to omap_video_timings, the fields which don't have an equivalent parameter in fb are kept as the original values if the panel driver has a get_timings op, else they are set to default values. Signed-off-by: Archit Taneja <archit@ti.com>
* OMAPFB: 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>
* OMAPFB: add __init & __exitTomi Valkeinen2012-05-111-5/+4
| | | | | | Change omapfb to use platform_driver_probe and add __init & __exit. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: fix parsing of vram parameterTomi Valkeinen2012-05-111-1/+1
| | | | | | | | | | | | | omapfb_parse_vram_param()'s check for end pointer returned from simple_strtoul() is wrong, causing the code to bug if the second or later vram parameters are non-parseable, for example "omapfb.vram=0:2M,:5M". However, even in that case the code will most likely bail out with -EINVAL in the following checks, so the bug is probably not a fatal one. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: Hein Tibosch <hein_tibosch@yahoo.es>
* OMAPFB: remove unused fb_format_to_dss_mode()Tomi Valkeinen2012-02-231-54/+0
| | | | | | fb_format_to_dss_mode() function is no longer used, so remove it. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPFB: remove mem info from platform_dataTomi Valkeinen2012-02-231-43/+0
| | | | | | | | | | | | | | | omapfb driver used platform_data to get fb memory areas and formats defined by the board file. This patch removes omapfb's (both old and new omapfb) use of the memory data in platform_data, because: - No board uses them currently - It's not board file's job to define things like amount of default framebuffer memory. These should come from the bootloader via command line parameters. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAPDSS: Remove video SRAM supportTomi Valkeinen2012-02-231-2/+2
| | | | | | | | | | | | OMAP SRAM can be used as video memory on OMAP1 and 2. However, there usually is very little SRAM available, thus limiting its use, and no board supported by the kernel currently uses it. This patch removes the use of SRAM as video ram for the omapdss driver to simplify memory handling. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: Tony Lindgren <tony@atomide.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-25 23:28:26 +0000