aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/netlabel (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2014-12-09drm/mst: cached EDID for logical ports (v2)Dave Airlie3-4/+21
Logical ports are never going to have EDID changes, they are used for the internal ports on MST monitors. We cache the EDIDs from these to save time at MST probe. v2: drop misplace tile property line, meant for other patch. Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-09drm: add tile_group support. (v3)Dave Airlie3-0/+119
A tile group is an identifier shared by a single monitor, DisplayID topology has 8 bytes we can use for this, just use those for now until something else comes up in the future. We assign these to an idr and use the idr to tell userspace what connectors are in the same tile group. DisplayID v1.3 says the serial number must be unique for displays from the same manufacturer. v2: destroy idr (dvdhrm) add docbook (danvet) airlied:- not sure how to make docbook add fns to tile group section. v3: fix missing unlock. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-09drm/displayid: add displayid defines and edid extension (v2)Dave Airlie2-0/+78
These are just taken from the DisplayID v1.3 spec, and the DDC spec. v2: use __packed (Jani) Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-09drm/dp-mst: Remove branches before dropping the referenceDaniel Vetter1-1/+4
When we unplug a dp mst branch we unreference the entire tree from the root towards the leaves. Which is ok, since that's the way the pointers and so also the refcounts go. But when we drop the reference we must make sure that we remove the branches/ports from the lists/pointers before dropping the reference. Otherwise the get_validated functions will still return it instead of returning NULL (which indicates a potentially on-going unplug). The mst branch destroy gets this right for ports: First it deletes the port from the ports list, then it unrefs. But the ports destroy function gets it wrong: First it unrefs, then it drops the ref. Which means a zombie mst branch can still be validate with get_validated_mstb_ref when it shouldn't. Fix this. This should address a backtrace Dave dug out somewhere on unplug: [<ffffffffa00cc262>] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0 [drm_kms_helper] [<ffffffffa00cc211>] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0 [drm_kms_helper] [<ffffffffa00cc2aa>] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper] [<ffffffffa00cc2fb>] drm_dp_payload_send_msg.isra.14+0x2b/0x100 [drm_kms_helper] [<ffffffffa00cc547>] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper] [<ffffffffa015c52e>] intel_mst_disable_dp+0x3e/0x80 [i915] [<ffffffffa013d60b>] haswell_crtc_disable+0x1cb/0x340 [i915] [<ffffffffa0136739>] intel_crtc_control+0x49/0x100 [i915] [<ffffffffa0136857>] intel_crtc_update_dpms+0x67/0x80 [i915] [<ffffffffa013fa59>] intel_connector_dpms+0x59/0x70 [i915] [<ffffffffa015c752>] intel_dp_destroy_mst_connector+0x32/0xc0 [i915] [<ffffffffa00cb44b>] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper] [<ffffffffa00cb588>] drm_dp_destroy_mst_branch_device+0x108/0x130 [drm_kms_helper] [<ffffffffa00cb3cd>] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper] [<ffffffffa00cdb79>] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper] [<ffffffff810d9ead>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffffa00cdc73>] drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] [<ffffffffa00c7dfb>] ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] [<ffffffffa0153ed8>] ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] [<ffffffffa015a225>] intel_dp_check_mst_status+0xb5/0x250 [i915] [<ffffffffa015ac71>] intel_dp_hpd_pulse+0x181/0x210 [i915] [<ffffffffa01104f6>] i915_digport_work_func+0x96/0x120 [i915] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-09drm/fb_helper: move deferred fb checking into restore mode (v2)Dave Airlie1-4/+9
On MST systems the monitors don't appear when we set the fb up, but plymouth opens the drm device and holds it open while they come up, when plymouth finishes and lastclose gets called we don't do the delayed fb probe, so the monitor never appears on the console. Fix this by moving the delayed checking into the mode restore. v2: Daniel suggested that ->delayed_hotplug is set under the mode_config mutex, so we should check it under that as well, while we are in the area. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-09drm/dp: retry AUX transactions 32 times (v1.1)Dave Airlie1-3/+4
At least on two MST devices I've tested with, when they are link training downstream, they are totally unable to handle aux ch msgs, so they defer like nuts. I tried 16, it wasn't enough, 32 seems better. This fixes one Dell 4k monitor and one of the MST hubs. v1.1: fixup comment (Tom). Acked-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-07Linux 3.18Linus Torvalds1-1/+1
2014-12-05amdkfd: Disable support for 32-bit user processesOded Gabbay1-1/+12
This patch checks if the process that opens the /dev/kfd device is 32-bit process. If so, it returns -EPERM and prints a warning message in dmesg. This is done to prevent 32-bit user processes from using amdkfd, and hence, HSA features. AMD's HSA userspace stack will also support only 64-bit processes on Linux. Reviewed-by: Alexey Skidanov <alexey.skidanov@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-12-05watchdog: s3c2410_wdt: Fix the mask bit offset for Exynos7Abhilash Kesavan1-1/+1
The watchdog mask bit offset listed for Exynos7 is incorrect. Fix this. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Acked-by: Naveen Krishna Chatradhi <naveenkrishna.ch@gmail.com Reviewd-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
2014-12-04uapi: fix to export linux/vm_sockets.hMasahiro Yamada1-1/+1
A typo "header=y" was introduced by commit 7071cf7fc435 ("uapi: add missing network related headers to kbuild"). Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: David Miller <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-04i2c: cadence: Set the hardware time-out register to maximum valueVishnu Motghare1-0/+11
Cadence I2C controller has bug wherein it generates invalid read transactions after timeout in master receiver mode. This driver does not use the HW timeout and this interrupt is disabled but the feature itself cannot be disabled. Hence, this patch writes the maximum value (0xFF) to this register. This is one of the workarounds to this bug and it will not avoid the issue completely but reduces the chances of error. Signed-off-by: Vishnu Motghare <vishnum@xilinx.com> Signed-off-by: Harini Katakam <harinik@xilinx.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2014-12-04i2c: davinci: generate STP always when NACK is receivedGrygorii Strashko1-5/+3
According to I2C specification the NACK should be handled as follows: "When SDA remains HIGH during this ninth clock pulse, this is defined as the Not Acknowledge signal. The master can then generate either a STOP condition to abort the transfer, or a repeated START condition to start a new transfer." [I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf] Currently the Davinci i2c driver interrupts the transfer on receipt of a NACK but fails to send a STOP in some situations and so makes the bus stuck until next I2C IP reset (idle/enable). For example, the issue will happen during SMBus read transfer which consists from two i2c messages write command/address and read data: S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P <--- write -----------------------> <--- read ---------------------> The I2C client device will send NACK if it can't recognize "Command Code" and it's expected from I2C master to generate STP in this case. But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will not be generated. Hence, fix it by generating Stop condition (STP) always when NACK is received. This patch fixes Davinci I2C in the same way it was done for OMAP I2C commit cda2109a26eb ("i2c: omap: query STP always when NACK is received"). Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reported-by: Hein Tibosch <hein_tibosch@yahoo.es> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
2014-12-04ahci: disable MSI on SAMSUNG 0xa800 SSDTejun Heo1-0/+1
Just like 0x1600 which got blacklisted by 66a7cbc303f4 ("ahci: disable MSI instead of NCQ on Samsung pci-e SSDs on macbooks"), 0xa800 chokes on NCQ commands if MSI is enabled. Disable MSI. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Dominik Mierzejewski <dominik@greysector.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=89171 Cc: stable@vger.kernel.org
2014-12-04amdkfd: Set *buffer_ptr to NULL in case of errorOded Gabbay1-1/+7
In function acquire_packet_buffer() we may return -ENOMEM. In that case, we should set the *buffer_ptr to NULL, so that calling functions which check the *buffer_ptr value as a criteria for success, will know that acquire_packet_buffer() failed. Reviewed-by: Alexey Skidanov <alexey.skidanov@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-12-03context_tracking: Restore previous state in schedule_userAndy Lutomirski1-2/+6
It appears that some SCHEDULE_USER (asm for schedule_user) callers in arch/x86/kernel/entry_64.S are called from RCU kernel context, and schedule_user will return in RCU user context. This causes RCU warnings and possible failures. This is intended to be a minimal fix suitable for 3.18. Reported-and-tested-by: Dave Jones <davej@redhat.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Frédéric Weisbecker <fweisbec@gmail.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Andy Lutomirski <luto@amacapital.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03drm/radeon: enable smc fan control on CIAlex Deucher1-1/+0
This seems to work well on CI boards after fixing the last few bugs noticed by Chernovsky Oleg. On boards with a high default fan speed this should reduce fan noise. Manual fan control is not enabled yet. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: use pointers instead of indexes for CS chunksChristian König9-55/+53
Nobody is interested at which index the chunk is. What's needed is a pointer to the chunk. Remove unused chunk_id field as well. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: remove duplicates checkChristian König6-34/+16
Completely unnecessary since the ww_mutex used to reserve a buffer can detect double reservations from the same thread anyway. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/ttm: optionally move duplicates to a separate listChristian König7-8/+26
This patch adds an optional list_head parameter to ttm_eu_reserve_buffers. If specified duplicates in the execbuf list are no longer reported as errors, but moved to this list instead. Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: check the right ring in radeon_evict_flags()Alex Deucher1-1/+1
Check the that ring we are using for copies is functional rather than the GFX ring. On newer asics we use the DMA ring for bo moves. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-12-03drm/radeon: fix copy paste typos in fan control for si/ciAlex Deucher2-6/+6
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: Hide cursor on CRTCs used by fbdev (v2)Michel Dänzer1-1/+31
Since we are now preserving the cursor across modesets, the cursor could be left over in console if e.g. X crashed. v2: add comment about universal plane support Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: add spinlock for BO_VA status protection (v2)Christian König2-6/+33
Stop using the VM mutex for this v2: fix typo in comment Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: fence PT updates as sharedChristian König1-9/+19
The BO_VA contains everything necessary. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: rename radeon_cs_reloc to radeon_bo_listChristian König12-42/+42
Better match what it is actually doing. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: drop the handle from radeon_cs_relocChristian König3-6/+3
It's only used for duplicate check and that can be done on the original as well. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon drop gobj from radeon_cs_relocChristian König3-9/+9
It's only used once after initializing and that ptr can be calculated from the BO as well. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: fix typo in new fan control registers for SI/CIAlex Deucher2-8/+8
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: sync all BOs involved in a CSChristian König1-12/+7
Not just the userspace relocs, otherwise we won't wait for a swapped out page tables to be swapped in again. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: Move hotspot handling out of radeon_set_cursorMichel Dänzer1-19/+17
It's only needed in radeon_crtc_cursor_set2. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03drm/radeon: Re-show the cursor after a modesetMichel Dänzer4-24/+68
Setting a mode seems to clear the cursor registers, so we need to re-program them to make sure the cursor is visible. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-03slab: fix nodeid bounds check for non-contiguous node IDsPaul Mackerras1-1/+1
The bounds check for nodeid in ____cache_alloc_node gives false positives on machines where the node IDs are not contiguous, leading to a panic at boot time. For example, on a POWER8 machine the node IDs are typically 0, 1, 16 and 17. This means that num_online_nodes() returns 4, so when ____cache_alloc_node is called with nodeid = 16 the VM_BUG_ON triggers, like this: kernel BUG at /home/paulus/kernel/kvm/mm/slab.c:3079! Call Trace: .____cache_alloc_node+0x5c/0x270 (unreliable) .kmem_cache_alloc_node_trace+0xdc/0x360 .init_list+0x3c/0x128 .kmem_cache_init+0x1dc/0x258 .start_kernel+0x2a0/0x568 start_here_common+0x20/0xa8 To fix this, we instead compare the nodeid with MAX_NUMNODES, and additionally make sure it isn't negative (since nodeid is an int). The check is there mainly to protect the array dereference in the get_node() call in the next line, and the array being dereferenced is of size MAX_NUMNODES. If the nodeid is in range but invalid (for example if the node is off-line), the BUG_ON in the next line will catch that. Fixes: 14e50c6a9bc2 ("mm: slab: Verify the nodeid passed to ____cache_alloc_node") Signed-off-by: Paul Mackerras <paulus@samba.org> Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Pekka Enberg <penberg@kernel.org> Acked-by: David Rientjes <rientjes@google.com> Cc: Christoph Lameter <cl@linux.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03lib/genalloc.c: export devm_gen_pool_create() for modulesMichal Simek1-0/+1
Modules can use this function for creating pool. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Cc: Laura Abbott <lauraa@codeaurora.org> Cc: Olof Johansson <olof@lixom.net> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03mm: fix anon_vma_clone() error treatmentDaniel Forrest2-5/+11
Andrew Morton noticed that the error return from anon_vma_clone() was being dropped and replaced with -ENOMEM (which is not itself a bug because the only error return value from anon_vma_clone() is -ENOMEM). I did an audit of callers of anon_vma_clone() and discovered an actual bug where the error return was being lost. In __split_vma(), between Linux 3.11 and 3.12 the code was changed so the err variable is used before the call to anon_vma_clone() and the default initial value of -ENOMEM is overwritten. So a failure of anon_vma_clone() will return success since err at this point is now zero. Below is a patch which fixes this bug and also propagates the error return value from anon_vma_clone() in all cases. Fixes: ef0855d334e1 ("mm: mempolicy: turn vma_set_policy() into vma_dup_policy()") Signed-off-by: Daniel Forrest <dan.forrest@ssec.wisc.edu> Reviewed-by: Michal Hocko <mhocko@suse.cz> Cc: Konstantin Khlebnikov <koct9i@gmail.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Rik van Riel <riel@redhat.com> Cc: Tim Hartrick <tim@edgecast.com> Cc: Hugh Dickins <hughd@google.com> Cc: Michel Lespinasse <walken@google.com> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03mm: fix swapoff hang after page migration and forkHugh Dickins1-13/+13
I've been seeing swapoff hangs in recent testing: it's cycling around trying unsuccessfully to find an mm for some remaining pages of swap. I have been exercising swap and page migration more heavily recently, and now notice a long-standing error in copy_one_pte(): it's trying to add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing so even when it's a migration entry or an hwpoison entry. Which wouldn't matter much, except it adds dst_mm next to src_mm, assuming src_mm is already on the mmlist: which may not be so. Then if pages are later swapped out from dst_mm, swapoff won't be able to find where to replace them. There's already a !non_swap_entry() test for stats: move that up before the swap_duplicate() and the addition to mmlist. Signed-off-by: Hugh Dickins <hughd@google.com> Cc: Kelley Nielsen <kelleynnn@gmail.com> Cc: <stable@vger.kernel.org> [2.6.18+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03fat: fix oops on corrupted vfat fsAl Viro1-9/+11
a) don't bother with ->d_time for positives - we only check it for negatives anyway. b) make sure to set it at unlink and rmdir time - at *that* point soon-to-be negative dentry matches then-current directory contents c) don't go into renaming of old alias in vfat_lookup() unless it has the same parent (which it will, unless we are seeing corrupted image) [hirofumi@mail.parknet.co.jp: make change minimum, don't call d_move() for dir] Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: <stable@vger.kernel.org> [3.17.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03ipc/sem.c: fully initialize sem_array before making it visibleManfred Spraul1-7/+8
ipc_addid() makes a new ipc identifier visible to everyone. New objects start as locked, so that the caller can complete the initialization after the call. Within struct sem_array, at least sma->sem_base and sma->sem_nsems are accessed without any locks, therefore this approach doesn't work. Thus: Move the ipc_addid() to the end of the initialization. Signed-off-by: Manfred Spraul <manfred@colorfullife.com> Reported-by: Rik van Riel <riel@redhat.com> Acked-by: Rik van Riel <riel@redhat.com> Acked-by: Davidlohr Bueso <dave@stgolabs.net> Acked-by: Rafael Aquini <aquini@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03drivers/input/evdev.c: don't kfree() a vmalloc addressAndrew Morton1-1/+1
If kzalloc() failed and then evdev_open_device() fails, evdev_open() will pass a vmalloc'ed pointer to kfree. This might fix https://bugzilla.kernel.org/show_bug.cgi?id=88401, where there was a crash in kfree(). Reported-by: Christian Casteyde <casteyde.christian@free.fr> Belatedly-Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Henrik Rydberg <rydberg@euromail.se> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-12-03amdkfd: use atomic allocations within srcu callbacksSasha Levin1-1/+1
srcu callbacks are running in atomic context, we can't allocate using __GFP_WAIT. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-12-03amdkfd: use sizeof(long) granularity for the pasid bitmaskSasha Levin1-2/+1
All the bit operations (such as find_first_zero_bit()) read sizeof(long) bytes at a time. If we allocated less than sizeof(long) bytes for the bitmask we would be accessing invalid memory when working with the bitmask. Change the allocator to allocate sizeof(long) multiples for the bitmask. Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2014-12-03drm/vmwgfx: (Re)bind shaders to MOBs with the correct offsetThomas Hellstrom1-1/+1
This codepath is mostly hit when rebinding after a backup buffer swapout. It's amazing that this error hasn't been more obvious but probably the shaders are not reread from guest memory that often.. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2014-12-03drm/vmwgfx: Fix fence event codeThomas Hellstrom1-11/+6
The commit "vmwgfx: Rework fence event action" introduced a number of bugs that are fixed with this commit: a) A forgotten return stateemnt. b) An if statement with identical branches. Cc: <stable@vger.kernel.org> Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2014-12-03drm/vmwgfx: Don't use memory accounting for kernel-side fence objectsThomas Hellstrom1-20/+2
Kernel side fence objects are used when unbinding resources and may thus be created as part of a memory reclaim operation. This might trigger recursive memory reclaims and result in the kernel running out of stack space. So a simple way out is to avoid accounting of these fence objects. In principle this is OK since while user-space can trigger the creation of such objects, it can't really hold on to them. However, their lifetime is quite long, so some form of accounting should perhaps be implemented in the future. Fixes kernel crashes when running, for example viewperf11 ensight-04 test 3 with low system memory settings. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com>
2014-12-03drm/vmwgfx: Fix error printout on signals pendingThomas Hellstrom1-2/+6
The function vmw_master_check() might return -ERESTARTSYS if there is a signal pending, indicating that the IOCTL should be rerun, potentially from user-space. At that point we shouldn't print out an error message since that is not an error condition. In short, avoid bloating the kernel log when a process refuses to die on SIGTERM. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
2014-12-03drm/i915: Reject modeset when the same digital port is used more than onceVille Syrjälä1-0/+47
On pre-HSW we have two encoders per digital port: one HDMI, one DP. However they are the same physical port in hardware and we can't enable both at the same time. Reject the modeset if the user attempts this. So far we've been saved by the fact that we never see both HDMI and DP connectors as connected. But if the user decides to force a mode anyway, all kinds of funny stuff might happen. Unfortunately we don't seem to have any way to inform userspace that such configurations are invalid except by returning an error from setcrtc. possible_clones only covers real cloning situations, and looking at the connector names doesn't work either since we don't always register both connectors for the same port. I suppose the only way to fix that would be to expose only a single encoder per digital port like we do on HSW+ but that would be a fairly large undertaking for little gain. kms_setmode hits this since it forces modes on non-connected VGA and HDMI connectors. Previosuly it just resulted in weirdness such as failed link training. With this patch it will now get an error back from the kernel and will die with an assert since it thinks that the configuration should be fine. v2: Deal with INTEL_OUTPUT_UNKNOWN (Paulo) Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: mask RPS IRQs properly when disabling RPSImre Deak1-7/+20
Atm, igt/gem_reset_stats can trigger the recently added WARN on left-over PM_IIR bits in gen6_enable_rps_interrupts(). There are two reasons for this: 1. we call intel_enable_gt_powersave() without a preceeding intel_disable_gt_powersave() 2. gen6_disable_rps_interrupts() doesn't mask interrupts in PM_IMR 1. means RPS interrupts will remain enabled and can be serviced during the HW initialization after a GPU reset. 2. means even if we called gen6_disable_rps_interrupts() any new RPS interrupt during RPS initialization would still propagate to PM_IIR too early (though wouldn't be serviced). This patch solves the 2. issue by also masking interrupts in PM_IMR, the following patch fixes 1. getting rid of the WARN. This also makes intel_enable_gt_powersave() and intel_disable_gt_powersave() more symmetric. Since gen6_disable_rps_interrupts() is called during driver loading with i915 interrupts disabled add a new version of gen6_disable_pm_irq() that doesn't WARN for this. Also while at it, get the irq_lock around the whole PM_IMR/IER/IIR programming sequence and make sure that any queued PM_IIR bit is also cleared. The WARN was caught by PRTS after I sent my previous RPS sanitizing patchset and I could easily reproduce it on HSW. To actually fix it we also need the next patch. Reported-by: He, Shuang <shuang.he@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Tune down spurious CRC interrupt warningDaniel Vetter1-1/+1
We don't really synchronously turn them off from debugfs. We try to avoid hitting them too badly by waiting one vblank, but apparently the irq handler can still race through that gap. Since this isn't really all that important for testcases, only for debugging CRC issues let's tune it down to a debug message. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82602 Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-03drm/i915: Fix context object leak for legacy contextsThomas Daniel1-4/+6
Dynamic context pinning for LRCs introduced a leak in legacy mode. Reinstate context unreference in i915_gem_free_request for legacy contexts. Leak reported by i-g-t/drv_module_reload fixed by this patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86507 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: John Harrison<John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915/skl: Update in Gen9 multi-engine forcewake rangeAkash Goel1-4/+8
Updates in forcewake range for Render/Media/Common power wells for Gen9. Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915/eDP: When enabling panel VDD cancel pending disable workerEgbert Eich1-0/+1
Before testing if the panel VDD is enabled on eDP cancel any pending disable worker. This makes sure the worker will be triggered with a delay from the last time edp_panel_vdd_schedule_off() is called, not the first time. This avoids unnecessary overhead. https://bugs.freedesktop.org/show_bug.cgi?id=86201 v2: use cancel_delayed_work() instead of cancel_delayed_work_sync() as the pps_mutexes will provide the required serialization with edp_panel_vdd_work() while the sync variant may deadlock. Suggested by Ville Syrjälä <ville.syrjala@linux.intel.com>. Made commit message a bit clearer. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.