- 17 7月, 2015 13 次提交
-
-
由 Michel Dänzer 提交于
Something (ATOM BIOS?) seems to be clobbering the LB_INTERRUPT_MASK register while the CRTC is off, which caused e.g. glxgears or gnome-shell to hang after a modeset. Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
-
由 Alex Deucher 提交于
This has been a source of confusion. Make it debug only. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
So the selected forced level shows up properly in sysfs. Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This is necessary to properly reset the min/max limits before clamping them otherwise we may get improper clamping depending on what what was the last forced level. Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Always respect the harvest configuration as is. Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
v2: squash in later fix Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
If we run into a part with a harvest configuration where the entire IP block is unusable, just disable the IP block. v2: fix logic as noted by Christian Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Christian König 提交于
Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
-
由 Christian König 提交于
Just to make sure userspace don't send nonsense to the kernel. Signed-off-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Reviewed-by: NJammy Zhou <Jammy.Zhou@amd.com>
-
由 Christian König 提交于
Port of amdgpu patch 9298e52f. Signed-off-by: NChristian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Michel Dänzer 提交于
This can be the case when the GPU is powered off, e.g. via vgaswitcheroo or runpm. When the GPU is powered up again, radeon_gart_table_vram_pin flushes the TLB after setting rdev->gart.ptr to non-NULL. Fixes panic on powering off R7xx GPUs. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61529Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 15 7月, 2015 24 次提交
-
-
由 Tvrtko Ursulin 提交于
Frame buffer modifiers extensions provided in; commit e3eb3250 Author: Rob Clark <robdclark@gmail.com> Date: Thu Feb 5 14:41:52 2015 +0000 drm: add support for tiled/compressed/etc modifier in addfb2 Missed the structure packing/alignment problem where 64-bit members were added after the odd number of 32-bit ones. This makes the compiler produce structures of different sizes under 32- and 64-bit x86 targets and makes the ioctl need explicit compat handling. v2: Removed the typedef. (Daniel Vetter) Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: stable@vger.kernel.org [danvet: Squash in compile fix from Mika.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Johannes Thumshirn 提交于
Destroy ocrdma_dev_id IDR on module exit, reclaiming the allocated memory. This was detected by the following semantic patch (written by Luis Rodriguez <mcgrof@suse.com>) <SmPL> @ defines_module_init @ declarer name module_init, module_exit; declarer name DEFINE_IDR; identifier init; @@ module_init(init); @ defines_module_exit @ identifier exit; @@ module_exit(exit); @ declares_idr depends on defines_module_init && defines_module_exit @ identifier idr; @@ DEFINE_IDR(idr); @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... idr_destroy(&idr); ... } @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... +idr_destroy(&idr); } </SmPL> Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Johannes Thumshirn 提交于
Destroy multcast_idr on module exit, reclaiming the allocated memory. This was detected by the following semantic patch (written by Luis Rodriguez <mcgrof@suse.com>) <SmPL> @ defines_module_init @ declarer name module_init, module_exit; declarer name DEFINE_IDR; identifier init; @@ module_init(init); @ defines_module_exit @ identifier exit; @@ module_exit(exit); @ declares_idr depends on defines_module_init && defines_module_exit @ identifier idr; @@ DEFINE_IDR(idr); @ on_exit_calls_destroy depends on declares_idr && defines_module_exit @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... idr_destroy(&idr); ... } @ missing_module_idr_destroy depends on declares_idr && defines_module_exit && !on_exit_calls_destroy @ identifier declares_idr.idr, defines_module_exit.exit; @@ exit(void) { ... +idr_destroy(&idr); } </SmPL> Signed-off-by: NJohannes Thumshirn <jthumshirn@suse.de> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Doug Ledford 提交于
There is little chance our memory allocation will fail, so we can combine initializing the work structs with allocating them instead of looping through all of them once to allocate and again to initialize. Then when we need to actually find out if our device is up or in the process of going down, have all of our work structs batched up, take the spin_lock once and only once, and do all of the batch under the one spin_lock invocation instead of incurring all of the locked memory cycles we would otherwise incur to take/release the spin_lock over and over again. Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Doug Ledford 提交于
We create a number of work structs to be queued up to a workqueue, and on completion of the workqueue handler, the workqueue handler frees the allocated memory. If, however, we don't queue the work struct because the device is going down, then we need to free the memory ourselves. Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Maninder Singh 提交于
On failure, we loop through all possible pointers and test them before calling kfree. But really, why even attempt to free items we didn't allocate when we can easily loop through exactly and only the devices for which the original memory allocation succeeded and free just those. Signed-off-by: NManinder Singh <maninder1.s@samsung.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Or Gerlitz 提交于
For IB links, reading HCA flow counters through iboe_process_mad() should be used when mlx4_ib_process_mad() is invoked only for VFs PMA queries and exactly nothing else. Fixes: 7193a141 ('IB/mlx4: Set VF to read from QP counters') Reported-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Vaishali Thakkar 提交于
In little endian cases, the macros be16_to_cpu and cpu_to_be64 unfolds to __swab{16,64} which provides special case for constants. In big endian cases, __constant_be16_to_cpu and be16_to_cpu expand directly to the same expression. The same applies for __constant_cpu_to_be64 and cpu_to_be64. So, replace __constant_be16_to_cpu with be16_to_cpu and __constant_cpu_to_be64 with cpu_to_be64, with the goal of getting rid of the definition of __constant_be16_to_cpu and __constant_cpu_to_be64 completely. Signed-off-by: NVaishali Thakkar <vthakkar1994@gmail.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Erez Shitrit 提交于
When switching between modes (datagram / connected) change the MTU accordingly. datagram mode up to 4K, connected mode up to (64K - 0x10). Signed-off-by: NELi Cohen <eli@mellanox.com> Signed-off-by: NErez Shitrit <erezsh@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Yuval Shaia 提交于
By default, IPoIB-CM driver uses 64k MTU. Larger MTU gives better performance. This MTU plus overhead puts the memory allocation for IP based packets at 32 4k pages (order 5), which have to be contiguous. When the system memory under pressure, it was observed that allocating 128k contiguous physical memory is difficult and causes serious errors (such as system becomes unusable). This enhancement resolve the issue by removing the physically contiguous memory requirement using Scatter/Gather feature that exists in Linux stack. With this fix Scatter-Gather will be supported also in connected mode. This change reverts some of the change made in commit e112373f ("IPoIB/cm: Reduce connected mode TX object size"). The ability to use SG in IPoIB CM is possible because the coupling between NETIF_F_SG and NETIF_F_CSUM was removed in commit ec5f0615 ("net: Kill link between CSUM and SG features.") Signed-off-by: NYuval Shaia <yuval.shaia@oracle.com> Acked-by: NChristian Marie <christian@ponies.io> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Carol L Soto 提交于
ib_ucm_release_dev clears the wrong bit if devnum is greater than IB_UCM_MAX_DEVICES. Signed-off-by: NCarol L Soto <clsoto@linux.vnet.ibm.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Haggai Eran 提交于
__ipoib_ib_dev_flush calls itself recursively on child devices, and lockdep complains about locking vlan_rwsem twice (see below). Use down_read_nested instead of down_read to prevent the warning. ============================================= [ INFO: possible recursive locking detected ] 4.1.0-rc4+ #36 Tainted: G O --------------------------------------------- kworker/u20:2/261 is trying to acquire lock: (&priv->vlan_rwsem){.+.+..}, at: [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib] but task is already holding lock: (&priv->vlan_rwsem){.+.+..}, at: [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&priv->vlan_rwsem); lock(&priv->vlan_rwsem); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kworker/u20:2/261: #0: ("%s""ipoib_flush"){.+.+..}, at: [<ffffffff810827cc>] process_one_work+0x15c/0x760 #1: ((&priv->flush_heavy)){+.+...}, at: [<ffffffff810827cc>] process_one_work+0x15c/0x760 #2: (&priv->vlan_rwsem){.+.+..}, at: [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib] stack backtrace: CPU: 3 PID: 261 Comm: kworker/u20:2 Tainted: G O 4.1.0-rc4+ #36 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 Workqueue: ipoib_flush ipoib_ib_dev_flush_heavy [ib_ipoib] ffff8801c6c54790 ffff8801c9927af8 ffffffff81665238 0000000000000001 ffffffff825b5b30 ffff8801c9927bd8 ffffffff810bba51 ffff880100000000 ffffffff00000001 ffff880100000001 ffff8801c6c55428 ffff8801c6c54790 Call Trace: [<ffffffff81665238>] dump_stack+0x4f/0x6f [<ffffffff810bba51>] __lock_acquire+0x741/0x1820 [<ffffffff810bcbf8>] lock_acquire+0xc8/0x240 [<ffffffffa0791e2a>] ? __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib] [<ffffffff81669d2c>] down_read+0x4c/0x70 [<ffffffffa0791e2a>] ? __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib] [<ffffffffa0791e2a>] __ipoib_ib_dev_flush+0x3a/0x2b0 [ib_ipoib] [<ffffffffa0791e4a>] __ipoib_ib_dev_flush+0x5a/0x2b0 [ib_ipoib] [<ffffffffa07920ba>] ipoib_ib_dev_flush_heavy+0x1a/0x20 [ib_ipoib] [<ffffffff81082871>] process_one_work+0x201/0x760 [<ffffffff810827cc>] ? process_one_work+0x15c/0x760 [<ffffffff81082ef0>] worker_thread+0x120/0x4d0 [<ffffffff81082dd0>] ? process_one_work+0x760/0x760 [<ffffffff81082dd0>] ? process_one_work+0x760/0x760 [<ffffffff81088b7e>] kthread+0xfe/0x120 [<ffffffff81088a80>] ? __init_kthread_worker+0x70/0x70 [<ffffffff8166c6e2>] ret_from_fork+0x42/0x70 [<ffffffff81088a80>] ? __init_kthread_worker+0x70/0x70 Signed-off-by: NHaggai Eran <haggaie@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Haggai Eran 提交于
The ucma_lock_files() locks the mut mutex on two files, e.g. for migrating an ID. Use mutex_lock_nested() to prevent the warning below. ============================================= [ INFO: possible recursive locking detected ] 4.1.0-rc6-hmm+ #40 Tainted: G O --------------------------------------------- pingpong_rpc_se/10260 is trying to acquire lock: (&file->mut){+.+.+.}, at: [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm] but task is already holding lock: (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&file->mut); lock(&file->mut); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by pingpong_rpc_se/10260: #0: (&file->mut){+.+.+.}, at: [<ffffffffa047ac4b>] ucma_migrate_id+0xbb/0x248 [rdma_ucm] stack backtrace: CPU: 0 PID: 10260 Comm: pingpong_rpc_se Tainted: G O 4.1.0-rc6-hmm+ #40 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 ffff8801f85b63d0 ffff880195677b58 ffffffff81668f49 0000000000000001 ffffffff825cbbe0 ffff880195677c38 ffffffff810bb991 ffff880100000000 ffff880100000000 ffff880100000001 ffff8801f85b7010 ffffffff8121bee9 Call Trace: [<ffffffff81668f49>] dump_stack+0x4f/0x6e [<ffffffff810bb991>] __lock_acquire+0x741/0x1820 [<ffffffff8121bee9>] ? dput+0x29/0x320 [<ffffffff810bcb38>] lock_acquire+0xc8/0x240 [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm] [<ffffffff8166b901>] ? mutex_lock_nested+0x291/0x3e0 [<ffffffff8166b6d5>] mutex_lock_nested+0x65/0x3e0 [<ffffffffa047ac55>] ? ucma_migrate_id+0xc5/0x248 [rdma_ucm] [<ffffffff810baeed>] ? trace_hardirqs_on+0xd/0x10 [<ffffffff8166b66e>] ? mutex_unlock+0xe/0x10 [<ffffffffa047ac55>] ucma_migrate_id+0xc5/0x248 [rdma_ucm] [<ffffffffa0478474>] ucma_write+0xa4/0xb0 [rdma_ucm] [<ffffffff81200674>] __vfs_write+0x34/0x100 [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110 [<ffffffff810ec055>] ? current_kernel_time+0xc5/0xe0 [<ffffffff812aa4d3>] ? security_file_permission+0x23/0x90 [<ffffffff8120088d>] ? rw_verify_area+0x5d/0xe0 [<ffffffff812009bb>] vfs_write+0xab/0x120 [<ffffffff81201519>] SyS_write+0x59/0xd0 [<ffffffff8112427c>] ? __audit_syscall_entry+0xac/0x110 [<ffffffff8166ffee>] system_call_fastpath+0x12/0x76 Signed-off-by: NHaggai Eran <haggaie@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Tatyana Nikolova 提交于
Fix for incorrect recording of the MAC address Signed-off-by: NTatyana Nikolova <Tatyana.E.Nikolova@intel.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Tatyana Nikolova 提交于
Neighbor resolution doesn't work without this fix Signed-off-by: NTatyana Nikolova <Tatyana.E.Nikolova@intel.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Tatyana Nikolova 提交于
Fixes to allow clients to make remove mapping requests, after they have provided the user space service with the mapping information, they are using when the service is restarted. 1) Adding IWPM_REG_VALID, IWPM_REG_INCOMPL and IWPM_REG_UNDEF registration types for the port mapper clients and functions to set/check the registration type. 2) If the port mapper user space service is not available to register the client, then its registration stays IWPM_REG_UNDEF and the registration isn't checked until the service becomes available (no mappings are possible, if the user space service isn't running). 3) After the service is restarted, the user space port mapper pid is set to valid and the client registration is set to IWPM_REG_INCOMPL to allow the client to make remove mapping requests. Signed-off-by: NTatyana Nikolova <Tatyana.E.Nikolova@intel.com> Reviewed-by: NSteve Wise <swise@opengridcomputing.com> Tested-by: NSteve Wise <swise@opengridcomputing.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Amir Vadai 提交于
Error values of ib_query_port() and ib_query_device() weren't propagated correctly. Because of that, ipoib_add_port() could return NULL value, which escaped the IS_ERR() check in ipoib_add_one() and we crashed. Signed-off-by: NAmir Vadai <amirv@mellanox.com> Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Reviewed-by: NIra Weiny <ira.weiny@intel.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Matan Barak 提交于
mlx4 VFs can provide CQE raw time-stamping services, but they don't have the hca core clock mapped to their PCI bars. As such, we should not attempt to query and report the clock offset to user space for VFs. Doing so causes query_device over VFs to fail with -ENOSUPP. Fixes: 4b664c43 ('IB/mlx4: Add support for CQ time-stamping') Signed-off-by: NMatan Barak <matanb@mellanox.com> Signed-off-by: NOr Gerlitz <ogerlitz@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Erez Shitrit 提交于
Whenever ib_cm gets remove_one call, like when there is a hot-unplug event, the driver should mark itself as going_down and confirm that no new works are going to be queued for that device. so, the order of the actions are: 1. mark the going_down bit. 2. flush the wq. 3. [make sure no new works for that device.] 4. unregister mad agent. otherwise, works that are already queued can be scheduled after the mad agent was freed. Signed-off-by: NErez Shitrit <erezsh@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Sagi Grimberg 提交于
We might return res which is not initialized. Also reduce code duplication by exporting srp_parse_tmo so srp_tmo_set can reuse it. Detected by Coverity. Signed-off-by: NSagi Grimberg <sagig@mellanox.com> Signed-off-by: NJenny Falkovich <jennyf@mellanox.com> Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Vaishali Thakkar 提交于
In little endian cases, the macro cpu_to_be{16,32,64} unfolds to __swab{16,32,64} which provides special case for constants. In big endian cases, __constant_cpu_to_be{16,32,64} and cpu_to_be{16,32,64} expand directly to the same expression. So, replace __constant_cpu_to_be{16,32,64} with cpu_to_be{16,32,64} with the goal of getting rid of the definitions of __constant_cpu_to_be{16,32,64} completely. The Coccinelle semantic patch that performs this transformation is as follows: @@expression x;@@ ( - __constant_cpu_to_be16(x) + cpu_to_be16(x) | - __constant_cpu_to_be32(x) + cpu_to_be32(x) | - __constant_cpu_to_be64(x) + cpu_to_be64(x) ) Signed-off-by: NVaishali Thakkar <vthakkar1994@gmail.com> Reviewed-by: NBart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Ira Weiny 提交于
We recently added BUG_ON's which were inappropriate for a condition which should never happen. Change these to be WARN_ON_ONCE as a debugging aid. Fixes: 4cd7c947 ('IB/mad: Add support for additional MAD info to/from drivers') Signed-off-by: NIra Weiny <ira.weiny@intel.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Ira Weiny 提交于
The define OPA_LID_PERMISSIVE is big endian and was compared to the cpu endian variable opa_drslid. Problem caught by 0-day build infrastructure. Fixes: 8e4349d1 (IB/mad: Add final OPA MAD processing) Signed-off-by: NIra Weiny <ira.weiny@intel.com> Reviewed-by: NMike Marciniszyn <mike.marciniszyn@intel.com> Reviewed-by: NJohn, Jubin <jubin.john@intel.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
由 Hal Rosenstock 提交于
Persuant to Liran's comments on node_type on linux-rdma mailing list: In an effort to reform the RDMA core and ULPs to minimize use of node_type in struct ib_device, an additional bit is added to struct ib_device for is_switch (IB switch). This is needed to be initialized by any IB switch device driver. This is a NEW requirement on such device drivers which are all "out of tree". In addition, an ib_switch helper was added to ib_verbs.h based on the is_switch device bit rather than node_type (although those should be consistent). The RDMA core (MAD, SMI, agent, sa_query, multicast, sysfs) as well as (IPoIB and SRP) ULPs are updated where appropriate to use this new helper. In some cases, the helper is now used under the covers of using rdma_[start end]_port rather than the open coding previously used. Reviewed-by: NSean Hefty <sean.hefty@intel.com> Reviewed-By: NJason Gunthorpe <jgunthorpe@obsidianresearch.com> Reviewed-by: NIra Weiny <ira.weiny@intel.com> Tested-by: NIra Weiny <ira.weiny@intel.com> Signed-off-by: NHal Rosenstock <hal@mellanox.com> Signed-off-by: NDoug Ledford <dledford@redhat.com>
-
- 14 7月, 2015 3 次提交
-
-
由 Maarten Lankhorst 提交于
When resuming with dpms off, the following warn can happen: [ 118.334082] ------------[ cut here ]------------ [ 118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]() [ 118.334106] WARN_ON(!crtc->state->enable) [ 118.334137] Modules linked in: i915 [ 118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148 [ 118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 [ 118.334144] Workqueue: events_unbound async_run_entry_fn [ 118.334147] ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001 [ 118.334149] ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8 [ 118.334151] ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668 [ 118.334151] Call Trace: [ 118.334155] [<ffffffff817aa62a>] dump_stack+0x4f/0x7b [ 118.334157] [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0 [ 118.334158] [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50 [ 118.334173] [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915] [ 118.334188] [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915] [ 118.334191] [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80 [ 118.334205] [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915] [ 118.334219] [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915] [ 118.334232] [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915] [ 118.334246] [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915] [ 118.334248] [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90 [ 118.334255] [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915] [ 118.334262] [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915] [ 118.334263] [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0 [ 118.334266] [<ffffffff81467550>] dpm_run_callback+0x70/0x420 [ 118.334267] [<ffffffff81467cbd>] device_resume+0x9d/0x1c0 [ 118.334269] [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60 [ 118.334270] [<ffffffff81467dfc>] async_resume+0x1c/0x50 [ 118.334271] [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0 [ 118.334273] [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0 [ 118.334275] [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0 [ 118.334276] [<ffffffff8109daf9>] worker_thread+0x49/0x450 [ 118.334278] [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0 [ 118.334280] [<ffffffff810a3cb9>] kthread+0xf9/0x110 [ 118.334282] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334284] [<ffffffff817b414f>] ret_from_fork+0x3f/0x70 [ 118.334286] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334287] ---[ end trace 01f2cf6371b82d7a ]--- This warn is harmless, and can be fixed by not calling intel_crtc_disable when the crtc is already disabled. Reported-and-Tested-by: NJörg Otte <jrg.otte@gmail.com> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
This reverts commit 19ee835c. It breaks existing old userspace which doesn't handle UNKNOWN swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably still is on some other platforms, but it still pretty clearly broke the testers machine. If we want this we need to extend the ioctl with new paramters that only new userspace looks at. Cc: Harald Arnesen <harald@skogtun.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: NHarald Arnesen <harald@skogtun.org> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Tvrtko Ursulin 提交于
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being forwarded, but the drm.h header suggests (and reality confirms) ones after (and including) DRM_COMMAND_END should be forwarded as well. We need this to correctly forward the compat ioctl for the botched-up addfb2.1 extension. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: stable@vger.kernel.org # 4.1+ [danvet: Explain why this is suddenly needed and add cc: stable.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-