- 22 4月, 2016 5 次提交
-
-
由 Sonny Jiang 提交于
Was previously always hardcoded to 0. Signed-off-by: NSonny Jiang <sonny.jiang@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Jérôme Glisse 提交于
Allowing userptr bo which are basicly a list of page from some vma (so either anonymous page or file backed page) would lead to serious corruption of kernel structures and counters (because we overwrite the page->mapping field when mapping buffer). This will already block if the buffer was populated before anyone does try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm vm fault handler. So to be safe just add a check to verify_access() callback. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NJérôme Glisse <jglisse@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Jérôme Glisse 提交于
Allowing userptr bo which are basicly a list of page from some vma (so either anonymous page or file backed page) would lead to serious corruption of kernel structures and counters (because we overwrite the page->mapping field when mapping buffer). This will already block if the buffer was populated before anyone does try to mmap it because then TTM_PAGE_FLAG_SG would be set in in the ttm_tt flags. But that flag is check before ttm_tt_populate in the ttm vm fault handler. So to be safe just add a check to verify_access() callback. Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NJérôme Glisse <jglisse@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
Fixes array overflow on these chips. Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Prerequiste for the next patch which ups the limits. Reviewed-by: NHarry Wentland <harry.wentland@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
- 18 4月, 2016 5 次提交
-
-
由 Alex Deucher 提交于
It will help identify problematic boards. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
This reverts commit e64c952e. ATPX is the ACPI method for controlling AMD PowerXpress laptops. There are flags to indicate which methods are supported. If the dGPU power down flag is not supported, the driver needs to implement the dGPU power down manually. We had previously always forced the driver to assume the ATPX dGPU power down was present, but this causes problems on boards where it is not, leading to GPU hangs when attempting to power down the dGPU. Manual dGPU power down is not currently supported in the Linux driver. Some laptops indicate that the ATPX dGPU power down method is not present, but it actually apparently is. I'm not sure if this is a bios bug and it should be set or if there is a reason it was unset and the method should not be used. This is not an issue on other OSes since both the ATPX and the manual driver power down methods are supported. This is apparently fairly widespread, so just revert for now. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=115321 https://bugzilla.kernel.org/show_bug.cgi?id=116581 https://bugzilla.kernel.org/show_bug.cgi?id=116251 Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
Nothing to do on resume on systems with AZ audio. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Alex Deucher 提交于
bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
The pci revision id is useful in debugging certain things as it's part of how SKUs are defined on newer asics. Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 14 4月, 2016 2 次提交
-
-
由 Rex Zhu 提交于
fix the issue that when resume back, uvd/vce dpm was disabled and uvd/vce's performace dropped. Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
-
由 Alex Deucher 提交于
This got lost somewhere along the way. This fixes audio not working until set_property was called. Noticed-by: NHyungwon Hwang <hyungwon.hwang7@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 12 4月, 2016 7 次提交
-
-
由 Javier Martinez Canillas 提交于
Commit 254d4d11 ("drm/exynos: Add dependency for G2D in Kconfig") made the DRM_EXYNOS_G2D symbol to only be selectable if the s5p-g2d V4L2 driver is not enabled, since both use the same HW IP block. But added the dependency as depends on !VIDEO_SAMSUNG_S5P_G2D which isn't correct since Kconfig expressions are not boolean but tristate. So it will only evaluate to 'n' if VIDEO_SAMSUNG_S5P_G2D=y but it will evaluate to m if VIDEO_SAMSUNG_S5P_G2D=m. This means that both the V4L2 and DRM drivers can be enabled if the former is enabled as a module, which is not what we want. Signed-off-by: NJavier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Dan Carpenter 提交于
The "ret = regmap_write()" assignment was missing so this error message is never printed. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Dan Carpenter 提交于
We accidentally return success instead of a negative error code here. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Marek Szyprowski 提交于
Commit 1feafd3a ("drm/exynos: add exynos5420 support for fimd") add support for Exynos 5420 SoC, but it broke enabling display clock feature because of incorrect condition check. This patch fixes it, so display is working again on platforms requiring display clock control (i.e. Exynos5250-based SNOW platform). Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Andrzej Hajda 提交于
Fbdev code should be compiled only if CONFIG_DRM_FBDEV_EMULATION option is enabled. The patch fixes exynos-drm code trying to manipulate fbdev data which is not initialized in case CONFIG_DRM_FBDEV_EMULATION is disabled. Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Andrzej Hajda 提交于
exynos_plane_mode_set should use adjusted_mode from the same atomic state as plane state. Otherwise it will result in incorrect behavior in case crtc mode changes. The patch fixes bug with black console framebuffer in case of command mode panels. Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
由 Arnd Bergmann 提交于
gcc-6 warns about a pointless loop in exynos_drm_subdrv_open: drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open': drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always evaluates to false [-Werror=tautological-compare] list_for_each_entry_reverse(subdrv, &subdrv->list, list) { Here, the list_for_each_entry_reverse immediately terminates because the subdrv pointer is compared to itself as the loop end condition. If we were to take the current subdrv pointer as the start of the list (as we would do if list_for_each_entry_reverse() was not a macro), we would iterate backwards over the &exynos_drm_subdrv_list anchor, which would be even worse. Instead, we need to use list_for_each_entry_continue_reverse() to go back over each subdrv that was successfully opened until the first entry. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NInki Dae <inki.dae@samsung.com>
-
- 07 4月, 2016 5 次提交
-
-
由 Junwei Zhang 提交于
Signed-off-by: NJunwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Bjørn Mork 提交于
commit e2c8b870 moved modeset locking inside resume/suspend functions, but missed a code path only executed on lid close/open on older hardware. The result was a deadlock when closing and opening the lid without suspending on such hardware: ============================================= [ INFO: possible recursive locking detected ] 4.6.0-rc1 #385 Not tainted --------------------------------------------- kworker/0:3/88 is trying to acquire lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] but task is already holding lock: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&dev->mode_config.mutex); lock(&dev->mode_config.mutex); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by kworker/0:3/88: #0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b #2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65 #3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915] #4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm] #5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm] #6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm] stack backtrace: CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385 Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 Workqueue: kacpi_notify acpi_os_execute_deferred 0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0 ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70 000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0 Call Trace: [<ffffffff8124af06>] dump_stack+0x67/0x90 [<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71 [<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a [<ffffffff8108fae2>] lock_acquire+0x137/0x1cb [<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4 [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915] [<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm] [<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm] [<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm] [<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915] [<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c [<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65 [<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16 [<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button] [<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button] [<ffffffff812b07df>] acpi_device_notify+0x19/0x1b [<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64 [<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20 [<ffffffff81068f17>] process_one_work+0x265/0x50b [<ffffffff810696f5>] worker_thread+0x1fc/0x2dd [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff810694f9>] ? rescuer_thread+0x309/0x309 [<ffffffff8106e2d6>] kthread+0xe0/0xe8 [<ffffffff8107bc47>] ? local_clock+0x19/0x22 [<ffffffff81484f42>] ret_from_fork+0x22/0x40 [<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5 Fixes: e2c8b870 ("drm/i915: Use atomic helpers for suspend, v2.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NBjørn Mork <bjorn@mork.no> Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no (cherry picked from commit 9f54d4bd) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Dave Airlie 提交于
I noticed my monitor didn't power off when it should, this should fix it. Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Dave Airlie 提交于
This ports the DAL timeouts and MST rate calculations for the hw from the DAL codebase. Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
- 06 4月, 2016 2 次提交
-
-
由 Alexandre Courbot 提交于
GM20B requires an extra clock compared to GK20A. Add that information into the platform data and acquire and enable this clock if necessary. Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
-
由 Chunming Zhou 提交于
Signed-off-by: NChunming Zhou <David1.Zhou@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com>
-
- 05 4月, 2016 12 次提交
-
-
由 Paul Parsons 提交于
One of the VESA DMT timings in drm_dmt_modes[] is slightly off. 1024x768@43Hz (interlaced) vsync_end should be 776, not 772. This brings it into line with the identical timings in edid_est_modes[]. Signed-off-by: NPaul Parsons <lost.distance@yahoo.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160404193639.8631D6E66B@gabe.freedesktop.org
-
由 Chris Wilson 提交于
This effectively reverts commit 8e5fd599 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Apr 9 13:28:50 2014 +0300 drm/i915/chv: Make CHV irq handler loop until all interrupts are consumed as under continuous execlists load we can saturate the IRQ handler, destablising the tsc clock and triggering the NMI watchdog to declare a hung CPU. [ 552.756051] clocksource: timekeeping watchdog on CPU0: Marking clocksource 'tsc' as unstable because the skew is too large: [ 552.756080] clocksource: 'refined-jiffies' wd_now: 10003b480 wd_last: 10003b28c mask: ffffffff [ 552.756091] clocksource: 'tsc' cs_now: d55d31aa50 cs_last: d17446166c mask: ffffffffffffffff [ 552.756210] clocksource: Switched to clocksource refined-jiffies [ 575.217870] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1 [ 575.217893] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.5.0-rc7+ #18 [ 575.217905] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 575.217915] 0000000000000000 ffff88027fd05bc0 ffffffff81288c6d 0000000000000000 [ 575.217935] 0000000000000001 ffff88027fd05be0 ffffffff810e72d1 0000000000000000 [ 575.217951] ffff88027fd05c80 ffff88027fd05c20 ffffffff81114b60 0000000181015f1e [ 575.217967] Call Trace: [ 575.217973] <NMI> [<ffffffff81288c6d>] dump_stack+0x4f/0x72 [ 575.217994] [<ffffffff810e72d1>] watchdog_overflow_callback+0x151/0x160 [ 575.218003] [<ffffffff81114b60>] __perf_event_overflow+0xa0/0x1e0 [ 575.218016] [<ffffffff811154c4>] perf_event_overflow+0x14/0x20 [ 575.218028] [<ffffffff8101d2ca>] intel_pmu_handle_irq+0x1da/0x460 [ 575.218042] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218052] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218064] [<ffffffff81014ae8>] perf_event_nmi_handler+0x28/0x50 [ 575.218075] [<ffffffff81007540>] nmi_handle+0x60/0x130 [ 575.218086] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218096] [<ffffffff810079c0>] do_nmi+0x140/0x470 [ 575.218108] [<ffffffff81559ec7>] end_repeat_nmi+0x1a/0x1e [ 575.218119] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218129] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218139] [<ffffffff814a8aae>] ? poll_idle+0x3e/0x70 [ 575.218148] <<EOE>> [<ffffffff814a8353>] cpuidle_enter_state+0xf3/0x2f0 [ 575.218164] [<ffffffff814a8587>] cpuidle_enter+0x17/0x20 [ 575.218175] [<ffffffff810aaa3a>] call_cpuidle+0x2a/0x40 [ 575.218185] [<ffffffff810aade3>] cpu_startup_entry+0x273/0x330 [ 575.218196] [<ffffffff81033a1e>] start_secondary+0x10e/0x130 However, not servicing all available IIR within the handler does hurt the throughput of pathological nop execbuf by about 20%, with a similar effect upon the dispatch latency of a series of execbuf. v2: use do {} while(0) for a smaller patch, and easier to revert again I have reasonable confidence that we do not miss GT interrupts (as execlists provides a stress case with a failure mechanism easily detected by igt), however I have less confidence about all the other sources of interrupts and worry that may lose a display hotplug interrupt, for example. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93467 Testcase: igt/gem_exec_nop/basic # requires NMI watchdog Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Antti Koskipää <antti.koskipaa@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457946117-6714-1-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 579de73b) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Lyude 提交于
Since we need MST devices ready before we try to resume displays, calling this after intel_display_resume() can result in some issues with various laptop docks where the monitor won't turn back on after suspending the system. This order was originally changed in commit e7d6f7d7 ("drm/i915: resume MST after reading back hw state") In order to fix some unclaimed register errors, however the actual cause of those has since been fixed. CC: stable@vger.kernel.org Signed-off-by: NLyude <cpaul@redhat.com> [danvet: Resolve conflicts with locking changes.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit a16b7658) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Lyude 提交于
After unplugging a DP MST display from the system, we have to go through and destroy all of the DRM connectors associated with it since none of them are valid anymore. Unfortunately, intel_dp_destroy_mst_connector() doesn't do a good enough job of ensuring that throughout the destruction process that no modesettings can be done with the connectors. As it is right now, intel_dp_destroy_mst_connector() works like this: * Take all modeset locks * Clear the configuration of the crtc on the connector, if there is one * Drop all modeset locks, this is required because of circular dependency issues that arise with trying to remove the connector from sysfs with modeset locks held * Unregister the connector * Take all modeset locks, again * Do the rest of the required cleaning for destroying the connector * Finally drop all modeset locks for good This only works sometimes. During the destruction process, it's very possible that a userspace application will attempt to do a modesetting using the connector. When we drop the modeset locks, an ioctl handler such as drm_mode_setcrtc has the oppurtunity to take all of the modeset locks from us. When this happens, one thing leads to another and eventually we end up committing a mode with the non-existent connector: [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* failed to enable link training [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f [drm:intel_dp_start_link_train [i915]] *ERROR* failed to start channel equalization [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7cf0001f [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi And in some cases, such as with the T460s using an MST dock, this results in breaking modesetting and/or panicking the system. To work around this, we now unregister the connector at the very beginning of intel_dp_destroy_mst_connector(), grab all the modesetting locks, and then hold them until we finish the rest of the function. CC: stable@vger.kernel.org Signed-off-by: NLyude <cpaul@redhat.com> Signed-off-by: NRob Clark <rclark@redhat.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1458155884-13877-1-git-send-email-cpaul@redhat.com (cherry picked from commit 1f771755) Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Paul Parsons 提交于
The EDID 1.4 specification section 3.10.3.9 defines an Established Timings III descriptor (tag #F7h). The parsing of this descriptor by drm_est3_modes() is off by one byte: the offset of the first timing bitmap is 6, not 5. Signed-off-by: NPaul Parsons <lost.distance@yahoo.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160328002258.E75DF6E35D@gabe.freedesktop.org
-
由 Paul Parsons 提交于
Three of the VESA DMT timings in edid_est_modes[] are slightly off. 1. 640x480@72Hz vsync_end should be 492, not 491. 2. 640x480@60Hz clock should be 25175, not 25200. 3. 1024x768@75Hz clock should be 78750, not 78800. This patch corrects those timings per the VESA DMT specification, and thus brings them into line with the identical timings in drm_dmt_modes[]. Signed-off-by: NPaul Parsons <lost.distance@yahoo.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160402100817.B60776E23A@gabe.freedesktop.org
-
由 Rex Zhu 提交于
These should be set by default otherwise the UVD/VCE performance won't be optimal. Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Rex Zhu 提交于
Signed-off-by: NRex Zhu <Rex.Zhu@amd.com> Reviewed-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Leo Liu 提交于
Signed-off-by: NLeo Liu <leo.liu@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Leo Liu 提交于
and revert fix following it accordingly Revert "drm/amdgpu: stop trying to suspend UVD sessions v2" Revert "drm/amdgpu: fix the UVD suspend sequence order" Signed-off-by: NLeo Liu <leo.liu@amd.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
-
由 Linus Torvalds 提交于
In commit e4570897 ("drm/dp-helper: Move the legacy helpers to gma500") the legacy i2c helpers were moved to the only remaining user of them, the gma500 driver. Together with that move, i2c_dp_aux_add_bus() was marked deprecated and started warning about its remaining use. It's now been a year and a half of annoying warning, and apparently nobody cares enough about gma500 to try to move it along to the more modern models. Get rid of the warning - if even the gma500 people don't care enough, then they should certainly not spam other innocent developers with a warning that might hide other, much more real issues. Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Alan Cox <alan@linux.intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Kirill A. Shutemov 提交于
PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time ago with promise that one day it will be possible to implement page cache with bigger chunks than PAGE_SIZE. This promise never materialized. And unlikely will. We have many places where PAGE_CACHE_SIZE assumed to be equal to PAGE_SIZE. And it's constant source of confusion on whether PAGE_CACHE_* or PAGE_* constant should be used in a particular case, especially on the border between fs and mm. Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much breakage to be doable. Let's stop pretending that pages in page cache are special. They are not. The changes are pretty straight-forward: - <foo> << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - <foo> >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> <foo>; - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN}; - page_cache_get() -> get_page(); - page_cache_release() -> put_page(); This patch contains automated changes generated with coccinelle using script below. For some reason, coccinelle doesn't patch header files. I've called spatch for them manually. The only adjustment after coccinelle is revert of changes to PAGE_CAHCE_ALIGN definition: we are going to drop it later. There are few places in the code where coccinelle didn't reach. I'll fix them manually in a separate patch. Comments and documentation also will be addressed with the separate patch. virtual patch @@ expression E; @@ - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT) + E @@ expression E; @@ - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) + E @@ @@ - PAGE_CACHE_SHIFT + PAGE_SHIFT @@ @@ - PAGE_CACHE_SIZE + PAGE_SIZE @@ @@ - PAGE_CACHE_MASK + PAGE_MASK @@ expression E; @@ - PAGE_CACHE_ALIGN(E) + PAGE_ALIGN(E) @@ expression E; @@ - page_cache_get(E) + get_page(E) @@ expression E; @@ - page_cache_release(E) + put_page(E) Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: NMichal Hocko <mhocko@suse.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 04 4月, 2016 2 次提交
-
-
由 Dan Carpenter 提交于
We accidentally return PTR_ERR(NULL) which is success instead of a negative error code. Fixes: 879e40bea6f2 ('drm: ARM HDLCD - get rid of devm_clk_put()') Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
-
由 Alexey Brodkin 提交于
Clock is acquired with devm_clk_get() which already manages corresponding resource. I.e. in case of driver removal or failure on installaiton clock resources will be automatically released and explicit call of devm_clk_put() is not required. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com> Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
-