- 07 Mar, 2015 5 commits
-
-
Wang YanQing authored
These quirk entries have the same effect as default quirk entry, so we can just delete them. Signed-off-by:
Wang YanQing <udknight@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Wang YanQing authored
Commit 8b5c913f ("serial: 8250_pci: Add WCH CH352 quirk to avoid Xscale detection") trigger one redundant entry report message. This patch fix it. Reported-by:
Russell King <rmk@arm.linux.org.uk> Signed-off-by:
Wang YanQing <udknight@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Russell King authored
I'm still receiving reports to my email address, so let's point this at the linux-serial mailing list instead. Cc: <stable@vger.kernel.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Sebastian Andrzej Siewior authored
This reverts commit 0aa525d1. The conditional RX-FIFO read seems to cause spurious interrupts and we see just: |serial8250: too much work for irq29 The previous behaviour was "default" for decades and Marvell's 88f6282 SoC might not be the only that relies on it. Therefore the Omap fix is reverted for now. Fixes: 0aa525d1 ("tty: serial: 8250_core: read only RX if there is something in the FIFO") Reported-By:
Nicolas Schichan <nschichan@freebox.fr> Debuged-By:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Baruch Siach authored
This reverts commit 6d01bb9d. The exact same code was added in commit 3239fd31 (serial: of-serial: fetch line number from DT) a few lined above. Doing this once should be enough. Cc: Rob Herring <robh@kernel.org> Signed-off-by:
Baruch Siach <baruch@tkos.co.il> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 Mar, 2015 1 commit
-
-
Daniel Vetter authored
This is a tricky story of the new atomic state handling and the legacy code fighting over each another. The bug at hand is an underrun of the framebuffer reference with subsequent hilarity caused by the load detect code. Which is peculiar since the the exact same code works fine as the implementation of the legacy setcrtc ioctl. Let's look at the ingredients: - Currently our code is a crazy mix of legacy modeset interfaces to set the parameters and half-baked atomic state tracking underneath. While this transition is going we're using the transitional plane helpers to update the atomic side (drm_plane_helper_disable/update and friends), i.e. plane->state->fb. Since the state structure owns the fb those functions take care of that themselves. The legacy state (specifically crtc->primary->fb) is still managed by the old code (and mostly by the drm core), with the fb reference counting done by callers (core drm for the ioctl or the i915 load detect code). The relevant commit is commit ea2c67bb Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Dec 23 10:41:52 2014 -0800 drm/i915: Move to atomic plane helpers (v9) - drm_plane_helper_disable has special code to handle multiple calls in a row - it checks plane->crtc == NULL and bails out. This is to match the proper atomic implementation which needs the crtc to get at the implied locking context atomic updates always need. See commit acf24a39 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 29 15:33:05 2014 +0200 drm/plane-helper: transitional atomic plane helpers - The universal plane code split out the implicit primary plane from the CRTC into it's own full-blown drm_plane object. As part of that the setcrtc ioctl (which updated both the crtc mode and primary plane) learned to set crtc->primary->crtc on modeset to make sure the plane->crtc assignments statate up to date in commit e13161af Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Apr 1 15:22:38 2014 -0700 drm: Add drm_crtc_init_with_planes() (v2) Unfortunately we've forgotten to update the load detect code. Which wasn't a problem since the load detect modeset is temporary and always undone before we drop the locks. - Finally there is a organically grown history (i.e. don't ask) around who sets the legacy plane->fb for the various driver entry points. Originally updating that was the drivers duty, but for almost all places we've moved that (plus updating the refcounts) into the core. Again the exception is the load detect code. Taking all together the following happens: - The load detect code doesn't set crtc->primary->crtc. This is only really an issue on crtcs never before used or when userspace explicitly disabled the primary plane. - The plane helper glue code short-circuits because of that and leaves a non-NULL fb behind in plane->state->fb and plane->fb. The state fb isn't a real problem (it's properly refcounted on its own), it's just the canary. - Load detect code drops the reference for that fb, but doesn't set plane->fb = NULL. This is ok since it's still living in that old world where drivers had to clear the pointer but the core/callers handled the refcounting. - On the next modeset the drm core notices plane->fb and takes care of refcounting it properly by doing another unref. This drops the refcount to zero, leaving state->plane now pointing at freed memory. - intel_plane_duplicate_state still assume it owns a reference to that very state->fb and bad things start to happen. Fix this all by applying the same duct-tape as for the legacy setcrtc ioctl code and set crtc->primary->crtc properly. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: Rob Clark <robdclark@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Matt Roper <matthew.d.roper@intel.com> Reported-and-tested-by:
Linus Torvalds <torvalds@linux-foundation.org> Reported-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- 28 Feb, 2015 6 commits
-
-
Joonsoo Kim authored
max_used_pages is defined as atomic_long_t so we need to use unsigned long to keep temporary value for it rather than int which is smaller than unsigned long in a 64 bit system. Signed-off-by:
Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Jerome Marchand <jmarchan@redhat.com> Cc: Nitin Gupta <ngupta@vflare.org> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Joshua Kinard authored
Fix a conditional statement checking for NULL in both ds1685_rtc_sysfs_time_regs_show and ds1685_rtc_sysfs_time_regs_store that was using a logical AND when it should be using a logical OR so that we fail out of the function properly if the condition ever evaluates to true. Fixes: aaaf5fbf ("rtc: add driver for DS1685 family of real time clocks") Signed-off-by:
Joshua Kinard <kumba@gentoo.org> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Geert Uytterhoeven authored
drivers/rtc/rtc-ds1685.c: In function `ds1685_rtc_read_alarm': drivers/rtc/rtc-ds1685.c:402: warning: comparison is always true due to limited range of data type drivers/rtc/rtc-ds1685.c:409: warning: comparison is always true due to limited range of data type drivers/rtc/rtc-ds1685.c:416: warning: comparison is always true due to limited range of data type drivers/rtc/rtc-ds1685.c: In function `ds1685_rtc_set_alarm': drivers/rtc/rtc-ds1685.c:475: warning: comparison is always true due to limited range of data type drivers/rtc/rtc-ds1685.c:478: warning: comparison is always true due to limited range of data type drivers/rtc/rtc-ds1685.c:481: warning: comparison is always true due to limited range of data type u8 cannot contain a value larger than 0xff, hence drop the checks. Wrapping the checks in unlikely() indicated some sense of humor, though ;-) Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Joshua Kinard <kumba@gentoo.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Arnd Bergmann authored
The newly added ds1685 driver causes a build error when enabled without CONFIG_RTC_INTF_DEV: drivers/rtc/rtc-ds1685.c:919:22: error: 'ds1685_rtc_alarm_irq_enable' undeclared here (not in a function) .alarm_irq_enable = ds1685_rtc_alarm_irq_enable, Apparently the driver was incorrectly changed to reflect the interface change from 16380c15 ("RTC: Convert rtc drivers to use the alarm_irq_enable method"), which removed the respective #ifdef from all other rtc drivers. This does the same change that was merged for the other drivers before and removes the #ifdef, allowing the interrupts to be enabled through the in-kernel rtc interface independent of the existence of /dev/rtc. Fixes: aaaf5fbf ("rtc: add driver for DS1685 family of real time clocks") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Joshua Kinard <kumba@gentoo.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Srinivas Pandruvada authored
It is possible that _ART/_TRT tables are missing or have errors. Ignore those failures, as INT3400 thermal zone is still required for _OSC or mode switch. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com>
-
Miguel Bernal Marin authored
Enable Intel Powerclamp driver on Atom* Processor C2000 Product Family for Microservers (Avoton). Avoton - SoCs for micro-servers has package C-states which can be used for idle injection. Reported-by:
Jose Navarro <jose.navarro@intel.com> Suggested-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Tested-by:
Jose Carlos Venegas Munoz <jos.c.venegas.munoz@intel.com> Signed-off-by:
Miguel Bernal Marin <miguel.bernal.marin@linux.intel.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com>
-
- 26 Feb, 2015 1 commit
-
-
Nicolas Ferre authored
Remove this configuration bit in crtc driver as the rising edge clock is widely used. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com>
-
- 25 Feb, 2015 17 commits
-
-
Alex Deucher authored
We were enabling DP secondary streams even if the monitor didn't support them. Fixes display problems on some DP monitors. Tested-by:
Jim Boz <jim876@xs4all.nl> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
The atom aux param interface only supports 4 bits for the total write transfer size (header + payload). This limits us to 12 bytes of payload rather than 16. Add a check for this. Reads are not affected. v2: switch to WARN_ON_ONCE Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
The logic was reversed from what the hw actually exposed. Fixes graphics corruption in certain harvest configurations. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Christian König authored
Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Christian König authored
Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Leo Liu authored
v2: disable it on suspend Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
Dump the whole IB if we run into an invalid packet. This makes things much easier to debug. bug: https://bugs.freedesktop.org/show_bug.cgi?id=89148 Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
These tend to be problematic even if the vblank period is long enough. This needs more investigation across a wider range of displays. Disable for now. bugs: https://bugs.freedesktop.org/show_bug.cgi?id=87796 https://bugs.freedesktop.org/show_bug.cgi?id=89198 Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Alex Deucher authored
Just in case it hasn't been calculated for the mode. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Nathan-J. Hirschauer authored
Commit b7bc596e ("drm/radeon: disable native backlight control on pre-r6xx asics (v2)") accidently broke backlight control on old mac laptops that use the on-GPU backlight controller. Signed-off-by:
Nathan-J. Hirschauer <nathanhi@deepserve.info> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
Robert Jarzmik authored
As pxa_timer_common_init() is only called in init context, mark it as such, and quiesce the compiler warnings : WARNING: vmlinux.o(.text.unlikely+0x45d4): Section mismatch in reference from the function pxa_timer_common_init() to the function .init.text:sched_clock_register() WARNING: vmlinux.o(.text.unlikely+0x4610): Section mismatch in reference from the function pxa_timer_common_init() to the function .init.text:clocksource_mmio_init() Signed-off-by:
Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org>
-
Matthias Brugger authored
We have two race conditions in the probe code which could lead to a null pointer dereference in the interrupt handler. The interrupt handler accesses the clockevent device, which may not yet be registered. First race condition happens when the interrupt handler gets registered before the interrupts get disabled. The second race condition happens when the interrupts get enabled, but the clockevent device is not yet registered. Fix that by disabling the interrupts before we register the interrupt and enable the interrupts after the clockevent device got registered. Reported-by:
Gongbae Park <yongbae2@gmail.com> Signed-off-by:
Matthias Brugger <matthias.bgg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org>
-
Daniel Lezcano authored
The Kconfig options for the asm9260 timer is wrong as it can be selected by another platform with allyes config and thus leading to a compilation failure as some non arch related code is pulled by the compilation. Fix this by having the platform Kconfig to select the timer as it is done for the others drivers. Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Oleksij Rempel <linux@rempel-privat.de> Conflicts: drivers/clocksource/Kconfig
-
Rodrigo Vivi authored
This return 0 without setting atomic bits on fb == crtc->cursor->fb where causing frontbuffer false positives. According to Daniel: The original regression seems to have been introduced in the original check/commit split: commit 757f9a3e Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 24 14:20:24 2014 -0300 drm/i915: move check of intel_crtc_cursor_set_obj() out Which already cause other trouble, resulting in the check getting moved in commit e391ea88 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Wed Sep 24 14:20:25 2014 -0300 drm/i915: Fix not checking cursor and object sizes The frontbuffer tracking itself only was broken when we shifted it into the check/commit logic with: commit 32b7eeec Author: Matt Roper <matthew.d.roper@intel.com> Date: Wed Dec 24 07:59:06 2014 -0800 drm/i915: Refactor work that can sleep out of commit (v7) v2: When putting more debug prints I notice the solution was simpler than I thought. AMS design is solid, just this return was wrong. Sorry for the noise. v3: Remove the entire chunck that would probably be removed by gcc anyway. (by Daniel) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
NeilBrown authored
Since __ATTR_PREALLOC was introduced in v3.19-rc1~78^2~18 it can now be used by md. This ensure that writing to these sysfs attributes will never block due to a memory allocation. Such blocking could become a deadlock if mdmon is trying to reconfigure an array after a failure prior to re-enabling writes. Signed-off-by:
NeilBrown <neilb@suse.de>
-
Eric Mei authored
When we have more than 1 drive failure, it's possible we start rebuild one drive while leaving another faulty drive in array. To determine whether array will be optimal after building, current code only check whether a drive is missing, which could potentially lead to data corruption. This patch is to add checking Faulty flag. Signed-off-by:
NeilBrown <neilb@suse.de>
-
Tomáš Hodek authored
When a drive is marked write-mostly it should only be the target of reads if there is no other option. This behaviour was broken by commit 9dedf603 md/raid1: read balance chooses idlest disk for SSD which causes a write-mostly device to be *preferred* is some cases. Restore correct behaviour by checking and setting best_dist_disk and best_pending_disk rather than best_disk. We only need to test one of these as they are both changed from -1 or >=0 at the same time. As we leave min_pending and best_dist unchanged, any non-write-mostly device will appear better than the write-mostly device. Reported-by:
Tomáš Hodek <tomas.hodek@volny.cz> Reported-by:
Dark Penguin <darkpenguin@yandex.ru> Signed-off-by:
NeilBrown <neilb@suse.de> Link: http://marc.info/?l=linux-raid&m=135982797322422 Fixes: 9dedf603 Cc: stable@vger.kernel.org (3.6+)
-
- 24 Feb, 2015 10 commits
-
-
Chanwoo Choi authored
This patch cleanup the code to use oneline for entry of exynos compatible table. Cc: Zhang Rui <rui.zhang@intel.com> Cc: Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Acked-by:
Lukasz Majewski <l.majewski@samsung.com> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com>
-
Geert Uytterhoeven authored
Swap interrupt disable and thermal zone unregistration in the error and remove paths, to make them more symmetrical with the initialization path. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com>
-
Geert Uytterhoeven authored
As soon as the interrupt has been enabled by devm_request_irq(), the interrupt routine may be called, depending on the current status of the hardware. However, at that point rcar_thermal_common hasn't been initialized complely yet. E.g. rcar_thermal_common.base is still NULL, causing a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000c pgd = c0004000 [0000000c] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.19.0-rc7-ape6evm-04564-gb6e46cb7cbe82389 #30 Hardware name: Generic R8A73A4 (Flattened Device Tree) task: ee8953c0 ti: ee896000 task.ti: ee896000 PC is at rcar_thermal_irq+0x1c/0xf0 LR is at _raw_spin_lock_irqsave+0x48/0x54 Postpone the call to devm_request_irq() until all initialization has been done to fix this. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com>
-
Markus Elfring authored
The cpufreq_cooling_unregister() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com>
-
Grygorii Strashko authored
Fix following build warning if CONFIG_PM_SLEEP is not set: drivers/thermal/ti-soc-thermal/ti-bandgap.c:1478:12: warning: 'ti_bandgap_suspend' defined but not used [-Wunused-function] static int ti_bandgap_suspend(struct device *dev) ^ drivers/thermal/ti-soc-thermal/ti-bandgap.c:1492:12: warning: 'ti_bandgap_resume' defined but not used [-Wunused-function] static int ti_bandgap_resume(struct device *dev) ^ Acked-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Grygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com>
-
Daniel Vetter authored
Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: stable@vger.kernel.org Cc: Johannes W <jargon@molb.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by:
Johannes W <jargon@molb.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Imre Deak authored
Atm, it's possible that the interrupt handler is called when the device is in D3 or some other low-power state. It can be due to another device that is still in D0 state and shares the interrupt line with i915, or on some platforms there could be spurious interrupts even without sharing the interrupt line. The latter case was reported by Klaus Ethgen using a Lenovo x61p machine (gen 4). He noticed this issue via a system suspend/resume hang and bisected it to the following commit: commit e11aa362 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jun 18 09:52:55 2014 -0700 drm/i915: use runtime irq suspend/resume in freeze/thaw This is a problem, since in low-power states IIR will always read 0xffffffff resulting in an endless IRQ servicing loop. Fix this by handling interrupts only when the driver explicitly enables them and so it's guaranteed that the interrupt registers return a valid value. Note that this issue existed even before the above commit, since during runtime suspend/resume we never unregistered the handler. v2: - clarify the purpose of smp_mb() vs. synchronize_irq() in the code comment (Chris) v3: - no need for an explicit smp_mb(), we can assume that synchronize_irq() and the mmio read/writes in the install hooks provide for this (Daniel) - remove code comment as the remaining synchronize_irq() is self explanatory (Daniel) v4: - drm_irq_uninstall() implies synchronize_irq(), so no need to call it explicitly (Daniel) Reference: https://lkml.org/lkml/2015/2/11/205 Reported-and-bisected-by:
Klaus Ethgen <Klaus@Ethgen.ch> Cc: stable@vger.kernel.org Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Chris Wilson authored
When we walk the list of vma, or even for protecting against concurrent framebuffer creation, we must hold the struct_mutex or else a second thread can corrupt the list as we walk it. Fixes regression from commit d7f46fc4 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA References: https://bugs.freedesktop.org/show_bug.cgi?id=89085 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Nick Hoath authored
When converting from implicitly tracked execlist queue items to ref counted requests, not all frees of requests were replaced with unrefs, and extraneous refs/unrefs of contexts were added. Correct the unbalanced refcount & replace the frees. Remove a noisy warning when hitting the request creation path. drm_i915_gem_request and intel_context are both kref reference counted structures. Upon allocation, drm_i915_gem_request's ref count should be bumped using kref_init. When a context is assigned to the request, the context's reference count should be bumped using i915_gem_context_reference. i915_gem_request_reference will reduce the context reference count when the request is freed. Problem introduced in commit 6d3d8274 Author: Nick Hoath <nicholas.hoath@intel.com> AuthorDate: Thu Jan 15 13:10:39 2015 +0000 drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request v2: Added comments explaining how the ctx pointer and the request object should be ref-counted. Removed noisy warning. v3: Cleaned up the language used in the commit & the header description (Thanks David Gordon) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88652 Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
Thomas Daniel <thomas.daniel@intel.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Boris Brezillon authored
Remove a useless pm_runtime_put_sync leading to unbalanced usage_count. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by:
Sylvain Rochet <sylvain.rochet@finsecur.com>
-