summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2012-04-09rtlwifi: Fix oops on rate-control failureLarry Finger
When the rate-control indexing is incorrectly set up, mac80211 issues a warning and returns NULL from the call to ieee80211_get_tx_rate(). When this happens, avoid a NULL pointer dereference. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-09mac80211: Convert WARN_ON to WARN_ON_ONCELarry Finger
When the control-rate tables are not set up correctly, it makes little sense to spam the logs, thus change the WARN_ON to WARN_ON_ONCE. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-09rtlwifi: rtl8192de: Fix firmware initializationLarry Finger
Before the switch to asynchronous firmware loading (mainline commit b0302ab), it was necessary to load firmware when initializing the first of the units in a dual-mac system. After the change, it is necessary to load firmware in both units. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-09nl80211: ensure interface is up in various APIsJohannes Berg
The nl80211 handling code should ensure as much as it can that the interface is in a valid state, it can certainly ensure the interface is running. Not doing so can cause calls through mac80211 into the driver that result in warnings and unspecified behaviour in the driver. Cc: stable@vger.kernel.org Reported-by: Ben Greear <greearb@candelatech.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-09mac80211: fix association beacon wait timeoutJohannes Berg
The TU_TO_EXP_TIME() macro already includes the "jiffies +" piece of the calculation, so don't add jiffies again. Reported-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Tested-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2012-04-09drm/i915: Finish any pending operations on the framebuffer before disablingChris Wilson
Similar to the case where we are changing from one framebuffer to another, we need to be sure that there are no pending WAIT_FOR_EVENTs on the pipe for the current framebuffer before switching. If we disable the pipe, and then try to execute a WAIT_FOR_EVENT it will block indefinitely and cause a GPU hang. We attempted to fix this in commit 85345517fe6d4de27b0d6ca19fef9d28ac947c4a (drm/i915: Retire any pending operations on the old scanout when switching) for the case of mode switching, but this leaves the condition where we are switching off the pipe vulnerable. There still remains the race condition were a display may be unplugged, switched off by the core, a uevent sent to notify the DDX and the DDX may issue a WAIT_FOR_EVENT before it processes the uevent. This window does not exist if the pipe is only switched off in response to the uevent. Time to make sure that is so... Reported-by: Francis Leblanc <Francis.Leblanc-Lebeau@verint.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36515 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> [danvet: fixup spelling in comment, noticed by Eugeni.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: Removed IVB forced enable of sprite dest key.acreese
The destination color key is always enabled for IVB. Removed the line that does this. Signed-off-by: Armin Reese <armin.c.reese@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09Merge branch 'master' of ↵John W. Linville
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
2012-04-09hwmon: (pmbus_core) Fix compiler warningGuenter Roeck
Some configurations produce the following compiler warning: drivers/hwmon/pmbus/pmbus_core.c: In function 'pmbus_show_boolean': drivers/hwmon/pmbus/pmbus_core.c:752: warning: 'val' may be used uninitialized in this function While this is a false positive, it can easily be fixed by overloading the return value from pmbus_get_boolean with both val and error return code (val is a boolean and thus never negative). Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
2012-04-09hwmon: (smsc47m1) Fix compiler warningGuenter Roeck
Some configurations produce the following compiler warning: drivers/hwmon/smsc47m1.c: In function 'sm_smsc47m1_init': drivers/hwmon/smsc47m1.c:938: warning: 'address' may be used uninitialized in this function While this is a false positive, it can easily be fixed by overloading the return value from smsc47m1_find with both address and error return code (the address is an unsigned short and thus never negative). This also reduces module size by a few bytes (46 bytes for x86_64). Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
2012-04-09hwmon: (acpi_power_meter) Fix compiler warning seen in some configurationsGuenter Roeck
In some configurations, BUG() does not result in an endless loop but returns to the caller. This results in the following compiler warning: drivers/hwmon/acpi_power_meter.c: In function 'show_str': drivers/hwmon/acpi_power_meter.c:380: warning: 'val' may be used uninitialized in this function Fix the warning by setting val to an empty string after BUG(). Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
2012-04-09hwmon: (smsc47b397) Fix compiler warningGuenter Roeck
Some configurations produce the following compiler warning: drivers/hwmon/smsc47b397.c: In function 'smsc47b397_init': drivers/hwmon/smsc47b397.c:385: warning: 'address' may be used uninitialized in this function While this is a false positive, it can easily be fixed by overloading the return value from smsc47b397_find with both address and error return code (the address is an unsigned short and thus never negative). This also reduces module size by a few bytes (64 bytes for x86_64). Cc: Mark M. Hoffman <mhoffman@lightlink.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Robert Coulson <robert.coulson@ericsson.com> Acked-by: Jean Delvare <khali@linux-fr.org>
2012-04-09tile/CPU hotplug: Add missing call to notify_cpu_starting()Srivatsa S. Bhat
The scheduler depends on receiving the CPU_STARTING notification, without which we end up into a lot of trouble. So add the missing call to notify_cpu_starting() in the bringup code. Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2012-04-09um: several x86 hw-dependent crypto modules won't build on umlAl Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-04-09um: fix linker script generationAl Viro
while we can't just use -U$(SUBARCH), we still need to kill idiotic define (implicit -Di386=1), both for SUBARCH=i386 and SUBARCH=x86/CONFIG_64BIT=n builds. Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2012-04-09pch_uart: Add Kontron COMe-mTT10 uart clock quirkMichael Brunner
Add UART clock quirk for the Kontron COMe-mTT10 module. The board has previously been called nanoETXexpress-TT, therefore this is also checked. As suggested by Darren Hart the comparison in this patch version is placed after the FRI2 checks to ensure it will also work with possible upcoming changes to the FRI2 firmware. This patch follows the patchset submitted by Darren Hart at commit a46f5533ecfc7bbdd646d84fdab8656031a715c6. Signed-off-by: Michael Brunner <mibru@gmx.de> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09ARM: OMAP1: mux: add missing includeAaro Koskinen
Fix the following build breakage in v3.4-rc2 that happens with CONFIG_OMAP_MUX=y: arch/arm/mach-omap1/mux.c:89:1: error: 'FUNC_MUX_CTRL_9' undeclared here (not in a function) arch/arm/mach-omap1/mux.c:89:1: error: 'PULL_DWN_CTRL_2' undeclared here (not in a function) arch/arm/mach-omap1/mux.c:93:1: error: 'FUNC_MUX_CTRL_C' undeclared here (not in a function) Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> [tony@atomide.com: updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-04-09pch_uart: Fix MSI setting issueTomoya MORINAGA
The following patch (MSI setting) is not enough. commit e463595fd9c752fa4bf06b47df93ef9ade3c7cf0 Author: Alexander Stein <alexander.stein@systec-electronic.com> Date: Mon Jul 4 08:58:31 2011 +0200 pch_uart: Add MSI support Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> To enable MSI mode, PCI bus-mastering must be enabled. This patch enables the setting. cc: Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09serial/8250_pci: add a "force background timer" flag and use it for the "kt" ↵Dan Williams
serial port Workaround dropped notifications in the iir register. Register reads coincident with new interrupt notifications sometimes result in this device clearing the interrupt event without reporting it in the read data. The serial core already has a heuristic for determining when a device has an untrustworthy iir register. In this case when we apriori know that the iir is faulty use a flag (UPF_BUG_THRE) to bypass the test and force usage of the background timer. [stable: 3.3.x] Acked-by: Alan Cox <alan@linux.intel.com> Cc: stable <stable@vger.kernel.org> Reported-by: Nhan H Mai <nhan.h.mai@intel.com> Reported-by: Sudhakar Mamillapalli <sudhakar@fb.com> Tested-by: Nhan H Mai <nhan.h.mai@intel.com> Tested-by: Sudhakar Mamillapalli <sudhakar@fb.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09Revert "serial/8250_pci: setup-quirk workaround for the kt serial controller"Dan Williams
This reverts commit 448ac154c957c4580531fa0c8f2045816fe2f0e7. The semantic of UPF_IIR_ONCE is only guaranteed to workaround the race condition in the kt serial's iir register if the only source of interrupts is THRE (fifo-empty) events. An modem status event at the wrong time can again cause an iir read to drop the 'empty' status leading to a hang. So, revert this in preparation for using the existing "I don't trust my iir register" workaround in the 8250 core (UART_BUG_THRE). [stable: 3.3.x] Cc: stable <stable@vger.kernel.org> Acked-by: Alan Cox <alan@linux.intel.com> Cc: Sudhakar Mamillapalli <sudhakar@fb.com> Reported-by: Nhan H Mai <nhan.h.mai@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09Revert "serial/8250_pci: init-quirk msi support for kt serial controller"Dan Williams
This reverts commit e86ff4a63c9fdd875ba8492577cd1ad2252f525c. This tried to enforce the semantics of one interrupt per iir read of the THRE (transmit-hold empty) status, but events from other sources (particularly modem status) defeat this guarantee. This change also broke 8250_pci suspend/resume support as pciserial_resume_ports() re-runs .init() quirks, but does not run .exit() quirks in pciserial_suspend_ports() leading to reports like: sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:16.3/msi_irqs' ...and a subsequent crash. The mismatch of init/exit at suspend/resume seems like a bug in its own right. [stable: 3.3.x] Cc: stable <stable@vger.kernel.org> Acked-by: Alan Cox <alan@linux.intel.com> Cc: Sudhakar Mamillapalli <sudhakar@fb.com> Reported-by: Nhan H Mai <nhan.h.mai@intel.com> Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09tty/serial/omap: console can only be built-inArnd Bergmann
When the omap serial driver is built as a module, we must not allow the console driver to be selected, because consoles can not be loadable modules. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Acked-by: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09serial: samsung: fix omission initialize ulcon in reset port fn()Kukjin Kim
Fix omission initialize ulcon in s3c24xx_serial_resetport(), reset port function in drivers/tty/serial/samsung.c. It has been happened from commit 0dfb3b41("serial: samsung: merge all SoC specific port reset functions") Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Cc: stable <stable@vger.kernel.org> [3.3] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09printk(): add KERN_CONT where needed in hpet and vt codeKay Sievers
A prototype for kmsg records instead of a byte-stream buffer revealed a couple of missing printk(KERN_CONT ...) uses. Subsequent calls produce one record per printk() call, while all should have ended up in a single record. Instead of: ACPI: (supports S0 S5) ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11) hpet0: at MMIO 0xfed00000, IRQs 2 , 8 , 0 It prints: ACPI: (supports S0 S5 ) ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11 ) hpet0: at MMIO 0xfed00000, IRQs 2 , 8 , 0 Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Len Brown <lenb@kernel.org> Signed-off-by: Kay Sievers <kay@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09tty/serial: atmel_serial: fix RS485 half-duplex problemSiftar, Gabe
On our custom board, we are using RS485 in half-duplex mode on an AT91SAM9G45. SER_RS485_RX_DURING_TX is not set as we do not want to receive the data we transmit (our transceiver will receive transmitted data). Although the current driver attempts to disable and enable the receiver at the appropriate points, incoming data is still loaded into the receive register causing our code to receive the very last byte that was sent once the receiver is enabled. I ran this by Atmel support and they wrote: "The issue comes from the fact that you disable the PDC/DMA Reception and not the USART Reception channel. In your case, the[n] you will still receive data into the USART_RHR register, and maybe you [h]ave the overrun flag set. So please disable the USART reception channel." The following patch should force the driver to enable/disable the receiver via RXEN/RXDIS fields of the USART control register. It fixed the issue I was having. Signed-off-by: Gabe Siftar <gabe.siftar@getingeusa.com> [nicolas.ferre@atmel.com: slightly modify commit message] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09tty: serial: altera_uart: Check for NULL platform_data in probe.Yuriy Kozlov
Follow altera_jtag_uart. This fixes a crash if there is a mistake in the DTS. Signed-off-by: Yuriy Kozlov <ykozlov@ptcusa.com> Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09isdn/gigaset: use gig_dbg() for debugging outputTilman Schmidt
The "TTY buffer in tty_port" patchset introduced an opencoded debug message in the Gigaset tty device if_close() function. Change it to use the gig_dbg() macro like everywhere else in the driver. Signed-off-by: Tilman Schmidt <tilman@imap.cc> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09omap-serial: Fix the error handling in the omap_serial probeShubhrajyoti D
The patch does the following - The pm_runtime_disable is called in the remove not in the error case of probe.The patch calls the pm_runtime_disable in the error case. - Calls pm_runtime_put in the error case. - The up is not freed in the error path. Fix the memory leak by using devm_* so that the memory need not be freed in the driver. - Also the iounmap is not called fix the same by calling using devm_ioremap. - Make the name of the error tags more meaningful. Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: Govindraj.R <govindraj.raja@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-09video:uvesafb: Fix oops that uvesafb try to execute NX-protected pageWang YanQing
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> Cc: stable@vger.kernel.org
2012-04-09drm/i915: VCS is not the last ringBen Widawsky
I made a mistake, please forgive me. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48254 Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: Add a dual link lvds quirk for MacBook Pro 8,2Daniel Vetter
When booting with EFI, Apple botched this one up. v2: Switch the quirk dmesg output to DRM_INFO. v3: Actually git add the new things ... Tested-by: Austin Lund <austin.lund@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42842 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: make quirks more verboseDaniel Vetter
And add informational dmesg output where it does not yet exist. In case a quirk matches too much, this information is crucial for debugging such a bug report. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: dump the DMA fetch addr register on pre-gen6Daniel Vetter
It exists way back to gen2, bug got moved around on gen4 a bit. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915/sdvo: Include YRPB as an additional TV output typeChris Wilson
Reported-and-tested-by: Bo Wang < bo.b.wang@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: disallow gem init ioctl on ilkDaniel Vetter
Ums is already disabled, but on ilk we can additionally disable gem initialization when using user mode setting. Upstream never support ilk without kernel modesetting and not even the RHEL ilk ums backport needs gem - that driver is based on xf86-video-intel version 2.2, which is pre-gem. Reviewed-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: refuse to load on gen6+ without kmsDaniel Vetter
Spurred by an irc discussion, let's start to clear up which parts of our kms + ums/gem + ums/dri1 + vbios/dri1 kernel driver pieces userspace in the wild actually uses. The idea is that we introduce checks at entry-points (module load time, ioctls, ...) first and then reap any obviously dead code in a second step. As a first step refuse to load without kms on chips where userspace never supported ums. Now upstream hasn't supported ums on ilk, ever. But RHEL had the great idea to backport the kms support to their ums driver. Cc: Dave Airlie <airlied@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: extract gt interrupt handlerDaniel Vetter
vlv, ivb and snb all share the gen6+ gt irq handling. 3 copies of the same stuff is a bit much, so extract it into a little helper. Now ilk has a different gt irq handling than snb, but shares the same irq handler (due to the similar display block). So also extract the ilk gt irq handling to clearly separate these two things. Nice side effect of this is that we can complete Ben Widawsky's gen6+ irq bit #define cleanup and call the render irq also with the GEN6 alias. Beforehand that code was shared with ilk, and neither option really made much sense. As a bonus this enables the error interrupt handling lifted from the vlv code on snb and ivb, too. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Antagonized-by: Ben Widawsky <ben@bwidawsk.net> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: use render gen to switch ring irq functionsDaniel Vetter
Top-level interrupt bits are usually found in the display block. It therefore makes sense to use HAS_PCH_SPLIT in i915_irq.c But the irq stuff in intel_ring.c only concerns itself with render core/gt-level interrupt sources. It therefore makes more sense to switch based on gpu gen. Kills a vlv special case. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: rip out old HWSTAM missed irq WA for vlvDaniel Vetter
This got copy-pasted from an older version. The newer kinds of workarounds don't need this anymore. Shame on me for not noticing when picking up the vlv irq patch. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: open code gen6+ ring irqsBen Widawsky
We can now open-code the get/put irq functions as they were just abstracting single register definitions. It would be nice to merge this in with the IRQ handling code... but that is too much work for me at present. In addition I could probably collapse this in to a lot of the Ironlake stuff, but I don't think it's worth the potential regressions. This patch itself should not effect functionality. CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: ring irq cleanupsBen Widawsky
- gen6 put/get only need one argument rflags and gflags are always the same (see above explanation) - remove a couple redundantly defined IRQs - reordered some lines to make things go in descending order Every ring has its own interrupts, enables, masks, and status bits that are fed into the main interrupt enable/mask/status registers. At one point in time it seemed like a good idea to make our functions support the notion that each interrupt may have a different bit position in the corresponding register (blitter parser error may be bit n in IMR, but bit m in blitter IMR). It turned out though that the HW designers did us a solid on Gen6+ and this unfortunate situation has been avoided. This allows our interrupt code to be cleaned up a bit. I jammed this into one commit because there should be no functional change with this commit, and staging it into multiple commits was unnecessarily artificial IMO. CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: - fixed up merged conflict with vlv changes. - added GEN6 to GT blitter bit, we only use it on gen6+. - added a comment to both ring irq bits and GT irq bits that on gen6+ these alias. - added comment that GT_BSD_USER_INTERRUPT is ilk-only. - I've got confused a bit that we still use GT_USER_INTERRUPT on ivb for the render ring - but this goes back to ilk where we have only gt interrupt bits and so we be equally confusing if changed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add SFUSE_STRAP registers for digital port detectionEugeni Dodonov
DDIA is detected via the DDI_BUF_CTL registers bit 0, but for DDIB, DDIC and DDID we need to consult SFUSE_STRAP values. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add WM_LINETIME registersEugeni Dodonov
Watermark line time registers for display low power watermark. v2: improve bit names as suggested by Chris Wilson Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add WRPLL clocksEugeni Dodonov
The WR PLL can drive the DDI ports at fixed frequencies for HDMI, DVI, DP and FDI. Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add LCPLL control registersEugeni Dodonov
Those are used to control the display core clock. v2: change the enable bit setting, spotted by Rodrigo Vivi. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add SSC offsets for SBI accessEugeni Dodonov
Different registers are identified by their target id and offset. To simplify their programming, they are called as <RegisterName><TargetId>. For example, SSCCTL register accessed through SBI at target id 6 and offset 0c is called SBI_SSCCTL6. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add port clock selection support for HSWEugeni Dodonov
Multiple clocks can drive different outputs. v2: use the port enums to access individual ports v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add S PLL controlEugeni Dodonov
This PLL control can drive DDI ports at desired frequencies for DisplayPort and FDI connections. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add PIXCLK_GATE registerEugeni Dodonov
Pixel clock gating control for Lynx point. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-09drm/i915: add SBI registersEugeni Dodonov
Those are responsible for the Sideband Interface programming. v2: rename SBI bits to better reflect their meaning Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit (git 2.34.1) at 2025-09-15 13:52:40 +0000