- 23 2月, 2012 5 次提交
-
-
由 Tomi Valkeinen 提交于
omapfb_set_platform_data() is no longer used, so remove it. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
include/linux/omapfb.h contains structs that are used only by the omapfb driver. Move the structs into drivers/video/omap/omapfb.h. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
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: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
arch/arm/plat-omap/fb.c contains code to alloc omapfb buffers at early boot time according to information given from the bootloader or board file. This code isn't currently used by any board, and is anyway something that the newer vram.c could handle. So remove the alloc code and in later patches make old omapfb driver use vram.c. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Tomi Valkeinen 提交于
omapfb_set_ctrl_platform_data() is no longer used, so it can be removed. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Acked-by: NTony Lindgren <tony@atomide.com>
-
- 03 8月, 2010 1 次提交
-
-
由 Ville Syrjälä 提交于
Separate the memory region from the framebuffer device a little bit. It's now possible to select the memory region used by the framebuffer device using the new mem_idx parameter of omapfb_plane_info. If the mem_idx is specified it will be interpreted as an index into the memory regions array, if it's not specified the framebuffer's index is used instead. So by default each framebuffer keeps using it's own memory region which preserves backwards compatibility. This allows cloning the same memory region to several overlays and yet each overlay can be controlled independently since they can be associated with separate framebuffer devices. Signed-off-by: NVille Syrjälä <ville.syrjala@nokia.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-
- 27 7月, 2010 1 次提交
-
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 15 2月, 2010 1 次提交
-
-
由 Tomi Valkeinen 提交于
Previously the only place to get the size of the display was from the DSS's sysfs interface, making, for example, configuring overlays and doing updates on manual displays more difficult. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-
- 09 12月, 2009 2 次提交
-
-
由 Tomi Valkeinen 提交于
Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com>
-
由 Tomi Valkeinen 提交于
Split arch/arm/plat-omap/include/mach/omapfb.h into two files: include/linux/omapfb.h - ioctls etc for userspace and some kernel stuff for board files drivers/video/omap/omapfb.h - for omapfb internal use This cleans up omapfb.h and also makes it easier for the upcoming new DSS driver to co-exist with the old driver. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@nokia.com> Acked-by: NTony Lindgren <tony@atomide.com>
-