- 23 3月, 2015 1 次提交
-
-
由 Keith Busch 提交于
Driver recovery requires the device's list node to have been initialized. Fixes: https://lkml.org/lkml/2015/3/22/262Reported-by: NSteven Noonan <steven@uplinklabs.net> Signed-off-by: NKeith Busch <keith.busch@intel.com> Cc: Matthew Wilcox <willy@linux.intel.com> Cc: Jens Axboe <axboe@fb.com> Signed-off-by: NJens Axboe <axboe@fb.com>
-
- 05 3月, 2015 1 次提交
-
-
由 Sudip Mukherjee 提交于
we have already allocated memory for nbd_dev, but we were not releasing that memory and just returning the error value. Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org> Acked-by: NPaul Clements <Paul.Clements@SteelEye.com> Cc: <stable@vger.kernel.org> Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
-
- 04 3月, 2015 1 次提交
-
-
由 Daniel Vetter 提交于
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: NLinus Torvalds <torvalds@linux-foundation.org> Reported-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 01 3月, 2015 4 次提交
-
-
由 Joonsoo Kim 提交于
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: NJoonsoo 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: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Joshua Kinard 提交于
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: NJoshua Kinard <kumba@gentoo.org> Reported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Geert Uytterhoeven 提交于
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: NGeert Uytterhoeven <geert@linux-m68k.org> Acked-by: NJoshua Kinard <kumba@gentoo.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Arnd Bergmann 提交于
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: NArnd Bergmann <arnd@arndb.de> Acked-by: NJoshua Kinard <kumba@gentoo.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 28 2月, 2015 2 次提交
-
-
由 Srinivas Pandruvada 提交于
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: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Miguel Bernal Marin 提交于
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: NJose Navarro <jose.navarro@intel.com> Suggested-by: NJacob Pan <jacob.jun.pan@linux.intel.com> Tested-by: NJose Carlos Venegas Munoz <jos.c.venegas.munoz@intel.com> Signed-off-by: NMiguel Bernal Marin <miguel.bernal.marin@linux.intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 26 2月, 2015 11 次提交
-
-
由 Nicolas Ferre 提交于
Remove this configuration bit in crtc driver as the rising edge clock is widely used. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
由 Alex Deucher 提交于
We were enabling DP secondary streams even if the monitor didn't support them. Fixes display problems on some DP monitors. Tested-by: NJim Boz <jim876@xs4all.nl> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
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: NMichel Dänzer <michel.daenzer@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
The logic was reversed from what the hw actually exposed. Fixes graphics corruption in certain harvest configurations. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Christian König 提交于
Signed-off-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> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Leo Liu 提交于
v2: disable it on suspend Signed-off-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
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=89148Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
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=89198Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Just in case it hasn't been calculated for the mode. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Nathan-J. Hirschauer 提交于
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: NNathan-J. Hirschauer <nathanhi@deepserve.info> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 25 2月, 2015 12 次提交
-
-
由 Robert Jarzmik 提交于
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: NRobert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
-
由 Matthias Brugger 提交于
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: NGongbae Park <yongbae2@gmail.com> Signed-off-by: NMatthias Brugger <matthias.bgg@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
-
由 Daniel Lezcano 提交于
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: NDaniel Lezcano <daniel.lezcano@linaro.org> Acked-by: NGuenter Roeck <linux@roeck-us.net> Acked-by: NOleksij Rempel <linux@rempel-privat.de> Conflicts: drivers/clocksource/Kconfig
-
由 Rodrigo Vivi 提交于
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: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 NeilBrown 提交于
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: NNeilBrown <neilb@suse.de>
-
由 Eric Mei 提交于
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: NNeilBrown <neilb@suse.de>
-
由 Tomáš Hodek 提交于
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: NTomáš Hodek <tomas.hodek@volny.cz> Reported-by: NDark Penguin <darkpenguin@yandex.ru> Signed-off-by: NNeilBrown <neilb@suse.de> Link: http://marc.info/?l=linux-raid&m=135982797322422 Fixes: 9dedf603 Cc: stable@vger.kernel.org (3.6+)
-
由 Chanwoo Choi 提交于
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: NChanwoo Choi <cw00.choi@samsung.com> Acked-by: NLukasz Majewski <l.majewski@samsung.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Geert Uytterhoeven 提交于
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: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Geert Uytterhoeven 提交于
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: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Markus Elfring 提交于
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: NMarkus Elfring <elfring@users.sourceforge.net> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
由 Grygorii Strashko 提交于
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: NNishanth Menon <nm@ti.com> Signed-off-by: NGrygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
-
- 24 2月, 2015 8 次提交
-
-
由 Daniel Vetter 提交于
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: NJohannes W <jargon@molb.org> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Imre Deak 提交于
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/205Reported-and-bisected-by: NKlaus Ethgen <Klaus@Ethgen.ch> Cc: stable@vger.kernel.org Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Chris Wilson 提交于
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=89085Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Nick Hoath 提交于
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=88652Signed-off-by: NNick Hoath <nicholas.hoath@intel.com> Reviewed-by: NThomas Daniel <thomas.daniel@intel.com> Reviewed-by: NDaniel Vetter <daniel@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Boris Brezillon 提交于
Remove a useless pm_runtime_put_sync leading to unbalanced usage_count. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com> Reported-by: NSylvain Rochet <sylvain.rochet@finsecur.com>
-
由 Boris Brezillon 提交于
The A2Q (Add To Queue) and UPDATE bits are left in their previous state when resetting the layer. This lead to weird behavior when enabling the plane again: the framebuffer previously queued is dequeued and we end up with access to an old memory region. Reset those bits when resetting the channel. Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
-
由 Daniel Vetter 提交于
In commit ccfc0865 Author: Rob Clark <robdclark@gmail.com> Date: Thu Dec 18 16:01:48 2014 -0500 drm: tweak getconnector locking We need to extend the locking to cover connector->state reading for atomic drivers, but the above commit was a bit too eager and also included the fill_modes callback. Which on i915 on old platforms using load detection needs to acquire modeset locks, resulting in a deadlock on output probing. Reported-by: NMarc Finet <m.dreadlock@gmail.com> Cc: Marc Finet <m.dreadlock@gmail.com> Cc: robdclark@gmail.com Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NRob Clark <robdclark@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Geert Uytterhoeven 提交于
If the default PM domain using PM_CLK is used for PM runtime, the real PM domain(s) cannot be registered from DT later. Hence do not enable it when running a multi-platform kernel with genpd support on an r8a7740. The R-Mobile PM domain driver will take care of PM runtime management of the module clocks. The default PM domain is still needed for: - platforms without genpd support, - the legacy (non-DT) case, where genpd may take over later, except for the C5 "always on" PM domain. Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
-