summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-01-22MIPS: BCM63XX: always register bmips smp opsJonas Gorski
Use the return value for guarding further SMP setup. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6249/
2014-01-22MIPS: BMIPS: add a smp ops registration helperJonas Gorski
Add a helper similar to the generic register_XXX_smp_ops() for bmips. Register SMP UP ops in case of BMIPS32/3300. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6248/
2014-01-22MIPS: BMIPS: extend BMIPS3300 to include BMIPS32Jonas Gorski
Codewise there is no difference between these two, so it does not make sense to treat them differently. Also chip families having one of these tend to have the other. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6247/
2014-01-22MIPS: BMIPS: select CPU_HAS_PREFETCHJonas Gorski
As they are MIPS32 CPUs they do support the prefetch opcode. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6243/
2014-01-22MIPS: BMIPS: select CPU_SUPPORTS_HIGHMEMJonas Gorski
All BMIPS CPUs support HIGHMEM, so it should be selected by CPU_BMIPS. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6242/
2014-01-22MIPS: BMIPS: merge CPU options into one optionJonas Gorski
Instead of treating each flavour as an exclusive CPU to select, make BMIPS the only option and let SYS_HAS_CPU_BMIPS* decide for which flavours to include support. Run tested on BMIPS3300 and BMIPS4350, only build tested for BMIPS4380 and BMIPS5000. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6240/
2014-01-22MIPS: BMIPS: change compile time checks to runtime checksJonas Gorski
Allow building for all bmips cpus at the same time by changing ifdefs to checks for the cpu type, or adding appropriate checks to the assembly. Since BMIPS43XX and BMIPS5000 require different IPI implementations, split the SMP ops into one for each, so the runtime overhead is only at registration time for them. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6241/
2014-01-22MIPS: allow asm/cpu.h to be included from assemblyJonas Gorski
Add guards around the enum to allow including cpu.h from assembly. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6238/
2014-01-22MIPS: BCM63XX: disable SMP also on BCM3368Jonas Gorski
BCM3368 has the same shared TLB as BCM6358. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6239/
2014-01-22MIPS: BCM63XX: add HSSPI platform device and register itJonas Gorski
Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6180/
2014-01-22MIPS: BCM63XX: add HSSPI IRQ and register offsetsJonas Gorski
Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6179/
2014-01-22MIPS: BCM63XX: setup the HSSPI clock rateJonas Gorski
Properly set up the HSSPI clock rate depending on the SoC's PLL rate. Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6177/
2014-01-22MIPS: BCM63XX: expose the HSSPI clockJonas Gorski
Signed-off-by: Jonas Gorski <jogo@openwrt.org> Signed-off-by: John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6178/
2014-01-22fuse: support clients that don't implement 'open'Andrew Gallagher
open/release operations require userspace transitions to keep track of the open count and to perform any FS-specific setup. However, for some purely read-only FSs which don't need to perform any setup at open/release time, we can avoid the performance overhead of calling into userspace for open/release calls. This patch adds the necessary support to the fuse kernel modules to prevent open/release operations from hitting in userspace. When the client returns ENOSYS, we avoid sending the subsequent release to userspace, and also remember this so that future opens also don't trigger a userspace operation. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
2014-01-22fuse: don't invalidate attrs when not using atimeAndrew Gallagher
Various read operations (e.g. readlink, readdir) invalidate the cached attrs for atime changes. This patch adds a new function 'fuse_invalidate_atime', which checks for a read-only super block and avoids the attr invalidation in that case. Signed-off-by: Andrew Gallagher <andrewjcg@fb.com> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
2014-01-22fuse: fix SetPageUptodate() condition in STOREMiklos Szeredi
As noticed by Coverity the "num != 0" condition never triggers. Instead it should check for a complete page. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
2014-01-22fuse: fix pipe_buf_operationsMiklos Szeredi
Having this struct in module memory could Oops when if the module is unloaded while the buffer still persists in a pipe. Since sock_pipe_buf_ops is essentially the same as fuse_dev_pipe_buf_steal merge them into nosteal_pipe_buf_ops (this is the same as default_pipe_buf_ops except stealing the page from the buffer is not allowed). Reported-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> Cc: stable@vger.kernel.org
2014-01-22Merge branch 'misc' into for-linusJames Bottomley
2014-01-22ASoC: samsung: smdk_wm8994: Fix build errorSachin Kamat
Fixes the following build error and warning when OF is not defined: sound/soc/samsung/smdk_wm8994.c:191:23: error: ‘samsung_wm8994_of_match’ undeclared (first use in this function) sound/soc/samsung/smdk_wm8994.c:47:32: warning: ‘smdk_board_data’ defined but not used [-Wunused-variable] of_match_ptr() is used so that samsung_wm8994_of_match gets dropped (as unused) by the compiler when OF is not defined. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-01-22ASoC: Samsung: s3c-i2s-v2: Fix build errorSachin Kamat
Fixes the following error introduced by commit eca3b01d0885 ("ASoC: switch over to use snd_soc_register_component() on s3c i2s"): sound/soc/samsung/s3c-i2s-v2.c:732:32: error: ‘drv’ undeclared (first use in this function) Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-01-22ASoC: samsung: Fix build regressions due to gpio re-orgSachin Kamat
Recent changes through commits c67d0f29262b ("ARM: s3c24xx: get rid of custom <mach/gpio.h>"), b0161caa72b6 ("ARM: S3C[24|64]xx: move includes back under <mach/> scope"), 364374121b78 ("ARM: s3c24xx: explicit dependency on <plat/gpio-cfg.h>") and 41c3548e6da6 ("ARM: s3c64xx: get rid of custom <mach/gpio.h>") caused build regressions due to broken dependencies. Fix the following errors by including the necessary header files explicitly: sound/soc/samsung/h1940_uda1380.c:56:3: error: implicit declaration of function ‘S3C2410_GPG’ sound/soc/samsung/h1940_uda1380.c:149:18: error: ‘S3C_GPIO_END’ undeclared (first use in this function) sound/soc/samsung/h1940_uda1380.c:234:21: error: ‘S3C_GPIO_END’ undeclared (first use in this function) sound/soc/samsung/h1940_uda1380.c:270:12: error: ‘S3C_GPIO_END’ undeclared (first use in this function) sound/soc/samsung/neo1973_wm8753.c:239:2: error: implicit declaration of function ‘S3C2410_GPJ’ sound/soc/samsung/rx1950_uda1380.c:67:3: error: implicit declaration of function ‘S3C2410_GPG’ sound/soc/samsung/s3c2412-i2s.c:86:2: error: implicit declaration of function ‘s3c_gpio_cfgall_range’ sound/soc/samsung/s3c2412-i2s.c:86:2: error: implicit declaration of function ‘S3C2410_GPE’ sound/soc/samsung/s3c2412-i2s.c:86:2: error: implicit declaration of function ‘S3C_GPIO_SFN’ sound/soc/samsung/s3c2412-i2s.c:87:10: error: ‘S3C_GPIO_PULL_NONE’ undeclared sound/soc/samsung/s3c24xx-i2s.c:394:2: error: implicit declaration of function ‘s3c_gpio_cfgall_range’ sound/soc/samsung/s3c24xx-i2s.c:394:2: error: implicit declaration of function ‘S3C2410_GPE’ sound/soc/samsung/s3c24xx-i2s.c:394:2: error: implicit declaration of function ‘S3C_GPIO_SFN’ sound/soc/samsung/s3c24xx-i2s.c:395:10: error: ‘S3C_GPIO_PULL_NONE’ undeclared sound/soc/samsung/smartq_wm8987.c:112:3: error: implicit declaration of function ‘S3C64XX_GPL’ Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-01-22arm64: mm: fix the function name in comment of __flush_dcache_areaJingoo Han
Fix the function name of comment of __flush_dcache_area, because __flush_dcache_area is the correct name. Also, the missing variable 'size' is added to the comment. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2014-01-22arm64: mm: use ubfm for dcache_line_sizeJingoo Han
Use 'ubfm' for the bitfield move instruction; thus, single instruction can be used instead of two instructions, when getting the minimum D-cache line size from CTR_EL0 register. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2014-01-22Merge branches 'for-3.13/upstream-fixes', 'for-3.14/i2c-hid', ↵Jiri Kosina
'for-3.14/sensor-hub', 'for-3.14/sony' and 'for-3.14/upstream' into for-linus
2014-01-22s390: wire up sys_sched_setattr/sys_sched_getattrHeiko Carstens
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/uapi: fix struct statfs64 definitionHeiko Carstens
With b8668fd0a7e1b59f "s390/uapi: change struct statfs[64] member types to unsigned values" the size of a couple of struct statfs64 member got incorrectly changed from 64 to 32 bit for 32 bit builds. Fix this by changing the type of couple of struct statfs64 members from unsigned long to unsigned long long. The definition of struct compat_statfs64 was correct however. Cc: stable@vger.kernel.org # v3.10+ Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/uaccess: remove dead extern declarations, make functions staticHeiko Carstens
Remove some dead uaccess extern declarations and also make some functions static, since they are only used locally. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/uaccess: test if current->mm is set before walking page tablesHeiko Carstens
If get_fs() == USER_DS we better test if current->mm is not zero before walking page tables. The page table walk code would try to lock mm->page_table_lock, however if mm is zero this might crash. Now it is arguably incorrect trying to access userspace if current->mm is zero, however we have seen that and s390 would be the only architecture which would crash in such a case. So we better make the page table walk code a bit more robust and report always a fault instead. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/zfcpdump: make zfcpdump depend on 64BITHeiko Carstens
Get rid of this link error: arch/s390/built-in.o: In function `smp_prepare_cpus': (.init.text+0x301e): undefined reference to `dump_save_area_create' Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/32bit: fix cmpxchg64Heiko Carstens
Fix broken inline assembly contraints for cmpxchg64 on 32bit. Fixes this crash: specification exception: 0006 [#1] SMP CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.13.0 #4 task: 005a16c8 ti: 00592000 task.ti: 00592000 Krnl PSW : 070ce000 8029abd6 (lockref_get+0x3e/0x9c) ... Krnl Code: 8029abcc: a71a0001 ahi %r1,1 8029abd0: 1852 lr %r5,%r2 #8029abd2: bb40f064 cds %r4,%r0,100(%r15) >8029abd6: 1943 cr %r4,%r3 8029abd8: 1815 lr %r1,%r5 Call Trace: ([<0000000078e01870>] 0x78e01870) [<000000000021105a>] sysfs_mount+0xd2/0x1c8 [<00000000001b551e>] mount_fs+0x3a/0x134 [<00000000001ce768>] vfs_kern_mount+0x44/0x11c [<00000000001ce864>] kern_mount_data+0x24/0x3c [<00000000005cc4b8>] sysfs_init+0x74/0xd4 [<00000000005cb5b4>] mnt_init+0xe0/0x1fc [<00000000005cb16a>] vfs_caches_init+0xb6/0x14c [<00000000005be794>] start_kernel+0x318/0x33c [<000000000010001c>] _stext+0x1c/0x80 Reported-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/xpram: don't modify module parametersSebastian Ott
During parsing of the sizes array the pointer to the particular string is lost. Keep it by using an extra pointer to store the end position of the parsed string. Keeping these parameters accessible can be helpful for debugging purposes and for userspace reading the parameters at runtime via sysfs. Also this will ensure that the memory is freed at module unload time. Reported-by: Michael Veigel <veigel@de.ibm.com> Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/zcrypt: remove zcrypt kmsg documentation againHeiko Carstens
This part of the ep11 patch should not have been merged. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/hvc_iucv: Automatically assign free HVC terminal devicesHendrik Brueckner
Add the generic "lnxhvc" terminal ID to automatically assign a HVC terminal when connecting to the HVC IUCV terminal device driver. The terminal device driver tries to find a free (not connected) HVC terminal to satisfy the incoming connection request. With this improvement, you do not longer need to guess which HVC terminal is free, that is, not connected. Also you can still connect to a particular HVC terminal by using its associated terminal ID. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/hvc_iucv: Display connection details through device attributesHendrik Brueckner
Add device attributes to display details about the connection status of HVC IUCV terminals. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/hvc_iucv: fix sparse warningHendrik Brueckner
drivers/tty/hvc/hvc_iucv.c:131:25: warning: symbol 'hvc_iucv_get_private' was not declared. Should it be static? Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22s390/vmur: Link parent CCW device during UR device creationHendrik Brueckner
When creating the virtual unit record (UR) device, specify the parent CCW device. Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-01-22MAINTAINERS: Restore "L: linux-kernel@vger.kernel.org" entriesIngo Molnar
A couple of years ago all the "L: lkml" email list entries in MAINTAINERS were removed and replaced with a 'the rest' entry at the end of the file - under the theory that this is unnecessary duplication and that people would find it intuitive: b5472cddbe2c MAINTAINERS: remove L: linux-kernel@vger.kernel.org from all but "THE REST" So it turns out that it's all but intuitive, not all people use scripts/get_maintainer.pl to extract maintainer contact info, some people read the MAINTAINERS file and see the lack of 'L:' entries of various lkml-only subsystems and are sending patches to the maintainers only, without Cc:-ing lkml. They arguably have a point. In hindsight removing all the "L: lkml" entries was probably not an overly good idea, not all mechanic duplication should be eliminated: in files read by humans it's useful to have 'at a glance' summary for all email addresses important to a subsystem's maintenance, in a single place, without too many imported rules and assumptions. So, to make the lkml fallback really apparent, add back 'L: lkml' entries to all subsystem entries whose workflow I'm involved in. This should at minimum be a per subsystem policy thing. Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Alan Cox <alan@linux.intel.com> Cc: Joe Perches <joe@perches.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Link: http://lkml.kernel.org/n/tip-lhzlymtgmmv5bMuwsb5zyoYo@git.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-01-22x86, boot: Use __attribute__((used)) to ensure videocard structs are emittedDavid Woodhouse
It looks like GCC will always emit an object that is marked with an explicit section, although the documentation doesn't say that and we possibly shouldn't be relying on it. Clang does *not* do so, so add __attribute__((used)) to make sure. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Link: http://lkml.kernel.org/r/1389180083-23249-2-git-send-email-David.Woodhouse@intel.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2014-01-22x86: Remove duplication of 16-bit CFLAGSDavid Woodhouse
Define them once in arch/x86/Makefile instead of twice. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Link: http://lkml.kernel.org/r/1389180083-23249-1-git-send-email-David.Woodhouse@intel.com Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2014-01-22x86, relocs: Add manual debug modeMichael Davidson
Improve the debuggability of relocations output. When trying to compare the output between different linkers, it's handy to be able to see the section names in output. Signed-off-by: Michael Davidson <md@google.com> Link: http://lkml.kernel.org/r/20140121203223.GA12649@www.outflux.net Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2014-01-22drm/i915: Allow reading the TIMESTAMP register on Gen8.Kenneth Graunke
Nothing's changed here; we just need to bump the generation check. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22f2fs: introduce NODE_MAPPING for code consistencyJaegeuk Kim
This patch adds NODE_MAPPING which is similar as META_MAPPING introduced by Gu Zheng. Cc: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2014-01-22f2fs: remove the orphan block page arrayGu Zheng
As the orphan_blocks may be max to 504, so it is not security and rigorous to store such a large array in the kernel stack as Dan Carpenter said. In fact, grab_meta_page has locked the page in the page cache, and we can use find_get_page() to fetch the page safely in the downstream, so we can remove the page array directly. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2014-01-22f2fs: add help function META_MAPPINGGu Zheng
Introduce help function META_MAPPING() to get the cache meta blocks' address space. Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com> Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2014-01-22f2fs: move a branch for code redabilityJaegeuk Kim
This patch moves a function in f2fs_delete_entry for code readability. Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2014-01-22f2fs: call mark_inode_dirty to flush dirty pagesJaegeuk Kim
If a dentry page is updated, we should call mark_inode_dirty to add the inode into the dirty list, so that its dentry pages are flushed to the disk. Otherwise, the inode can be evicted without flush. Signed-off-by: Jaegeuk Kim <jaegeuk.kim@samsung.com>
2014-01-22drm/i915: Repeat evictions whilst pageflip completions are outstandingChris Wilson
Since an old pageflip will keep its scanout buffer object pinned until it has executed its unpin task on the common workqueue, we can clog up our GGTT with stale pinned objects. As we cannot flush those workqueues without dropping our locks, we have to resort to falling back to userspace and telling them to repeat the operation in order to have a chance to run our workqueues and free up the required memory. If we fail, then we are forced to report ENOSPC back to userspace causing the operation to fail and best-case scenario is that it introduces temporary corruption. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22drm/i915: Wait for completion of pending flips when starved of fencesChris Wilson
On older generations (gen2, gen3) the GPU requires fences for many operations, such as blits. The display hardware also requires fences for scanouts and this leads to a situation where an arbitrary number of fences may be pinned by old scanouts following a pageflip but before we have executed the unpin workqueue. This is unpredictable by userspace and leads to random EDEADLK when submitting an otherwise benign execbuffer. However, we can detect when we have an outstanding flip and so cause userspace to wait upon their completion before finally declaring that the system is starved of fences. This is really no worse than forcing the GPU to stall waiting for older execbuffer to retire and release their fences before we can reallocate them for the next execbuffer. v2: move the test for a pending fb unpin to a common routine for later reuse during eviction Reported-and-tested-by: dimon@gmx.net Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22drm/i915: don't disable DP port after a failed link trainingImre Deak
Atm after a failed link training we disable the DP port. This can happen during a modeset-enable or a DP link re-establishment. The latter can be a problem and we shouldn't disable the DP port, see the previous patch for the reasoning. In the former case the right thing would be to disable the DP port, but also the rest of the pipe. As a stop-gap solution leave the DP port enabled in both cases. It is an improvement on its own (avoiding HW lock ups) and the proper solution for the first case requires a bigger change, so let's keep that on the TODO list. v2: - fix explanation of change impact (Chris) Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-01-22drm/i915: don't disable the DP port if the link is lostImre Deak
Currently if the DP link is lost (either because of a hot unplug, or failed link status check) we disable the DP port, but leave the rest of the pipe running. This is incompatible with the modeset disabling sequence of some platforms/configurations. At least this is the case for DP ports on the CPU as opposed to PCH. Atm we'll also get a warning when we do a modeset disable after the above link lost event, since we expect the DP port to be enabled at this point (see the bugzilla ticket for the related dmesg). Note that with this patch we'll still end up disabling the port, thanks to the HPD uevent and subsequent modeset disable. See also the next patch fixing the other half of this issue. Solution suggested by Ville. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>