summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2016-04-05drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume timeYakir Yang
Turn off the panel power in suspend time would help to reduce power waste. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: add edid modes parse in get_modes methodYakir Yang
Display Port monitor could support kinds of mode which indicate in monitor edid, not just one single display resolution which defined in panel or devivetree property display timing. Note: Gustavo Padovan try to remove the controller and phy power on function in bind time at bellow commit: drm/exynos: do not start enabling DP at bind() phase But for now driver need to read edid message in .get_modes() function, so controller must be inited in bind time, so we need to add controller init back. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: move hpd detect to connector detect functionYakir Yang
This change just make a little clean to make code more like drm core expect, move hdp detect code from bridge->enable(), and place them into connector->detect(). Note: Gustavo Padovan try to remove the controller and phy power on function in bind time at bellow commit: drm/exynos: do not start enabling DP at bind() phase But for now the connector status don't hardcode to connected, need to operate dp phy in .detect function, so we need to revert parts if Gustavo Padovan's changes, add phy poweron function in bind time. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: try force hpd after plug in lookup failedYakir Yang
Some edp screen do not have hpd signal, so we can't just return failed when hpd plug in detect failed. This is an hardware property, so we need add a devicetree property "analogix,need-force-hpd" to indicate this sutiation. Acked-by: Rob Herring <robh@kernel.org> Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288Yakir Yang
There are some IP limit on rk3288 that only support 4 physical lanes of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: add some rk3288 special registers settingYakir Yang
RK3288 need some special registers setting, we can separate them out by the dev_type of plat_data. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: rockchip: dp: add rockchip platform dp driverYakir Yang
Rockchip have three clocks for dp controller, we leave pclk_edp to analogix_dp driver control, and keep the sclk_edp_24m and sclk_edp in platform driver. Acked-by: Mark Yao <mark.yao@rock-chips.com> Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-04-05drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_rangeYakir Yang
Both hsync/vsync polarity and interlace mode can be parsed from drm display mode, and dynamic_range and ycbcr_coeff can be judge by the video code. But presumably Exynos still relies on the DT properties, so take good use of mode_fixup() in to achieve the compatibility hacks. Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: remove duplicate configuration of link rate and ↵Yakir Yang
link count link_rate and lane_count already configured in analogix_dp_set_link_train(), so we don't need to config those repeatly after training finished, just remove them out. Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: fix some obvious code styleYakir Yang
Fix some obvious alignment problems, like alignment and line over 80 characters problems, make this easy to be maintained later. Acked-by: Jingoo Han <jingoohan1@gmail.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: rename register constantsHeiko Stuebner
In the original split we kept the register constants intact to keep the diff small. Still the constants are Analogix-specific, so rename them now. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm/exynos: dp: rename implementation specific driver partHeiko Stuebner
The core functionality now resides in the generic bridge part so the exynos-specific implementation details can get a more suitable nameing. Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
2016-04-05drm: bridge: analogix/dp: split exynos dp driver to bridge directoryYakir Yang
Split the dp core driver from exynos directory to bridge directory, and rename the core driver to analogix_dp_*, rename the platform code to exynos_dp. Beside the new analogix_dp driver would export six hooks. "analogix_dp_bind()" and "analogix_dp_unbind()" "analogix_dp_suspned()" and "analogix_dp_resume()" "analogix_dp_detect()" and "analogix_dp_get_modes()" The bind/unbind symbols is used for analogix platform driver to connect with analogix_dp core driver. And the detect/get_modes is used for analogix platform driver to init the connector. They reason why connector need register in helper driver is rockchip drm haven't implement the atomic API, but Exynos drm have implement it, so there would need two different connector helper functions, that's why we leave the connector register in helper driver. Acked-by: Inki Dae <inki.dae@samsung.com> Tested-by: Caesar Wang <wxt@rock-chips.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2016-04-04drm/amd/powerplay: add uvd/vce dpm enabling flag default.Rex Zhu
These should be set by default otherwise the UVD/VCE performance won't be optimal. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-04drm/amd/powerplay: fix issue that resume back, dpm can't work on FIJI.Rex Zhu
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-04drm/amdgpu: save and restore the firwmware cache part when suspend resumeLeo Liu
Signed-off-by: Leo Liu <leo.liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-04drm/amdgpu: save and restore UVD context with suspend and resumeLeo 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: Leo Liu <leo.liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-04gma500: remove annoying deprecation warningLinus Torvalds
In commit e45708976aea ("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: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-04Merge branch 'PAGE_CACHE_SIZE-removal'Linus Torvalds
Merge PAGE_CACHE_SIZE removal patches from Kirill 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. Let's stop pretending that pages in page cache are special. They are not. The first patch with most changes has been done with coccinelle. The second is manual fixups on top. The third patch removes macros definition" [ I was planning to apply this just before rc2, but then I spaced out, so here it is right _after_ rc2 instead. As Kirill suggested as a possibility, I could have decided to only merge the first two patches, and leave the old interfaces for compatibility, but I'd rather get it all done and any out-of-tree modules and patches can trivially do the converstion while still also working with older kernels, so there is little reason to try to maintain the redundant legacy model. - Linus ] * PAGE_CACHE_SIZE-removal: mm: drop PAGE_CACHE_* and page_cache_{get,release} definition mm, fs: remove remaining PAGE_CACHE_* and page_cache_{get,release} usage mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macros
2016-04-04mm, fs: get rid of PAGE_CACHE_* and page_cache_{get,release} macrosKirill 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: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Acked-by: Michal Hocko <mhocko@suse.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-04-04drm/i915: Move execlists irq handler to a bottom halfTvrtko Ursulin
Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole system can be brought into multi-second periods of complete non-interactivty. That can look for example like this: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] Modules linked in: [redacted for brevity] CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ #183 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1 Workqueue: i915 gen6_pm_rps_work [i915] task: ffff8800aae88000 ti: ffff8800aae90000 task.ti: ffff8800aae90000 RIP: 0010:[<ffffffff8104a3c2>] [<ffffffff8104a3c2>] __do_softirq+0x72/0x1d0 RSP: 0000:ffff88014f403f38 EFLAGS: 00000206 RAX: ffff8800aae94000 RBX: 0000000000000000 RCX: 00000000000006e0 RDX: 0000000000000020 RSI: 0000000004208060 RDI: 0000000000215d80 RBP: ffff88014f403f80 R08: 0000000b1b42c180 R09: 0000000000000022 R10: 0000000000000004 R11: 00000000ffffffff R12: 000000000000a030 R13: 0000000000000082 R14: ffff8800aa4d0080 R15: 0000000000000082 FS: 0000000000000000(0000) GS:ffff88014f400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa53b90c000 CR3: 0000000001a0a000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: 042080601b33869f ffff8800aae94000 00000000fffc2678 ffff88010000000a 0000000000000000 000000000000a030 0000000000005302 ffff8800aa4d0080 0000000000000206 ffff88014f403f90 ffffffff8104a716 ffff88014f403fa8 Call Trace: <IRQ> [<ffffffff8104a716>] irq_exit+0x86/0x90 [<ffffffff81031e7d>] smp_apic_timer_interrupt+0x3d/0x50 [<ffffffff814f3eac>] apic_timer_interrupt+0x7c/0x90 <EOI> [<ffffffffa01c5b40>] ? gen8_write64+0x1a0/0x1a0 [i915] [<ffffffff814f2b39>] ? _raw_spin_unlock_irqrestore+0x9/0x20 [<ffffffffa01c5c44>] gen8_write32+0x104/0x1a0 [i915] [<ffffffff8132c6a2>] ? n_tty_receive_buf_common+0x372/0xae0 [<ffffffffa017cc9e>] gen6_set_rps_thresholds+0x1be/0x330 [i915] [<ffffffffa017eaf0>] gen6_set_rps+0x70/0x200 [i915] [<ffffffffa0185375>] intel_set_rps+0x25/0x30 [i915] [<ffffffffa01768fd>] gen6_pm_rps_work+0x10d/0x2e0 [i915] [<ffffffff81063852>] ? finish_task_switch+0x72/0x1c0 [<ffffffff8105ab29>] process_one_work+0x139/0x350 [<ffffffff8105b186>] worker_thread+0x126/0x490 [<ffffffff8105b060>] ? rescuer_thread+0x320/0x320 [<ffffffff8105fa64>] kthread+0xc4/0xe0 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 [<ffffffff814f351f>] ret_from_fork+0x3f/0x70 [<ffffffff8105f9a0>] ? kthread_create_on_node+0x170/0x170 I could not explain, or find a code path, which would explain a +20 second lockup, but from some instrumentation it was apparent the interrupts off proportion of time was between 10-25% under heavy load which is quite bad. When a interrupt "cliff" is reached, which was >~320k irq/s on my machine, the whole system goes into a terrible state of the above described multi-second lockups. By moving the GT interrupt handling to a tasklet in a most simple way, the problem above disappears completely. Testing the effect on sytem-wide latencies using igt/gem_syslatency shows the following before this patch: gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us This shows that the unrelated process is experiencing huge delays in its wake-up latency. After the patch the results look like this: gem_syslatency: cycles=808907, latency mean=53.133us max=1640us gem_syslatency: cycles=862154, latency mean=62.778us max=2117us gem_syslatency: cycles=856039, latency mean=58.079us max=2123us gem_syslatency: cycles=841683, latency mean=56.914us max=1667us Showing a huge improvement in the unrelated process wake-up latency. It also shows an approximate halving in the number of total empty batches submitted during the test. This may not be worrying since the test puts the driver under a very unrealistic load with ncpu threads doing empty batch submission to all GPU engines each. Another benefit compared to the hard-irq handling is that now work on all engines can be dispatched in parallel since we can have up to number of CPUs active tasklets. (While previously a single hard-irq would serially dispatch on one engine after another.) More interesting scenario with regards to throughput is "gem_latency -n 100" which shows 25% better throughput and CPU usage, and 14% better dispatch latencies. I did not find any gains or regressions with Synmark2 or GLbench under light testing. More benchmarking is certainly required. v2: * execlists_lock should be taken as spin_lock_bh when queuing work from userspace now. (Chris Wilson) * uncore.lock must be taken with spin_lock_irq when submitting requests since that now runs from either softirq or process context. v3: * Expanded commit message with more testing data; * converted missed locking sites to _bh; * added execlist_lock comment. (Chris Wilson) v4: * Mention dispatch parallelism in commit. (Chris Wilson) * Do not hold uncore.lock over MMIO reads since the block is already serialised per-engine via the tasklet itself. (Chris Wilson) * intel_lrc_irq_handler should be static. (Chris Wilson) * Cancel/sync the tasklet on GPU reset. (Chris Wilson) * Document and WARN that tasklet cannot be active/pending on engine cleanup. (Chris Wilson/Imre Deak) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Testcase: igt/gem_exec_nop/all Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1459768316-6670-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-04drm: ARM HDLCD - fix an error codeDan 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: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
2016-04-04drm: ARM HDLCD - get rid of devm_clk_put()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: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
2016-04-04drm/i915/ddi: Silence compiler warning for unknown output typeChris Wilson
Silences src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used uninitialized in this function [-Wuninitialized] Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1459717154-27607-1-git-send-email-chris@chris-wilson.co.uk
2016-04-03drm/i915: Show PCI power state under debugfs/i915_runtime_pm_statusChris Wilson
As the current PCI power state is an essential feature of runtime pm, include it in the debugfs/i915_runtime_pm_status. v2: Use pci_power_name() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459689261-7920-2-git-send-email-chris@chris-wilson.co.uk
2016-04-03drm/i915: Add struct_mutex locking for debugs/i915_gem_framebufferChris Wilson
Since describe_obj() looks at state guarded by the struct_mutex, we need to be holding it. [ 580.201054] drv_suspend: starting subtest debugfs-reader [ 580.239652] ------------[ cut here ]------------ [ 580.239696] WARNING: CPU: 0 PID: 920 at include/linux/list_check.h:25 describe_obj+0x419/0x440() [ 580.239725] CPU: 0 PID: 920 Comm: cat Not tainted 4.5.0-rc6+ #835 [ 580.239745] Hardware name: /NUC5CPYB, BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [ 580.239767] 0000000000000000 ffff88027554fcf8 ffffffff812c1135 0000000000000000 [ 580.239815] ffffffff8193dc42 ffff88027554fd30 ffffffff8107419d ffff880071727c00 [ 580.239858] ffff8802757d8000 ffffffff818f693c ffffffff818f693c ffff8802757b9048 [ 580.239896] Call Trace: [ 580.239917] [<ffffffff812c1135>] dump_stack+0x67/0x92 [ 580.239939] [<ffffffff8107419d>] warn_slowpath_common+0x7d/0xb0 [ 580.239959] [<ffffffff810742ba>] warn_slowpath_null+0x1a/0x20 [ 580.239981] [<ffffffff813ce579>] describe_obj+0x419/0x440 [ 580.240006] [<ffffffff813ced22>] i915_gem_framebuffer_info+0xa2/0x100 [ 580.240033] [<ffffffff811a9286>] seq_read+0xe6/0x3b0 [ 580.240059] [<ffffffff81182288>] __vfs_read+0x28/0xd0 [ 580.240085] [<ffffffff81173378>] ? SyS_fadvise64+0x228/0x2c0 [ 580.240112] [<ffffffff811823b2>] vfs_read+0x82/0x110 [ 580.240137] [<ffffffff811827d9>] SyS_read+0x49/0xa0 [ 580.240162] [<ffffffff815bac57>] entry_SYSCALL_64_fastpath+0x12/0x6b [ 580.240187] ---[ end trace 3e2cbf34576c9878 ]--- [ 580.281900] ------------[ cut here ]------------ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1459689261-7920-1-git-send-email-chris@chris-wilson.co.uk
2016-04-01drm/i915: Fix plane init failure pathsVille Syrjälä
Deal with errors from drm_universal_plane_init() in primary and cursor plane init paths (sprites were already covered). Also make the code neater by using goto for error handling. v2: Rebased due to drm_universal_plane_init() 'name' parameter v3: Another rebase due to s/""/NULL/ v4: Rebased on drm-nightly (Matthew Auld) v5: Fix email address (Matthew Auld) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458571402-32749-1-git-send-email-matthew.auld@intel.com
2016-04-01drm/i915: Remove the "three times for luck" trick from vlv_enable_pll()Ville Syrjälä
VLV DPLL is somewhat sane and doesn't run on luck. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-7-git-send-email-ville.syrjala@linux.intel.com Acked-by: Jani Nikula <jani.nikula@intel.com>
2016-04-01drm/i915: assert_panel_unlocked() in chv_enable_pll()Ville Syrjälä
Supposedly the power sequencer still locks out the DPLL registers on CHV, so let's issue a warning if it's still locked when enabling the DPLL. Also drop the redundant IS_MOBILE() check for VLV when we check the same thing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-6-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-01drm/i915: Add a local pipe variable to vlv_enable_pll()Ville Syrjälä
Avoid redundant crtc->pipe lookups by giving vlv_enable_pll() a local pipe variable. Also makes it look more like the corresponding CHV code. While at is change the CHV code to enum pipe from int, Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-01drm/i915: Implement WaPixelRepeatModeFixForC0:chvVille Syrjälä
DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B) to either pipe B or C. So do that to make pixel repeat work on pipes B and C. Pipe A is fine without any tricks. Fortunately the pixel repeat propagation appears to be a oneshot operation, so once the value has been written we can clear the chicken bits. So it is still possible to drive pipe B and C with different pixel multipliers simultaneosly. Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B) for this to work. But since we keep that bit always set in all DPLLs there's no problem. This of course means we can't reliably read out the pixel multiplier for pipes B and C. That would make the state checker unhappy, so I added shadow copies of those registers in to dev_priv. The other option would have been to skip pixel multiplier, dpll_md an dotclock checks entirely on CHV, but that feels like a serious loss of cross checking, so just pretending that we have working DPLL MD registers seemed better. Obviously with the shadow copies we can't detect if the pixel multiplier was properly configured, nor can we take over its state from the BIOS, but hopefully people won't have displays that would be limitd to such crappy modes. There is one strange flicker still remaining. It's visible on pipe C/HDMID when HDMIB is enabled while driven by pipe B. It doesn't occur if pipe A drives HDMIB, nor is there any glitch on pipe B/HDMIB when port C/HDMID starts up. I don't have a board with HDMIC so not sure if it happens there too. So I'm not sure if it's somehow tied in with this strange linkage between pipe B and C. Sadly I was unable to find an enable sequence that would avoid the glitch, but at least it's not fatal ie. the output recovers afterwards. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-4-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-01drm/i915: Make {vlv,chv}_{disable,update}_pll() more similarVille Syrjälä
The VLV and CHV DPLL disable and update are almost identical in how the DPLL/DPLL_MD registers need to be set up. But the code looks more different than it really is. Try to bring them into line. Note that we now leave the refclock always enabled for both DPLLs in the dual channel PHY. But that's perfectly fine since it's the same clock, and we anyway already do that when turning the disp2d power well on. v2: s/chv_update_pll/chv_compute_dpll/ v3: Add a note that we leave refclocks enabled for both DPLLs (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-01drm/i915: Throw out BUGs from DPLL/PCH functionsVille Syrjälä
These BUGs don't serve any purpose IMO. Throw them out. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-04-01drm/i915: Disable FDI RX before DDI_BUF_CTLVille Syrjälä
Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists FDI RX disable both as step 13 and step 18 in the sequence. But I dug up an old BUN mail from Art that moved the FDI RX disable to happen before DDI_BUF_CTL disable. That BUN did not renumber the steps and just added a note: "Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL." The BUN described the symptoms of the fixed issue as: "PCH display underflow and a black screen on the analog CRT port that happened after a FDI re-train" I suppose later someone tried to renumber the steps to match, but forgot to remove the FDI RX disable from its old position in the sequence. They also forgot to update the note describing what should be done in case of an FDI training failure. Currently it says: "To retry FDI training, follow the Disable Sequence steps to Disable FDI, but skip the steps related to clocks and PLLs (16, 19, and 20), ..." It should really say "17, 20, and 21" with the current sequence because those are the steps that deal with PLLs and whatnot, after step 13 became FDI RX disable. And had the step 18 FDI RX disable been removed, as I suspect it should have, the note should actually say "17, 19, and 20". So, let's move the FDI RX disable to happen before DDI_BUF_CTL disable, as that would appear to be the correct order based on the BUN. Note that Art has since unconfused the spec, and so this patch should now match the steps listed in the spec. v2: Add a note that the spec is now correct Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456841783-4779-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
2016-04-01drm/radeon: Only call drm_vblank_on/off between drm_vblank_init/cleanupMichel Dänzer
Prevents the if (WARN_ON(pipe >= dev->num_crtcs)) in drm_vblank_on/off from triggering if acceleration fails to initialize, in which case we call drm_vblank_cleanup. Reported-and-Tested-by: Julian Margetson <runaway@candw.ms> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amdgpu: fence wait old rcu slotChunming Zhou
since the rcu slot was initialized to be num_hw_submission, if command submission doesn't use scheduler, this limitation will be invalid like uvd test. Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amdgpu: fix leaking fence in the pageflip codeChristian König
This fixes a memory leak when we can't register the callback on a fence. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amdgpu: print vram type rather than just DDRAlex Deucher
We have the info, so use it rather than reporting just DDR. Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amdgpu/gmc: use proper register for vram type on FijiAlex Deucher
The offset changed on Fiji. Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-04-01drm/amdgpu/gmc: move vram type fetching into sw_initAlex Deucher
early_init gets called before atom asic init so on non-posted cards, the vram type is not initialized. Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-04-01drm/amdgpu: Set vblank_disable_allowed = trueMichel Dänzer
Without this, since the conversion from drm_vblank_pre/post_modeset to drm_vblank_on/off, the vblank interrupt could never be disabled after userspace triggered enabling it. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/radeon: Set vblank_disable_allowed = trueMichel Dänzer
Without this, since the conversion from drm_vblank_pre/post_modeset to drm_vblank_on/off, the vblank interrupt could never be disabled after userspace triggered enabling it. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amd/powerplay: Need to change boot to performance state in resume.Rex Zhu
Fixes slow performance on resume. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amd/powerplay: add new Fiji function for not setting same ps.Rex Zhu
Add comparison function used by powerplay to determine which power state to select. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amdgpu: check dpm state before pm system fs initialized.Rex Zhu
Make sure powerplay initialized properly before enabling debugfs pm files. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed- by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amd/powerplay: notify amdgpu whether dpm is enabled or not.Rex Zhu
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amdgpu: Not support disable dpm in powerplay.Rex Zhu
We don't support the dpm parameter in powerplay. Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amdgpu: add an cgs interface to notify amdgpu the dpm state.Rex Zhu
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-01drm/amd/powerplay: fix segment fault issue in multi-display case.Rex Zhu
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com> Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-04-01Revert "drm/i915: Fix races on fbdev"Joonas Lahtinen
This reverts commit a7442b93cf32c1e1ddb721a26cd1f92302e2a222. With the patch applied SNB, IVB and ILK are experiencing hard machine hangs. Original patch was to fix "just" kernel panics so it's not a good trade-off. Proper fix for the panic is on the way, lets revert until then. Fixes: a7442b93cf32 ("drm/i915: Fix races on fbdev") Cc: Lukas Wunner <lukas@wunner.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: stable@vger.kernel.org Acked-by: Lukas Wunner <lukas@wunner.de> Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459510861-29035-1-git-send-email-joonas.lahtinen@linux.intel.com
generated by cgit (git 2.34.1) at 2025-09-16 00:29:46 +0000