aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/video
Commit message (Collapse)AuthorAge
* OMAP: DSS2: DISPC: Fix minimum PCD valueTomi Valkeinen2012-08-17
| | | | | | | | | | | | | | | | | | | | | | The current driver had a hardcoded minimum value of 2 for pixel clock divisor (PCD). This doesn't seem to be right. OMAP4 TRM says that PCD can be 1 when not downscaling, and inverted pixel clock (IPC) is off. OMAP3 TRM says the same, but also in the register descriptions that PCD value 1 is invalid. OMAP2 TRM says PCD 2 is the minimum. OMAP2 is still untested, but for both OMAP3 and OMAP4 PCD of 1 seems to work fine. This patch adds a new DSS feature, FEAT_PARAM_DSS_PCD, which is used to find the minimum and maximum PCD. The minimum is set to 2 for OMAP2, and 1 for OMAP3/4. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: HDMI: change regn definitionTomi Valkeinen2012-08-17
| | | | | | | | | | | | | | regn divider is currently programmed to the registers without change, but when calculating clock frequencies it is used as regn+1. To make this similar to how DSI handles the dividers this patch changes the regn value to be used as such for calculations, but the value programmed to registers is regn-1. This simplifies the clock frequency calculations, makes it similar to DSI, and also allows us to use regn value 0 as undefined. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* OMAP: DSS2: HDMI: use default dividersTomi Valkeinen2012-08-17
| | | | | | | Use default regn and regm2 dividers in the hdmi driver if the board file does not define them. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
* Add omap drm display driverRob Clark2012-08-17
| | | | | | | | | | | | | | | A DSS based DRM display driver, which provides a plugin interface for 3d/2d accelerators to register. The core driver handles construction of CRTC/encoder/connectors to represent the hardware, and support KMS. This driver replaces omapfb. The omap drm driver allocates framebuffer memory and implements (with the help of drm_fb_helper) the legacy fbdev interface. The driver maps CRTCs to overlays, encoders to overlay-managers, and connectors to dssdev's. Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
* OMAP: DSS: HDMI: tame hdmi driverRob Clark2012-08-17
| | | | | | | Main change is to avoid automatically picking timings. Now the driver defaults to a safe 640x480, and leaves it to the upper layer (drm driver) to pick the desired resolution based on what the user selects and the drm infrastucture's parsing of the EDID.
* debug dssAndy Green2012-08-17
| | | | Signed-off-by: Andy Green <andy.green@linaro.org>
* SGX-KM Initial SGX driver integration for 2.6.35 kernel.Hemant Hariyani2012-08-17
| | | | | | | | | This is the first version of SGX driver integration to ensure UI boot-up. Power management and hwmod modifications will be added as patches. Change-Id: If71e6cd651a53f4809e7b978b693cb7d1a89178d Signed-off-by: Hemant Hariyani <hemanthariyani@ti.com>
* omap dss use correct codec nameAndy Green2012-08-17
| | | | Signed-off-by: Andy Green <andy.green@linaro.org>
* omap dss unable to bring up hdmi nonfatalAndy Green2012-08-17
| | | | | | | | | | If the HDMI connector isn't in, the generic enable_panel callback fails and the omap framebuffer code fails probe wholesale. This swallows the error if the display was unable to be enabled; the box can still work as headless then. Signed-off-by: Andy Green <andy.green@linaro.org>
* OMAP: DSS: ensure default panel is enabledAndy Doan2012-08-17
| | | | | | | | | | In the event a panel is not probable (no i2c_bus_num), we should make sure that the default panel passed to the kernel marked enabled Adapted to be more paranoid and work in Panda case. Signed-off-by: Andy Doan <andy.doan@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org>
* OMAP DSS: allow discovery of default displayAndy Doan2012-08-17
| | | | | | | | Enable code outside of DSS core to find out the default display that was passed to the kernel Signed-off-by: Andy Doan <andy.doan@linaro.org> Signed-off-by: Andy Green <andy.green@linaro.org>
* Subject: [PATCH] omap4: dss: hdmi: find best matching resolutionZach Pfeffer2012-08-17
| | | | | | | | | | | | | | | | | | | Based off: "OMAP4:DSS:HDMI: Patch to add seperate edid.c" Commited by: Ricardo Perez Olivares <x0081762@ti.com> Written by: Mythri P K <mythripk@ti.com> EDID parsing for DVI Monitor from: Rob Clark <rob@ti.com> Some of the ENUM's and structure derived from hdmi.h from: Yong Zhi <y-zhi@ti.com> Signed-off-by: Zach Pfeffer <zach.pfeffer@linaro.org>
* Subject: [PATCH 18/21] Subject: [PATCH 17/19] OMAPFB: re-allocate FB if ↵Sebastien Jan2012-08-17
| | | | | | | | | | | | | needed on resize notification Note that re-allocating can fragment vram, so to avoid re-allocation, pre-assign FB size with kernel bootargs like: omapfb.vram=0:8M,1:8M Note: prevent the console accessing the FB while re-allocation is running. Other early FB users would be an issue as well. Signed-off-by: Sebastien Jan <s-jan@ti.com>
* Subject: [PATCH 17/21] Subject: [PATCH 15/19] OMAP2: HDMI: Assume EDID read ↵Jassi Brar2012-08-17
| | | | | | | | | | | | success as detection Some class of hdmi displays never make the bit(2) of HDMI_CORE_SYS_SYS_STAT set. EDID is read before calls to is_detected callback, so if reading EDID succeeded that implies we do have HDMI connected. In that case skip reading/waiting on the second bit. Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
* Subject: [PATCH 16/21] Subject: [PATCH 13/19] OMAP4: DSS2: HDMI: adding a ↵Ricardo Salveti de Araujo2012-08-17
| | | | | | | | | | workaround for LG monitors Some monitors report a disconnect just after a connect, so if force is enabled, give some time and check at least one more time. This is a needed workaround to make the driver work with LG monitors. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
* Subject: [PATCH 14/21] Subject: [PATCH 16/19] OMAP4: OMAPFB: register ↵Sebastien Jan2012-08-17
| | | | | | | | | | | callback to get notified of resolution change Protect fb_set_var() with console-sem to avoid making console driver unhappy. Supports more than one framebuffer. This is a port from Rob Clark <rob@ti.com> patch. Signed-off-by: Sebastien Jan <s-jan@ti.com>
* Subject: [PATCH 13/21] Subject: [PATCH 14/19] OMAP2: DSS: HDMI: removing ↵Ricardo Salveti de Araujo2012-08-17
| | | | | | | | | | | error msg from check_timing The check_timing call is used to validate the timing before actually appling it, so it's expected to treat unsupported timings. It makes no sense to print an error message for the user saying that the timing could not be applied (it's not even being applied by this function). Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
* Subject: [PATCH 12/21] Subject: [PATCH 12/19] hdmi add notificationAndy Green2012-08-17
| | | | Signed-off-by: Andy Green <andy.green@linaro.org>
* Subject: [PATCH 11/21] Subject: [PATCH 11/19] OMAP4: DSS: add generic ↵Sebastien Jan2012-08-17
| | | | | | | | | | | | | | | | notifier mechanism A callback can be registered by the dssdev client in order to be notified of resolution changes, for example an external monitor that is hot-plugged. Multiple clients can now register for notification from one dssdev, and the notification mechanism can be extended in the future to add other events. This is a port of Rob Clark's <rob@ti.com> original patch. Signed-off-by: Sebastien Jan <s-jan@ti.com>
* Subject: [PATCH 10/21] Subject: [PATCH 10/19] OMAP: DSS2: handle null ↵Andy Doan2012-08-17
| | | | | | | pointer for no attached panel A null pointer error occurs when a board file configures a panel (LCD in my case) but doesn't have one attached
* Subject: [PATCH 09/21] Subject: [PATCH 09/19] OMAP: DSS2: Avoid enabling ↵Ricardo Salveti de Araujo2012-08-17
| | | | | | panel if none is around Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
* Subject: [PATCH 08/21] Subject: [PATCH 08/19] OMAP: DSS2: adding force ↵Jassi Brar2012-08-17
| | | | | | | | | | | argument to is_detected() Force is available from (*detect) at drm_connector_funcs, and can be used by the driver to avoid expensive, destructive operations during automated probing. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
* Subject: [PATCH 07/21] Subject: [PATCH 07/19] OMAP: DSS2: add get_edid and ↵Ricardo Salveti de Araujo2012-08-17
| | | | | | is_detected support Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
* Subject: [PATCH 06/21] Subject: [PATCH 06/19] OMAP: DSS2: HDMI: Adding ↵Ricardo Salveti de Araujo2012-08-17
| | | | | | | | is_detected callback support This is a port from Rob Clark <rob@ti.com> patch. Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com>
* Subject: [PATCH 05/21] Subject: [PATCH 04/19] OMAP: DSS2: Add is_detected() ↵Jassi Brar2012-08-17
| | | | | | | | | | | | | driver API The API should return whether the device is detected, and if applicable whether the cable is plugged in. For non-hot-plug devices, it simply means "is the display/panel present". For hot-plug devices it means "is the cable plugged in". Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
* Subject: [PATCH 03/21] Subject: [PATCH 03/19] OMAP: DSS2: Add default ↵Jassi Brar2012-08-17
| | | | | | | | get/check timings functions Signed-off-by: Rob Clark <rob@ti.com> Signed-off-by: Ricardo Salveti de Araujo <ricardo.salveti@canonical.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
* Subject: [PATCH 02/21] Subject: [PATCH 01/19] OMAP4: DSS: add generic ↵Jassi Brar2012-08-17
| | | | | | | | | | | | | | | | | notifier mechanism A callback can be registered by the dssdev client in order to be notified of resolution changes, for example an external monitor that is hot-plugged. Multiple clients can now register for notification from one dssdev, and the notification mechanism can be extended in the future to add other events. This is a port of Rob Clark's <rob@ti.com> original patch. Signed-off-by: Sebastien Jan <s-jan@ti.com> Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
* config omap2plus dss enable sdi dss omap4Andy Green2012-08-17
| | | | Signed-off-by: Andy Green <andy.green@linaro.org>
* After resume the HDMI/DVI output was still blank. It turns out thatKan-Ru Chen2012-08-17
| | | | | | framebuffers have to be reconfigured so the output is activated again. Signed-off-by: Kan-Ru Chen <kanru@0xlab.org>
* video:uvesafb: Fix oops that uvesafb try to execute NX-protected pageWang YanQing2012-05-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/987283 commit b78f29ca0516266431688c5eb42d39ce42ec039a upstream. This patch fix the oops below that catched in my machine [ 81.560602] uvesafb: NVIDIA Corporation, GT216 Board - 0696a290, Chip Rev , OEM: NVIDIA, VBE v3.0 [ 81.609384] uvesafb: protected mode interface info at c000:d350 [ 81.609388] uvesafb: pmi: set display start = c00cd3b3, set palette = c00cd40e [ 81.609390] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da [ 81.614558] uvesafb: VBIOS/hardware doesn't support DDC transfers [ 81.614562] uvesafb: no monitor limits have been set, default refresh rate will be used [ 81.614994] uvesafb: scrolling: ypan using protected mode interface, yres_virtual=4915 [ 81.744147] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 81.744153] BUG: unable to handle kernel paging request at c00cd3b3 [ 81.744159] IP: [<c00cd3b3>] 0xc00cd3b2 [ 81.744167] *pdpt = 00000000016d6001 *pde = 0000000001c7b067 *pte = 80000000000cd163 [ 81.744171] Oops: 0011 [#1] SMP [ 81.744174] Modules linked in: uvesafb(+) cfbcopyarea cfbimgblt cfbfillrect [ 81.744178] [ 81.744181] Pid: 3497, comm: modprobe Not tainted 3.3.0-rc4NX+ #71 Acer Aspire 4741 /Aspire 4741 [ 81.744185] EIP: 0060:[<c00cd3b3>] EFLAGS: 00010246 CPU: 0 [ 81.744187] EIP is at 0xc00cd3b3 [ 81.744189] EAX: 00004f07 EBX: 00000000 ECX: 00000000 EDX: 00000000 [ 81.744191] ESI: f763f000 EDI: f763f6e8 EBP: f57f3a0c ESP: f57f3a00 [ 81.744192] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 81.744195] Process modprobe (pid: 3497, ti=f57f2000 task=f748c600 task.ti=f57f2000) [ 81.744196] Stack: [ 81.744197] f82512c5 f759341c 00000000 f57f3a30 c124a9bc 00000001 00000001 000001e0 [ 81.744202] f8251280 f763f000 f7593400 00000000 f57f3a40 c12598dd f5c0c000 00000000 [ 81.744206] f57f3b10 c1255efe c125a21a 00000006 f763f09c 00000000 c1c6cb60 f7593400 [ 81.744210] Call Trace: [ 81.744215] [<f82512c5>] ? uvesafb_pan_display+0x45/0x60 [uvesafb] [ 81.744222] [<c124a9bc>] fb_pan_display+0x10c/0x160 [ 81.744226] [<f8251280>] ? uvesafb_vbe_find_mode+0x180/0x180 [uvesafb] [ 81.744230] [<c12598dd>] bit_update_start+0x1d/0x50 [ 81.744232] [<c1255efe>] fbcon_switch+0x39e/0x550 [ 81.744235] [<c125a21a>] ? bit_cursor+0x4ea/0x560 [ 81.744240] [<c129b6cb>] redraw_screen+0x12b/0x220 [ 81.744245] [<c128843b>] ? tty_do_resize+0x3b/0xc0 [ 81.744247] [<c129ef42>] vc_do_resize+0x3d2/0x3e0 [ 81.744250] [<c129efb4>] vc_resize+0x14/0x20 [ 81.744253] [<c12586bd>] fbcon_init+0x29d/0x500 [ 81.744255] [<c12984c4>] ? set_inverse_trans_unicode+0xe4/0x110 [ 81.744258] [<c129b378>] visual_init+0xb8/0x150 [ 81.744261] [<c129c16c>] bind_con_driver+0x16c/0x360 [ 81.744264] [<c129b47e>] ? register_con_driver+0x6e/0x190 [ 81.744267] [<c129c3a1>] take_over_console+0x41/0x50 [ 81.744269] [<c1257b7a>] fbcon_takeover+0x6a/0xd0 [ 81.744272] [<c12594b8>] fbcon_event_notify+0x758/0x790 [ 81.744277] [<c10929e2>] notifier_call_chain+0x42/0xb0 [ 81.744280] [<c1092d30>] __blocking_notifier_call_chain+0x60/0x90 [ 81.744283] [<c1092d7a>] blocking_notifier_call_chain+0x1a/0x20 [ 81.744285] [<c124a5a1>] fb_notifier_call_chain+0x11/0x20 [ 81.744288] [<c124b759>] register_framebuffer+0x1d9/0x2b0 [ 81.744293] [<c1061c73>] ? ioremap_wc+0x33/0x40 [ 81.744298] [<f82537c6>] uvesafb_probe+0xaba/0xc40 [uvesafb] [ 81.744302] [<c12bb81f>] platform_drv_probe+0xf/0x20 [ 81.744306] [<c12ba558>] driver_probe_device+0x68/0x170 [ 81.744309] [<c12ba731>] __device_attach+0x41/0x50 [ 81.744313] [<c12b9088>] bus_for_each_drv+0x48/0x70 [ 81.744316] [<c12ba7f3>] device_attach+0x83/0xa0 [ 81.744319] [<c12ba6f0>] ? __driver_attach+0x90/0x90 [ 81.744321] [<c12b991f>] bus_probe_device+0x6f/0x90 [ 81.744324] [<c12b8a45>] device_add+0x5e5/0x680 [ 81.744329] [<c122a1a3>] ? kvasprintf+0x43/0x60 [ 81.744332] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70 [ 81.744335] [<c121e6e4>] ? kobject_set_name_vargs+0x64/0x70 [ 81.744339] [<c12bbe9f>] platform_device_add+0xff/0x1b0 [ 81.744343] [<f8252906>] uvesafb_init+0x50/0x9b [uvesafb] [ 81.744346] [<c100111f>] do_one_initcall+0x2f/0x170 [ 81.744350] [<f82528b6>] ? uvesafb_is_valid_mode+0x66/0x66 [uvesafb] [ 81.744355] [<c10c6994>] sys_init_module+0xf4/0x1410 [ 81.744359] [<c1157fc0>] ? vfsmount_lock_local_unlock_cpu+0x30/0x30 [ 81.744363] [<c144cb10>] sysenter_do_call+0x12/0x36 [ 81.744365] Code: f5 00 00 00 32 f6 66 8b da 66 d1 e3 66 ba d4 03 8a e3 b0 1c 66 ef b0 1e 66 ef 8a e7 b0 1d 66 ef b0 1f 66 ef e8 fa 00 00 00 61 c3 <60> e8 c8 00 00 00 66 8b f3 66 8b da 66 ba d4 03 b0 0c 8a e5 66 [ 81.744388] EIP: [<c00cd3b3>] 0xc00cd3b3 SS:ESP 0068:f57f3a00 [ 81.744391] CR2: 00000000c00cd3b3 [ 81.744393] ---[ end trace 18b2c87c925b54d6 ]--- Signed-off-by: Wang YanQing <udknight@gmail.com> Cc: Michal Januszewski <spock@gentoo.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* backlight: fix typo in tosa_lcd.cMasanari Iida2012-04-05
| | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/971808 commit 8da00edc1069f01c34510fa405dc15d96c090a3f upstream. Fix typo in drivers/video/backlight/tosa_lcd.c "tosa_lcd_reume" should be "tosa_lcd_resume". Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* udlfb: remove sysfs framebuffer device with USB .disconnect()Kay Sievers2012-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/971808 commit ce880cb860f36694d2cdebfac9e6ae18176fe4c4 upstream. The USB graphics card driver delays the unregistering of the framebuffer device to a workqueue, which breaks the userspace visible remove uevent sequence. Recent userspace tools started to support USB graphics card hotplug out-of-the-box and rely on proper events sent by the kernel. The framebuffer device is a direct child of the USB interface which is removed immediately after the USB .disconnect() callback. But the fb device in /sys stays around until its final cleanup, at a time where all the parent devices have been removed already. To work around that, we remove the sysfs fb device directly in the USB .disconnect() callback and leave only the cleanup of the internal fb data to the delayed work. Before: add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) remove /2-1.2:1.0/graphics/fb0 (graphics) After: add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb) remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb) Tested-by: Bernie Thompson <bernie@plugable.com> Acked-by: Bernie Thompson <bernie@plugable.com> Signed-off-by: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* UBUNTU: SAUCE: (no-up) remove __initdata from vesafb_fixTim Gardner2012-04-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/969309 OK. Then, I think we also want to fix these warnings probably introduced by commit a6021559 "UBUNTU: SAUCE: (no-up) Modularize vesafb". WARNING: drivers/video/vesafb.o(.exit.text+0x42): Section mismatch in reference from the function vesafb_remove() to the (unknown reference) .init.data:(unknown) The function __exit vesafb_remove() references a (unknown reference) __initdata (unknown). This is often seen when error handling in the exit function uses functionality in the init path. The fix is often to remove the __initdata annotation of (unknown) so it may be used outside an init section. WARNING: drivers/video/vesafb.o(.exit.text+0x4a): Section mismatch in reference from the function vesafb_remove() to the variable .init.data:vesafb_fix The function __exit vesafb_remove() references a variable __initdata vesafb_fix. This is often seen when error handling in the exit function uses functionality in the init path. The fix is often to remove the __initdata annotation of vesafb_fix so it may be used outside an init section. Reported-by: Tetsuo Honda <from-ubuntu@I-love.SAKURA.ne.jp> Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Colin King <colin.king@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
* usermodehelper: use UMH_WAIT_PROC consistentlyOleg Nesterov2012-04-05
| | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/963685 A few call_usermodehelper() callers use the hardcoded constant instead of the proper UMH_WAIT_PROC, fix them. Reported-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by: Oleg Nesterov <oleg@redhat.com> Cc: Lars Ellenberg <drbd-dev@lists.linbit.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Michal Januszewski <spock@gentoo.org> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Kentaro Takeda <takedakn@nttdata.co.jp> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: James Morris <jmorris@namei.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (back ported from commit 70834d3070c3f3015ab5c05176d54bd4a0100546) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
* OMAPDSS: HDMI: PHY burnout fixTomi Valkeinen2012-03-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/954576 commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd upstream. A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board if the HDMI PHY is kept powered on when the cable is not connected. This patch solves the problem by adding hot-plug-detection into the HDMI IP driver. This is not a real HPD support in the sense that nobody else than the IP driver gets to know about the HPD events, but is only meant to fix the HW bug. The strategy is simple: If the display device is turned off by the user, the PHY power is set to OFF. When the display device is turned on by the user, the PHY power is set either to LDOON or TXON, depending on whether the HDMI cable is connected. The reason to avoid PHY OFF when the display device is on, but the cable is disconnected, is that when the PHY is turned OFF, the HDMI IP is not "ticking" and thus the DISPC does not receive pixel clock from the HDMI IP. This would, for example, prevent any VSYNCs from happening, and would thus affect the users of omapdss. By using LDOON when the cable is disconnected we'll avoid the HW bug, but keep the HDMI working as usual from the user's point of view. Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* OMAP: DSS2: HDMI: use default dividersTomi Valkeinen2012-03-26
| | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/954576 commit 8d88767a4377171752c22ac39bcb2b505eb751da upstream. Use default regn and regm2 dividers in the hdmi driver if the board file does not define them. Cc: Mythri P K <mythripk@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* atmel_lcdfb: fix usage of CONTRAST_CTR in suspend/resumeHubert Feurstein2012-03-08
| | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/931719 commit 9f1065032ceb7e86c7c9f16bb86518857e88a172 upstream. An error was existing in the saving of CONTRAST_CTR register across suspend/resume. Signed-off-by: Hubert Feurstein <h.feurstein@gmail.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* offb: Fix bug in calculating requested vram sizeBenjamin Herrenschmidt2012-01-23
| | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/915926 commit c055fe0797b7bd8f6f21a13598a55a16d5c13ae7 upstream. We used to try to request 8 times more vram than needed, which would fail if the card has a too small BAR (observed with qemu & kvm). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Brad Figg <brad.figg@canonical.com>
* offb: Fix setting of the pseudo-palette for >8bppBenjamin Herrenschmidt2012-01-23
| | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/915926 commit 1bb0b7d21584b3f878e2bc880db62351ddee5185 upstream. When using a >8bpp framebuffer, offb advertises truecolor, not directcolor, and doesn't touch the color map even if it has a corresponding access method for the real hardware. Thus it needs to set the pseudo-palette with all 3 components of the color, like other truecolor framebuffers, not with copies of the color index like a directcolor framebuffer would do. This went unnoticed for a long time because it's pretty hard to get offb to kick in with anything but 8bpp (old BootX under MacOS will do that and qemu does it). Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com> Signed-off-by: Brad Figg <brad.figg@canonical.com>
* viafb: correct sync polarity for OLPC DCONDaniel Drake2011-12-12
| | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/902312 commit a32839696a8eef813a1aff604fbad9a32dff6c95 upstream. While the OLPC display appears to be able to handle either positive or negative sync, the Display Controller only recognises positive sync. This brings viafb (for XO-1.5) in line with lxfb (for XO-1) and fixes a recent regression where the XO-1.5 DCON could no longer be frozen. Thanks to Florian Tobias Schandinat for helping identify the fix. Test case: from a vt, echo 1 > /sys/devices/platform/dcon/freeze should cause the current screen contents to freeze, rather than garbage being displayed. Signed-off-by: Daniel Drake <dsd@laptop.org> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* viafb: improve pitch handlingFlorian Tobias Schandinat2011-11-21
| | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/890952 commit 936a3f770b8de7042d793272f008ef1bb08522e9 upstream. This patch adds checks for minimum and maximum pitch size to prevent invalid settings which could otherwise crash the machine. Also the alignment is done in a slightly more readable way. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* viafb: use display information in info not in var for panningFlorian Tobias Schandinat2011-11-21
| | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/890952 commit d933990c57b498c092ceef591c7c5d69dbfe9f30 upstream. As Laurent pointed out we must not use any information in the passed var besides xoffset, yoffset and vmode as otherwise applications might abuse it. Also use the aligned fix.line_length and not the (possible) unaligned xres_virtual. Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* fb: sh-mobile: Fix deadlock risk between lock_fb_info() and console_lock()Bruno Prémont2011-11-21
| | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/890952 commit 4a47a0e09c504e3ce0ccdb405411aefc5b09deb8 upstream. Following on Herton's patch "fb: avoid possible deadlock caused by fb_set_suspend" which moves lock_fb_info() out of fb_set_suspend() to its callers, correct sh-mobile's locking around call to fb_set_suspend() and the same sort of deaklocks with console_lock() due to order of taking the lock. console_lock() must be taken while fb_info is already locked and fb_info must be locked while calling fb_set_suspend(). Signed-off-by: Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* fb: avoid possible deadlock caused by fb_set_suspendHerton Ronaldo Krzesinski2011-11-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/890952 commit 9e769ff3f585db8f978f9113be83d36c7e3965dd upstream. A lock ordering issue can cause deadlocks: in framebuffer/console code, all needed struct fb_info locks are taken before acquire_console_sem(), in places which need to take console semaphore. But fb_set_suspend is always called with console semaphore held, and inside it we call lock_fb_info which gets the fb_info lock, inverse locking order of what the rest of the code does. This causes a real deadlock issue, when we write to state fb sysfs attribute (which calls fb_set_suspend) while a framebuffer is being unregistered by remove_conflicting_framebuffers, as can be shown by following show blocked state trace on a test program which loads i915 and runs another forked processes writing to state attribute: Test process with semaphore held and trying to get fb_info lock: .. fb-test2 D 0000000000000000 0 237 228 0x00000000 ffff8800774f3d68 0000000000000082 00000000000135c0 00000000000135c0 ffff880000000000 ffff8800774f3fd8 ffff8800774f3fd8 ffff880076ee4530 00000000000135c0 ffff8800774f3fd8 ffff8800774f2000 00000000000135c0 Call Trace: [<ffffffff8141287a>] __mutex_lock_slowpath+0x11a/0x1e0 [<ffffffff814142f2>] ? _raw_spin_lock_irq+0x22/0x40 [<ffffffff814123d3>] mutex_lock+0x23/0x50 [<ffffffff8125dfc5>] lock_fb_info+0x25/0x60 [<ffffffff8125e3f0>] fb_set_suspend+0x20/0x80 [<ffffffff81263e2f>] store_fbstate+0x4f/0x70 [<ffffffff812e7f70>] dev_attr_store+0x20/0x30 [<ffffffff811c46b4>] sysfs_write_file+0xd4/0x160 [<ffffffff81155a26>] vfs_write+0xc6/0x190 [<ffffffff81155d51>] sys_write+0x51/0x90 [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b .. modprobe process stalled because has the fb_info lock (got inside unregister_framebuffer) but waiting for the semaphore held by the test process which is waiting to get the fb_info lock: .. modprobe D 0000000000000000 0 230 218 0x00000000 ffff880077a4d618 0000000000000082 0000000000000001 0000000000000001 ffff880000000000 ffff880077a4dfd8 ffff880077a4dfd8 ffff8800775a2e20 00000000000135c0 ffff880077a4dfd8 ffff880077a4c000 00000000000135c0 Call Trace: [<ffffffff81411fe5>] schedule_timeout+0x215/0x310 [<ffffffff81058051>] ? get_parent_ip+0x11/0x50 [<ffffffff814130dd>] __down+0x6d/0xb0 [<ffffffff81089f71>] down+0x41/0x50 [<ffffffff810629ac>] acquire_console_sem+0x2c/0x50 [<ffffffff812ca53d>] unbind_con_driver+0xad/0x2d0 [<ffffffff8126f5f7>] fbcon_event_notify+0x457/0x890 [<ffffffff814144ff>] ? _raw_spin_unlock_irqrestore+0x1f/0x50 [<ffffffff81058051>] ? get_parent_ip+0x11/0x50 [<ffffffff8141836d>] notifier_call_chain+0x4d/0x70 [<ffffffff8108a3b8>] __blocking_notifier_call_chain+0x58/0x80 [<ffffffff8108a3f6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff8125dabb>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff8125e6ac>] unregister_framebuffer+0x7c/0x130 [<ffffffff8125e8b3>] remove_conflicting_framebuffers+0x153/0x180 [<ffffffff8125eef3>] register_framebuffer+0x93/0x2c0 [<ffffffffa0331112>] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper] [<ffffffffa03314a3>] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper] [<ffffffffa03318dd>] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper] [<ffffffffa037b588>] intel_fbdev_init+0xa8/0x160 [i915] [<ffffffffa0343d74>] i915_driver_load+0x854/0x12b0 [i915] [<ffffffffa02f0e7e>] drm_get_pci_dev+0x19e/0x360 [drm] [<ffffffff8141821d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffffa0386f91>] i915_pci_probe+0x15/0x17 [i915] [<ffffffff8124481f>] local_pci_probe+0x5f/0xd0 [<ffffffff81244f89>] pci_device_probe+0x119/0x120 [<ffffffff812eccaa>] ? driver_sysfs_add+0x7a/0xb0 [<ffffffff812ed003>] driver_probe_device+0xa3/0x290 [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0 [<ffffffff812ed29b>] __driver_attach+0xab/0xb0 [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0 [<ffffffff812ebd3e>] bus_for_each_dev+0x5e/0x90 [<ffffffff812ecc2e>] driver_attach+0x1e/0x20 [<ffffffff812ec6f2>] bus_add_driver+0xe2/0x320 [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffff812ed536>] driver_register+0x76/0x140 [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffff81245216>] __pci_register_driver+0x56/0xd0 [<ffffffffa02f1264>] drm_pci_init+0xe4/0xf0 [drm] [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffffa02e84a8>] drm_init+0x58/0x70 [drm] [<ffffffffa03aa094>] i915_init+0x94/0x96 [i915] [<ffffffff81002194>] do_one_initcall+0x44/0x190 [<ffffffff810a066b>] sys_init_module+0xcb/0x210 [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b .. fb-test2 which reproduces above is available on kernel.org bug #26232. To solve this issue, avoid calling lock_fb_info inside fb_set_suspend, and move it out to where needed (callers of fb_set_suspend must call lock_fb_info before if needed). So far, the only place which needs to call lock_fb_info is store_fbstate, all other places which calls fb_set_suspend are suspend/resume hooks that should not need the lock as they should be run only when processes are already frozen in suspend/resume. References: https://bugzilla.kernel.org/show_bug.cgi?id=26232 Signed-off-by: Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* carminefb: Fix module parameters permissionsJean Delvare2011-11-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/890952 commit c84c14224bbca6ec60d5851fcc87be0e34df2f44 upstream. The third parameter of module_param is supposed to be an octal value. The missing leading "0" causes the following: $ ls -l /sys/module/carminefb/parameters/ total 0 -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_displays -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode_str After fixing the perm parameter, we get the expected: $ ls -l /sys/module/carminefb/parameters/ total 0 -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_displays -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode_str Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* savagedb: Fix typo causing regression in savage4 series video chip detectionJohn Stanley2011-09-13
| | | | | | | | | | | | | | | | | | | | http://bugs.launchpad.net/bugs/848773 Two additional savage4 variants were added, but the S3_SAVAGE4_SERIES macro was incompletely modified, resulting in a false positive detection of a savage4 card regardless of which savage card is actually present. For non-savage4 series cards, such as a Savage/IX-MV card, this results in garbled video and/or a hard-hang at boot time. Fix this by changing an '||' to an '&&' in the S3_SAVAGE4_SERIES macro. Signed-off-by: John P. Stanley <jpsinthemix@verizon.net> Reviewed-by: Tormod Volden <debian.tormod@gmail.com> [ The macros have incomplete parenthesis too, but whatever .. -Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 4b00e4b3940eabb38adeec0823751820fe2d6fda) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
* Revert "UBUNTU: SAUCE: OMAP: DSS2: check for both cpu type and revision, ↵Leann Ogasawara2011-08-30
| | | | | | | | rather than just revision" This reverts commit f9c5baa2a6f1cbaa587840a5acbccf1e750ee333. Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
* Revert "UBUNTU: SAUCE: OMAP: DSS2: enable hsclk in dsi_pll_init for OMAP36XX"Leann Ogasawara2011-08-30
| | | | | | This reverts commit d360158cc2b48727a2215ebc1e78c3b1d171335e. Signed-off-by: Leann Ogasawara <leann.ogasawara@canonical.com>
* UBUNTU: SAUCE: vesafb: enable mtrr WC by defaultThomas Schlichter2011-08-30
| | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/778043 Move to enabling a write-combining MTRR by default, this then matches the uvesafb module. Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
* UBUNTU: SAUCE: vesafb: mtrr module parameter is uint, not boolThomas Schlichter2011-08-30
| | | | | | | | | | | BugLink: http://bugs.launchpad.net/bugs/778043 As noted by the reporter the mtrr kernel command line option is actually a positive numeric not a boolean, move the module parameter we add to match. Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-04-23 19:02:09 -0400