aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR?roel kluin2009-05-18
| | | | | | | | FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Acked-by: Ram Vepa <ram.vepa@neterion.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* mv643xx_eth: fix PPC DMA breakageGabriel Paubert2009-05-18
| | | | | | | | | | | | | After 2.6.29, PPC no more admits passing NULL to the dev parameter of the DMA API. The result is a BUG followed by solid lock-up when the mv643xx_eth driver brings an interface up. The following patch makes the driver work on my Pegasos again; it is mostly a search and replace of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping functions. Signed-off-by: Gabriel Paubert <paubert@iram.es> Acked-by: Lennert Buytenhek <buytenh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* bonding: fix link down handling in 802.3ad modeStephen Hemminger2009-05-18
| | | | | | | | | | | | | | One of the purposes of bonding is to allow for redundant links, and failover correctly if the cable is pulled. If all the members of a bonded device have no carrier present, the bonded device itself needs to report no carrier present to user space so management tools (like routing daemons) can respond. Bonding in 802.3ad mode does not work correctly for this because it incorrectly chooses a link that is down as a possible aggregator. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge branch 'linux-2.6.30.y' of ↵David S. Miller2009-05-18
|\ | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/inaky/wimax
| * wimax/i2400m: fix device crash: fix optimization in _roq_queue_update_wsInaky Perez-Gonzalez2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the i2400m receives data and the device indicates there has to be reordering, we keep an sliding window implementation to sort the packets before sending them to the network stack. One of the "operations" that the device indicates is "queue a packet and update the window start". When the queue is empty, this is equivalent to "deliver the packet and update the window start". That case was optimized in i2400m_roq_queue_update_ws() so that we would not pointlessly queue and dequeue a packet. However, when the optimization was active, it wasn't updating the window start. That caused the reorder management code to get confused later on with what seemed to be wrong reorder requests from the device. Thus the fix implemented is to do the right thing and update the window start in both cases, when the queue is empty (and the optimization is done) and when not. Signed-off-by: Inaky Perez-Gonzalez <inaky@linux.intel.com>
* | bridge: fix initial packet flood if !STPStephen Hemminger2009-05-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If bridge is configured with no STP and forwarding delay of 0 (which is typical for virtualization) then when link starts it will flood all packets for the first 20 seconds. This bug was introduced by a combination of earlier changes: * forwarding database uses hold time of zero to indicate user wants to always flood packets * optimzation of the case of forwarding delay of 0 avoids the initial timer tick The fix is to just skip all the topology change detection code if kernel STP is not being used. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | bridge: relay bridge multicast pkgs if !STPStephen Hemminger2009-05-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently the bridge catches all STP packets; even if STP is turned off. This prevents other systems (which do have STP turned on) from being able to detect loops in the network. With this patch, if STP is off, then any packet sent to the STP multicast group address is forwarded to all ports. Based on earlier patch by Joakim Tjernlund with changes to go through forwarding (not local chain), and optimization that only last octet needs to be checked. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | NET: Meth: Fix unsafe mix of irq and non-irq spinlocks.Ralf Baechle2009-05-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mixing of normal and irq spinlocks results in the following lockdep messages on bootup on IP32: [...] Sending DHCP requests . ====================================================== [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] 2.6.30-rc5-00164-g41baeef #30 ------------------------------------------------------ swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire: (&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c and this task is already holding: (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c which would create a new lock dependency: (_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...} but this new dependency connects a SOFTIRQ-irq-safe lock: (_xmit_ETHER#2){+.-...} ... which became SOFTIRQ-irq-safe at: [<ffffffff80061458>] __lock_acquire+0x784/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 to a SOFTIRQ-irq-unsafe lock: (&priv->meth_lock){+.+...} ... which became SOFTIRQ-irq-unsafe at: ... [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 other info that might help us debug this: 2 locks held by swapper/1: #0: (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0 #1: (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c the SOFTIRQ-irq-safe lock's dependencies: -> (_xmit_ETHER#2){+.-...} ops: 0 { HARDIRQ-ON-W at: [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 IN-SOFTIRQ-W at: [<ffffffff80061458>] __lock_acquire+0x784/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 INITIAL USE at: [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff802d2b88>] dev_watchdog+0x70/0x398 [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248 [<ffffffff8003da5c>] __do_softirq+0xec/0x208 [<ffffffff8003dbd8>] do_softirq+0x60/0xe4 [<ffffffff8003dda0>] irq_exit+0x54/0x9c [<ffffffff80004420>] ret_from_irq+0x0/0x4 [<ffffffff80004720>] r4k_wait+0x20/0x40 [<ffffffff80015418>] cpu_idle+0x30/0x60 [<ffffffff804cd934>] start_kernel+0x3ec/0x404 } ... key at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8 the SOFTIRQ-irq-unsafe lock's dependencies: -> (&priv->meth_lock){+.+...} ops: 0 { HARDIRQ-ON-W at: [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 SOFTIRQ-ON-W at: [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 INITIAL USE at: [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff800128d0>] _spin_lock+0x30/0x44 [<ffffffff80263f20>] meth_reset+0x118/0x2d8 [<ffffffff8026424c>] meth_open+0x28/0x140 [<ffffffff802c1ae8>] dev_open+0xe0/0x18c [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4 [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 } ... key at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8 stack backtrace: Call Trace: [<ffffffff8000ed0c>] dump_stack+0x8/0x34 [<ffffffff80060b74>] check_usage+0x470/0x4a0 [<ffffffff80060c34>] check_irq_usage+0x90/0x130 [<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14 [<ffffffff800627e0>] lock_acquire+0xf8/0x150 [<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84 [<ffffffff8026388c>] meth_tx+0x48/0x43c [<ffffffff802d3a38>] __qdisc_run+0x150/0x30c [<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0 [<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28 [<ffffffff80012e68>] do_one_initcall+0x58/0x170 [<ffffffff804cd190>] kernel_init+0x98/0x104 [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18 ..... timed out! IP-Config: Retrying forever (NFS root)... Sending DHCP requests ., OK [...] Fixed by converting all locks to irq locks. Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Tested-by: Andrew Randrianasulu <randrik_a@yahoo.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | mlx4_en: Fix not deleted napi structuresYevgeny Petrilin2009-05-17
| | | | | | | | | | | | | | | | | | Napi structures are being created each time we open a port, but when the port is closed the napi structure is only disabled but not removed. This bug caused hang while removing the driver. Signed-off-by: Yevgeny Petrilin <yevgenyp@mellanox.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
* | ipconfig: handle case of delayed DHCP serverChris Friesen2009-05-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a DHCP server is delayed, it's possible for the client to receive the DHCPOFFER after it has already sent out a new DHCPDISCOVER message from a second interface. The client then sends out a DHCPREQUEST from the second interface, but the server doesn't recognize the device and rejects the request. This patch simply tracks the current device being configured and throws away the OFFER if it is not intended for the current device. A more sophisticated approach would be to put the OFFER information into the struct ic_device rather than storing it globally. Signed-off-by: Chris Friesen <cfriesen@nortel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | netpoll: don't dereference NULL dev from npPavel Emelyanov2009-05-17
| | | | | | | | | | | | | | | | | | It looks like the dev in netpoll_poll can be NULL - at lease it's checked at the function beginning. Thus the dev->netde_ops dereference looks dangerous. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge branch 'master' of /home/davem/src/GIT/linux-2.6/David S. Miller2009-05-17
|\ \
| * | Fix caller information for warn_slowpath_nullLinus Torvalds2009-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ian Campbell noticed that since "Eliminate thousands of warnings with gcc 3.2 build" (commit 57adc4d2dbf968fdbe516359688094eef4d46581) all WARN_ON()'s currently appear to come from warn_slowpath_null(), eg: WARNING: at kernel/softirq.c:143 warn_slowpath_null+0x1c/0x20() because now that warn_slowpath_null() is in the call path, the __builtin_return_address(0) returns that, rather than the place that caused the warning. Fix this by splitting up the warn_slowpath_null/fmt cases differently, using a common helper function, and getting the return address in the right place. This also happens to avoid the unnecessary stack usage for the non-stdargs case, and just generally cleans things up. Make the function name printout use %pS while at it. Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Hugh Dickins <hugh@veritas.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | Merge branch 'for-linus' of ↵Linus Torvalds2009-05-16
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6: piix: The Sony TZ90 needs the cable type hardcoding icside: register second channel of version 6 PCB ide-tape: remove back-to-back REQUEST_SENSE detection
| | * | piix: The Sony TZ90 needs the cable type hardcodingAlan Cox2009-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Sony TZ90 needs the cable type hardcoding. See bug #12734 Signed-off-by: Alan Cox <alan@linux.intel.com> Reported-by: Jonathan E. Snow <jesnow@uh.edu> [bart: port it from ata_piix to piix and give reporter the proper credit] Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
| | * | icside: register second channel of version 6 PCBSergei Shtylyov2009-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The second IDE channel of version 6 PCB is not being registered anymore since the commit 48c3c1072651922ed153bcf0a33ea82cf20df390 (ide: add struct ide_host (take 3)). Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
| | * | ide-tape: remove back-to-back REQUEST_SENSE detectionTejun Heo2009-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Impact: fix an oops which always triggers ide_tape_issue_pc() assumed drive->pc isn't NULL on invocation when checking for back-to-back request sense issues but drive->pc can be NULL and even when it's not NULL, it's not safe to dereference it once the previous command is complete because pc could have been freed or was on stack. Kill back-to-back REQUEST_SENSE detection. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
| * | | Merge branch 'release' of ↵Linus Torvalds2009-05-16
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: ACPI: Idle C-states disabled by max_cstate should not disable the TSC ACPI: idle: fix init-time TSC check regression ACPI processor: reset the throttling state once it's invalid ACPI processor: introduce module parameter processor.ignore_tpc ACPI, i915: build fix ACPI: suspend: restore BM_RLD on resume ACPI: resume: re-enable SCI-enable workaround thermal: fix off-by-1 error in trip point trigger condition eeepc-laptop: unregister_rfkill_notifier on failure asus-laptop: fix input keycode eeepc-laptop: support for super hybrid engine (SHE) eeepc-laptop: Work around rfkill firmware bug eeepc-laptop: report brightness control events via the input layer eeepc-laptop: fix wlan rfkill state change during init ACPI: suspend: don't let device _PS3 failure prevent suspend ACPI: power: update error message ACPI: video: DMI workaround another broken Acer BIOS enabling display brightness ACPICA: use acpi.* modparam namespace ACPI video: dmi check for broken _BQC on Acer Aspire 5720
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | | \ \
| | *-----------------. \ \ Merge branches 'release', 'bugzilla-13032', 'bugzilla-13041+', ↵Len Brown2009-05-16
| | |\ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'bugzilla-13121', 'bugzilla-13165', 'bugzilla-13243', 'bugzilla-13259', 'resume-sci-en-regression', 'thermal-regression', 'tsc-regression' and 'asus-2.6.30' into release
| | | | | | | | | | | | * | | eeepc-laptop: unregister_rfkill_notifier on failureCorentin Chary2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If there is a failure during eeepc_hotk_add() we need to remove the acpi_notify_handler. Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | | | | | * | | asus-laptop: fix input keycodeCorentin Chary2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | KEY_STOP is now KEY_STOPCD It's the correct key to stop a media BTN_EXTRA is now KEY_SCREENLOCK: The laptop manual tells us that this key is for screenlock KEY_TV is now KEY_PROG1 So it can be reported to X server Ref: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/361505 Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | | | | | * | | eeepc-laptop: support for super hybrid engine (SHE)Grigori Goronzy2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The older eeepc-acpi driver allowed to control the SHE performance preset through a ACPI function for just this purpose. SHE underclocks and undervolts the FSB and undervolts the CPU (at preset 2, "powersave"), or slightly overclocks the CPU (at preset 0, "performance"). Preset 1 is the default setting with default clocks and voltage. The new eeepc-laptop driver doesn't support it anymore. The attached patch adds support for it to eeepc-laptop. It's very straight-forward and almost trivial. Signed-off-by: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | | | | | * | | eeepc-laptop: Work around rfkill firmware bugAlan Jenkins2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1) Buggy firmware can change the RFKILL state by itself. This is easily detected. The RFKILL API states that in such cases, we should call rfkill_force_state() to notify the core. I have reported the bug to Asus. I believe this is the right thing to do for robustness, even if this particular firmware bug is fixed. 2) The same bug causes the wireless toggle key to be reported as 0x11 instead of 0x10. 0x11 is otherwise unused, so it should be safe to add this as a new keycode. The bug is triggered by removing the laptop battery while hibernated. On resume, the wireless toggle key causes the firmware to toggle the wireless state itself. (Also, the key is reported as 0x11 when the current wireless state is OFF). This is very poor behaviour because the OS can't predict whether the firmware is controlling the RFKILL state. Without this workaround, the bug means users have to press the wireless toggle key twice to enable, due to the OS/firmware conflict. (Assuming rfkill-input or equivalent is being used). The workaround avoids this. I believe that acpid scripts which toggle the value of the sysfs state file when the toggle key is pressed will be rendered ineffective by the bug, regardless of this workaround. If they simply toggle the state, when the firmware has already toggled it, then you will never see a state change. Tested on "EEEPC 4G" only. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | | | | | * | | eeepc-laptop: report brightness control events via the input layerDarren Salt2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This maps the brightness control events to one of two keys, either KEY_BRIGHTNESSDOWN or KEY_BRIGHTNESSUP, as needed. Some mapping has to be done due to the fact that the BIOS reports them as <base value> + <current brightness index>; the selection is done according to the sign of the change in brightness (if this is 0, no keypress is reported). (Ref. http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2009-April/002001.html) Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | | | | | * | | eeepc-laptop: fix wlan rfkill state change during initAlan Jenkins2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an rfkill device is registered, the rfkill core will change its state to the system default. So we need to prepare for state changes *before* we register it. That means installing the eeepc-specific ACPI callback which handles the hotplug of the wireless network adaptor. This problem doesn't occur during normal operation. You have to 1) Boot with wireless enabled. eeepc-laptop should load automatically. 2) modprobe -r eeepc-laptop 3) modprobe eeepc-laptop On boot, the default rfkill state will be set to enabled. With the current core code, step 2) will disable the wireless. Therefore in step 3), the wireless will change state during registration, from disabled to enabled. But without this fix, the PCI device for the wireless adaptor will not appear. Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | | | | * | | | ACPI: Idle C-states disabled by max_cstate should not disable the TSCLen Brown2009-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Processor idle power states C2 and C3 stop the TSC on many machines. Linux recognizes this situation and marks the TSC as unstable: Marking TSC unstable due to TSC halts in idle But if those same machines are booted with "processor.max_cstate=1", then there is no need to validate C2 and C3, and no need to disable the TSC, which can be reliably used as a clocksource. Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de>
| | | | | | | | | | | * | | | ACPI: idle: fix init-time TSC check regressionLen Brown2009-05-16
| | | | | | | | | | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A previous 2.6.30 patch, a71e4917dc0ebbcb5a0ecb7ca3486643c1c9a6e2, (ACPI: idle: mark_tsc_unstable() at init-time, not run-time) erroneously disabled the TSC on systems that did not actually have valid deep C-states. Move the check after the deep-C-states are validated, via new helper, tsc_check_state(), hich replaces tsc_halts_in_c(). Signed-off-by: Len Brown <len.brown@intel.com> Acked-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Frans Pop <elendil@planet.nl>
| | | | | | | | | | * / / / thermal: fix off-by-1 error in trip point trigger conditionVladimir Zajac2009-05-14
| | | | | | | | | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a regression caused by commit b1569e99c795bf83b4ddf41c4f1c42761ab7f75e "ACPI: move thermal trip handling to generic thermal layer" which accidentally changed trip point trigger condition to temp > trip_temp This patch changes the trigger condition back to temp >= trip_temp Signed-off-by: Vladimir Zajac <eightgraph@gmail.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Acked-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | | * / / / ACPI: resume: re-enable SCI-enable workaroundLin Ming2009-05-15
| | | | | | | | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit. (The BIOS is supposed to update SCI_EN, not the OS) http://bugzilla.kernel.org/show_bug.cgi?id=13289 Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | * | | | ACPI processor: reset the throttling state once it's invalidZhang Rui2009-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the BIOS hands us an invalid throttling state, write a valid state. http://bugzilla.kernel.org/show_bug.cgi?id=13259 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: James Ettle <theholyettlz@googlemail.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | | * | | | ACPI processor: introduce module parameter processor.ignore_tpcZhang Rui2009-05-15
| | | | | | | | |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce module parameter processor.ignore_tpc. Some laptops are shipped with buggy _TPC, this module parameter is used to to disable the buggy support. http://bugzilla.kernel.org/show_bug.cgi?id=13259 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Tested-by: James Ettle <theholyettlz@googlemail.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | * | | | ACPI: suspend: don't let device _PS3 failure prevent suspendLen Brown2009-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 6328a57401dc5f5cf9931738eb7268fcd8058c49 "Enable PNPACPI _PSx Support, v3" added a call to acpi_bus_set_power(handle, ACPI_STATE_D3) to pnpacpi_disable_resource() before the existing call to evaluate _DIS on the device. This caused suspend to fail on the system in http://bugzilla.kernel.org/show_bug.cgi?id=13243 because the sanity check to verify we entered _PS3 failed on the serial port. As a work-around, that sanity check can be disabled system-wide with "acpi.power_nocheck=1" Or perhaps we should just shrug off the _PS3 failure and carry on with _DIS like we used to -- which is what this patch does. Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | | * | | | ACPI: power: update error messageLen Brown2009-05-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "Transitioning device [%s] to D%d" is not correct. We print this line when we attempted to transition the device, and it failed. So instead, print "Device [%s] failed to transition to D%d\n" This can happen under two conditions: 1. acpi_power_transition() fails when trying to handle the _ON/_OFF for associated power resource. 2. acpi_evaluate_object() on the explicit _PS0/_PS3 for that actual device could fail. this change clarifies, but doesn't fix http://bugzilla.kernel.org/show_bug.cgi?id=13243 Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | | * | | | | ACPI, i915: build fixLen Brown2009-05-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drivers/built-in.o: In function `intel_opregion_init': (.text+0x9d540): undefined reference to `acpi_video_register' http://bugzilla.kernel.org/show_bug.cgi?id=13165 Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | * | | | | | ACPI: video: DMI workaround another broken Acer BIOS enabling display brightnessLen Brown2009-05-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | http://bugzilla.kernel.org/show_bug.cgi?id=13121 Signed-off-by: Len Brown <len.brown@intel.com>
| | | | | * | | | | | ACPI video: dmi check for broken _BQC on Acer Aspire 5720Zhang Rui2009-04-24
| | | | | |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Acer Aspire 5720, _BQC always returns a value 9 smaller than the actual brightness level. Add dmi quirk for this laptop. http://bugzilla.kernel.org/show_bug.cgi?id=13121 Tested-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
| | | | * | / / / / ACPICA: use acpi.* modparam namespaceLen Brown2009-05-07
| | | | | |/ / / / | | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add acpi/acpica/*.c to the acpi.* modparam namespace so that any modparams we stick into ACPICA do not expose ACPICA filenames to users. There are currently only two modparams in ACPICA, just recently added for http://bugzilla.kernel.org/show_bug.cgi?id=13041 With this change, they become acpi.gts=1 acpi.bfs=1 rather than hwsleep.gts=1 hwsleep.bfs=1 Signed-off-by: Len Brown <len.brown@intel.com>
| | | * / | | | | ACPI: suspend: restore BM_RLD on resumeLen Brown2009-05-15
| | | |/ / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 2.6.29, 31878dd86b7df9a147f5e6cc6e07092b4308782b "ACPI: remove BM_RLD access from idle entry path" moved BM_RLD initialization to init-time from run time. But we discovered that some BIOS do not restore BM_RLD after suspend, causing device errors on C3 and C4 after resume. So now the kernel restores BM_RLD. http://bugzilla.kernel.org/show_bug.cgi?id=13032 Signed-off-by: Len Brown <len.brown@intel.com>
| * | | | | | | Linux 2.6.30-rc6v2.6.30-rc6Linus Torvalds2009-05-16
| | | | | | | |
| * | | | | | | Merge branch 'for-linus' of ↵Linus Torvalds2009-05-15
| |\ \ \ \ \ \ \ | | |/ / / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6: PCI MSI: Fix MSI-X with NIU cards PCI: Fix pci-e port driver slot_reset bad default return value
| | * | | | | | PCI MSI: Fix MSI-X with NIU cardsMatthew Wilcox2009-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The NIU device refuses to allow accesses to MSI-X registers before MSI-X is enabled. This patch fixes the problem by moving the read of the mask register to after MSI-X is enabled. Reported-by: David S. Miller <davem@davemloft.net> Tested-by: David S. Miller <davem@davemloft.net> Reviewed-by: David S. Miller <davem@davemloft.net> Signed-off-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| | * | | | | | PCI: Fix pci-e port driver slot_reset bad default return valueZhang, Yanmin2009-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an upstream port reports an AER error to root port, kernel starts error recovery procedures. The default return value of function pcie_portdrv_slot_reset is PCI_ERS_RESULT_NONE. If all port service drivers of the downstream port under the upstream port have no slot_reset method in pci_error_handlers, AER recovery would stop without resume. Below patch against 2.6.30-rc3 fixes it. Signed-off-by: Zhang Yanmin <yanmin.zhang@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
| * | | | | | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6Linus Torvalds2009-05-15
| |\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-2.6: Bluetooth: Don't trigger disconnect timeout for security mode 3 pairing Bluetooth: Don't use hci_acl_connect_cancel() for incoming connections Bluetooth: Fix wrong module refcount when connection setup fails Another case of me handling the fallout from Davem's unfortunate addiction to shuffleboard. Won't anybody think of the children? Join the anti-shuffleboard league today!
| * \ \ \ \ \ \ \ Merge branch 'drm-intel-next' of ↵Linus Torvalds2009-05-15
| |\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel * 'drm-intel-next' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: drm/i915: Add new GET_PIPE_FROM_CRTC_ID ioctl. drm/i915: Set HDMI hot plug interrupt enable for only the output in question. drm/i915: Include 965GME pci ID in IS_I965GM(dev) to match UMS. drm/i915: Use the GM45 VGA hotplug workaround on G45 as well. drm/i915: ignore LVDS on intel graphics systems that lie about having it drm/i915: sanity check IER at wait_request time drm/i915: workaround IGD i2c bus issue in kernel side (v2) drm/i915: Don't allow binding objects into the last page of the aperture. drm/i915: save/restore fence registers across suspend/resume drm/i915: x86 always has writeq. Add I915_READ64 for symmetry.
| | * | | | | | | | drm/i915: Add new GET_PIPE_FROM_CRTC_ID ioctl.Carl Worth2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows userlevel code to discover the pipe number corresponding to a given CRTC ID. This is necessary for doing pipe-specific operations such as waiting for vblank on a given CRTC. Failure to use the right pipe mapping can result in GPU hangs, or at least failure to actually sync to vblank. Signed-off-by: Carl Worth <cworth@cworth.org> [anholt: Style touchups from review] Signed-off-by: Eric Anholt <eric@anholt.net>
| | * | | | | | | | drm/i915: Set HDMI hot plug interrupt enable for only the output in question.Ma Ling2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We detect HDMI output connection status by writing to HOT Plug Interrupt Detect Enable bit in PORT_HOTPLUG_EN. The behavior will generate a specified interrupt, which is caught by audio driver, but during one detection driver set all Detect Enable bits of HDMIB, HDMIC HDMID, and generate wrong interrupt signals for current output, according to the signals audio driver misunderstand device status. The patch intends to handle corresponding output precisely. It fixed freedesktop.org bug #21371 Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
| | * | | | | | | | drm/i915: Include 965GME pci ID in IS_I965GM(dev) to match UMS.Ma Ling2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It fixed bug #21659 Signed-off-by: Ma Ling <ling.ma@intel.com> [anholt: hand-applied because git-am is too picky] Signed-off-by: Eric Anholt <eric@anholt.net>
| | * | | | | | | | drm/i915: Use the GM45 VGA hotplug workaround on G45 as well.Ma Ling2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although spec say CRT_HOTPLUG_ACTIVATION_PERIOD_64 is only useful for mobile platform, it is also required to detect vga on G4x desktops correctly. Tested on G45/G43/Q45 platforms with no regressions. It fixed freedesktop.org bug #21120 and part of bug #21210 Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Eric Anholt <eric@anholt.net>
| | * | | | | | | | drm/i915: ignore LVDS on intel graphics systems that lie about having itJarod Wilson2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a number of small form factor desktop systems with Intel mobile graphics chips that lie and say they have an LVDS. With kernel mode-setting, this becomes a problem, and makes native resolution boot go haywire -- for example, my Dell Studio Hybrid, hooked to a 1920x1080 display claims to have a 1024x768 LVDS, and the resulting graphical boot on the 1920x1080 display uses only the top left 1024x768, and auto-configured X will end up only 1024x768 as well. With this change, graphical boot and X both do 1920x1080 as expected. Note that we're simply embracing and extending the early bail-out code in place for the Mac Mini here. The xorg intel driver uses pci subsystem device and vendor id for matching, while we're using dmi lookups here. The MSI addition is courtesy of and tested by Bill Nottingham. Signed-off-by: Jarod Wilson <jarod@redhat.com> Tested-by: Bill Nottingham <notting@redhat.com> Signed-off-by: Eric Anholt <eric@anholt.net>
| | * | | | | | | | drm/i915: sanity check IER at wait_request timeJesse Barnes2009-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We might sleep here anyway so I hope an extra uncached read is ok to add. In #20896 we found that vbetool clobbers the IER. In KMS mode this is particularly bad since we don't set the interrupt regs late (in EnterVT), so we'd fail to get *any* interrupts at all after X started (since some distros have scripts that call vbetool at X startup apparently). So this patch checks IER at wait_request time, and re-enables interrupts if it's been clobbered. In a proper config this check should never be triggered. This is really a distro issue, but having a sanity check is nice, as long as it doesn't have a real performance hit. Tested-by: Mateusz Kaduk <mateusz.kaduk@gmail.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [anholt: Moved the check inside of the sleeping case to avoid perf cost] Signed-off-by: Eric Anholt <eric@anholt.net>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-15 22:01:12 -0500