aboutsummaryrefslogtreecommitdiffstatshomepage
path: root/tools/perf/scripts/python/call-graph-from-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2017-04-26drm/i915: checking for NULL instead of IS_ERR() in mock selftestsDan Carpenter1-1/+1
i915_gem_request_alloc() uses error pointers. It never returns NULLs. Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwanda Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit be02f7556447a0dee672acb5e462f03377b98ae8) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-04-26drm/i915: Perform link quality check unconditionally during long pulseVille Syrjälä1-2/+13
Apparently some DP sinks are a little nuts and cause HPD to drop intermittently during modesets. This happens eg. on an ASUS PB287Q. In oder to recover from this we can't really use the previous connector status to determine if the link needs retraining, so let's just ignore that piece of information and do the retrain unconditionally. We do of course still check whether the link is supposed to be running or not. To actually get read out the EDID and update things properly we also need to nuke the goto out added by commit 7d23e3c37bb3 ("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure why that was there. Perhaps to avoid an EDID read if the connector status didn't appear to change, but that sort of thing is quite racy and would have failed anyway if we failed to keep up with the hotplugs (if we missed the HPD down in between two HPD ups). And now that we take this codepath unconditionally we definitely need to drop the goto as otherwise we would never do the EDID read. v2: Drop the goto that made us skip EDID reads entirely. Doh! v3: Rebase due to locking changes s/apparely/apparently/ in the comment (Chris) Cc: stable@vger.kernel.org Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Reported-by: Palmer Dabbelt <palmer@dabbelt.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766 References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com (cherry picked from commit 1a36147bb93921651f7fbd7a6e522da6c349081b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-04-26drm/i915: Fix use after free in lpe_audio_platdev_destroy()Chris Wilson1-1/+8
[31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr ffff8801f7788358 [31908.547297] Read of size 8 by task drv_selftest/3781 [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G BU W 4.10.0+ #451 [31908.547553] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015 [31908.547682] Call Trace: [31908.547772] dump_stack+0x68/0x9f [31908.547857] kasan_object_err+0x1c/0x70 [31908.547947] kasan_report_error+0x1f1/0x4f0 [31908.548038] ? kfree+0xaa/0x170 [31908.548121] kasan_report+0x34/0x40 [31908.548211] ? klist_children_get+0x20/0x30 [31908.548472] ? intel_lpe_audio_teardown+0x78/0xb0 [i915] [31908.548567] __asan_load8+0x5e/0x70 [31908.548824] intel_lpe_audio_teardown+0x78/0xb0 [i915] [31908.549080] intel_audio_deinit+0x28/0x80 [i915] [31908.549315] i915_driver_unload+0xe4/0x360 [i915] [31908.549551] ? i915_driver_load+0x1d70/0x1d70 [i915] [31908.549651] ? trace_hardirqs_on+0xd/0x10 [31908.549885] i915_pci_remove+0x23/0x30 [i915] [31908.549978] pci_device_remove+0x5c/0x100 [31908.550069] device_release_driver_internal+0x1db/0x2e0 [31908.550165] driver_detach+0x68/0xc0 [31908.550256] bus_remove_driver+0x8b/0x150 [31908.550346] driver_unregister+0x3e/0x60 [31908.550439] pci_unregister_driver+0x1d/0x110 [31908.550531] ? find_module_all+0x7a/0xa0 [31908.550791] i915_exit+0x1a/0x87 [i915] [31908.550881] SyS_delete_module+0x264/0x2c0 [31908.550971] ? free_module+0x430/0x430 [31908.551064] ? trace_hardirqs_off_caller+0x16/0x110 [31908.551159] ? trace_hardirqs_on_caller+0x16/0x280 [31908.551256] ? trace_hardirqs_on_thunk+0x1a/0x1c [31908.551350] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.551440] RIP: 0033:0x7f1d67312ec7 [31908.551520] RSP: 002b:00007ffebe34e888 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [31908.551650] RAX: ffffffffffffffda RBX: ffffffff811123f6 RCX: 00007f1d67312ec7 [31908.551743] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560d0af476b8 [31908.551837] RBP: ffff880233d87f98 R08: 0000000000000000 R09: 00007ffebe34e8b8 [31908.551930] R10: 00007f1d68adf8c0 R11: 0000000000000206 R12: 0000000000000000 [31908.552023] R13: 0000560d0af46440 R14: 0000000000000034 R15: 00007ffebe34d860 [31908.552121] ? trace_hardirqs_off_caller+0x16/0x110 [31908.552217] Object at ffff8801f7788000, in cache kmalloc-2048 size: 2048 [31908.552306] Allocated: [31908.552377] PID = 3781 [31908.552456] save_stack_trace+0x16/0x20 [31908.552539] kasan_kmalloc+0xee/0x190 [31908.552627] __kmalloc+0xdb/0x1b0 [31908.552713] platform_device_alloc+0x27/0x90 [31908.552804] platform_device_register_full+0x36/0x220 [31908.553066] intel_lpe_audio_init+0x41e/0x570 [i915] [31908.553320] intel_audio_init+0xd/0x40 [i915] [31908.553552] i915_driver_load+0x13f5/0x1d70 [i915] [31908.553788] i915_pci_probe+0x65/0xe0 [i915] [31908.553881] pci_device_probe+0xda/0x140 [31908.553969] driver_probe_device+0x400/0x660 [31908.554058] __driver_attach+0x11c/0x120 [31908.554147] bus_for_each_dev+0xe6/0x150 [31908.554237] driver_attach+0x26/0x30 [31908.554325] bus_add_driver+0x26b/0x3b0 [31908.554412] driver_register+0xce/0x190 [31908.554502] __pci_register_driver+0xaf/0xc0 [31908.554589] 0xffffffffa0550063 [31908.554675] do_one_initcall+0x8b/0x1e0 [31908.554764] do_init_module+0x102/0x325 [31908.554852] load_module+0x3aad/0x45e0 [31908.554944] SyS_finit_module+0x169/0x1a0 [31908.555033] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.555119] Freed: [31908.555188] PID = 3781 [31908.555266] save_stack_trace+0x16/0x20 [31908.555349] kasan_slab_free+0xb0/0x180 [31908.555436] kfree+0xaa/0x170 [31908.555520] platform_device_release+0x76/0x80 [31908.555610] device_release+0x45/0xe0 [31908.555698] kobject_put+0x11f/0x260 [31908.555785] put_device+0x12/0x20 [31908.555871] platform_device_unregister+0x1b/0x20 [31908.556135] intel_lpe_audio_teardown+0x5c/0xb0 [i915] [31908.556390] intel_audio_deinit+0x28/0x80 [i915] [31908.556622] i915_driver_unload+0xe4/0x360 [i915] [31908.556858] i915_pci_remove+0x23/0x30 [i915] [31908.556948] pci_device_remove+0x5c/0x100 [31908.557037] device_release_driver_internal+0x1db/0x2e0 [31908.557129] driver_detach+0x68/0xc0 [31908.557217] bus_remove_driver+0x8b/0x150 [31908.557304] driver_unregister+0x3e/0x60 [31908.557394] pci_unregister_driver+0x1d/0x110 [31908.557653] i915_exit+0x1a/0x87 [i915] [31908.557741] SyS_delete_module+0x264/0x2c0 [31908.557834] entry_SYSCALL_64_fastpath+0x1c/0xb1 [31908.557919] Memory state around the buggy address: [31908.558005] ffff8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558127] ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558255] >ffff8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558374] ^ [31908.558467] ffff8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [31908.558595] ffff8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe, and we need to coordinate a proper fix in platform_device itself. Fixes: eef57324d926 ("drm/i915: setup bridge for HDMI LPE audio driver") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99952 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Cc: Jerome Anand <jerome.anand@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20170412080251.30648-1-chris@chris-wilson.co.uk Reviewed-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 48ae80741da4b8a26b6df0f765713912bc7cc480) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-04-26drm/i915: Use the right mapping_gfp_mask for final shmem allocationChris Wilson1-1/+1
Many sightings report the greater prevalence of allocation failures. This is all due to the incorrect use of mapping_gfp_constraint(), so remove it in favour of just querying the mapping_gfp_mask() which are the exact gfp_t we wanted in the first place. We still do expect a higher chance of reporting ENOMEM, as that is the intention of using __GFP_NORETRY -- to fail rather than oom after having reclaimed from our bo caches, and having done a direct|kswapd reclaim pass. Reported-by: Jason Ekstrand <jason.ekstrand@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594 Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170405221514.23251-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> (cherry picked from commit b268d9fe0f10544f5f7a1b7015e2b97075e6215d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-04-26drm/i915: Make legacy cursor updates more unsyncedVille Syrjälä1-11/+20
We're clearing the legacy_cursor_update flag before calling drm_atomic_helper_setup_commit() which means the helper will wait for the flip to complete before cleaning up the framebuffers. That's not what we want for the legacy cursor, so let's clear the flag after setting up the commit. Also toss in a FIXME about solving these problems in a nicer way using the fabled vblank workers. v2: Also unsync with legacy page flips Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Uwe Kleine-König <uwe@kleine-koenig.org> Cc: Rafael Ristovski <rafael.ristovski@gmail.com> Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170329142123.5923-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit 895203044067af64400cedbc055898bcec98d102) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-04-26drm/i915: Apply a cond_resched() to the saturated signalerChris Wilson1-1/+14
If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are more than sufficient to hog the CPU, preventing the system from even processing ICMP echo replies. v2: Tvrtko dug into cond_resched() on x86 and found that it only depended upon preempt_count and not tif_need_resched() - which means that we would always call schedule() at that point. Fixes: c81d46138da6 ("drm/i915: Convert trace-irq to the breadcrumb waiter") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170404120531.10737-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit a7980a640cbd339aa80f406d1786a275a2c320bc) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-04-26drm/i915: Park the signaler before sleepingChris Wilson1-3/+3
If the signal to park arrives before we sleep, then we need to check kthread_should_park() before sleeping to avoid missing the signal. Otherwise, if the signal arrives whilst we are processing completed requests, we will reset the current->state back to TASK_INTERRUPTIBLE and so miss the wakeup. Fixes: fe3288b5da2c ("drm/i915: Park the breadcrumbs signaler across a GPU reset") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170403105124.8969-1-chris@chris-wilson.co.uk Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (cherry picked from commit b1becb88268beb72df6495e35d3d76c138d215bb) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-04-18drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()Dan Carpenter1-2/+2
There are two bugs here. The && should be || and the > is off by one so it should be >= ARRAY_SIZE(). Fixes: 8453d674ae7e ("drm/i915/gvt: vGPU execlist virtualization") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-13drm/i915/gvt: Fix PTE write flush for taking runtime pm properlyZhenyu Wang1-0/+5
Make sure to take runtime pm when write PTE flush which ensure to write to hw properly. This fixes warning during mdev/vgpu creation which will do ggtt reset. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 9375 at drivers/gpu/drm/i915/intel_drv.h:1748 fwtable_write32+0x1c2/0x1e0 [i915] RPM wakelock ref not held during HW access Call Trace: ? dump_stack+0x5c/0x81 ? __warn+0xbe/0xe0 ? warn_slowpath_fmt+0x5a/0x80 ? wake_up_klogd+0x37/0x40 ? vprintk_emit+0x2ef/0x370 ? fwtable_write32+0x1c2/0x1e0 [i915] ? gtt_set_entry64+0xbb/0xd0 [i915] ? intel_vgpu_reset_ggtt+0x88/0xf0 [i915] ? intel_vgpu_init_gtt+0xa5/0x4f0 [i915] ? intel_gvt_create_vgpu+0x1b5/0x250 [i915] ? kobject_put+0x1b/0x50 ? intel_vgpu_create+0x4e/0x130 [kvmgt] ? mdev_device_create+0x186/0x2a0 [mdev] ? create_store+0xba/0xe0 [mdev] ? create_store+0xba/0xe0 [mdev] ? kernfs_fop_write+0x109/0x1a0 ? kernfs_fop_write+0x109/0x1a0 ? __vfs_write+0x33/0x160 ? __fput+0x161/0x1d0 ? vfs_write+0xb0/0x190 ? SyS_write+0x52/0xc0 ? exit_to_usermode_loop+0x7a/0xa0 ? entry_SYSCALL_64_fastpath+0x1e/0xad v2: remove unrelated oops info v3: change to take runtime pm for ggtt reset instead of get/put for each pte write flush Fixes: d650ac060237 ("drm/i915/gvt: reset the GGTT entry when vGPU created") Cc: Ping Gao <ping.a.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-13drm/i915/gvt: remove some debug messages in scheduler timer handlerZhenyu Wang2-10/+2
As those debug messages might appear in every timer call for scheduler, it's too noisy, eat too much log and aren't meaningful. So remove them. Cc: Ping Gao <ping.a.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-12drm/i915/gvt: add mmio init for virtual displayPei Zhang1-1/+28
GVT implements a purely virtual monitor for virtual GPU independent of the host. Some DDI related MMIO are not initialized in current code which cause the display initialization failure in guest. This patch fills the gap. Signed-off-by: Pei Zhang <pei.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-12drm/i915/gvt: use directly assignment for structure copyingChangbin Du2-4/+2
Let c compiler handle the structure copying. The compiler will use builtin function to handle that. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-12drm/i915/gvt: remove redundant ring id check which cause significant CPU mispredictionChangbin Du1-6/+0
From perf data, found a significant overhead at ring id check in the function get_opcode. This inline function is frequently used. Since Intel static predictor will predict the branch to fall through so the prediction most fail. This is wasting CPU pipeline resource. We do not need check the engine id everywhere, it should be reliable. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-12drm/i915/gvt: remove redundant platform check for mocs load/restoreChangbin Du1-6/+0
The platform check is done outside, no need check again. Platform doesn't include mocs should not invoke this two functions. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-12drm/i915/gvt: Align render mmio list to cachelineChangbin Du1-2/+2
Make the global mmio list be cacheline aligned to improve performance. Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-04-09Linux 4.11-rc6Linus Torvalds1-1/+1
2017-04-08mm/mempolicy.c: fix error handling in set_mempolicy and mbind.Chris Salls1-12/+8
In the case that compat_get_bitmap fails we do not want to copy the bitmap to the user as it will contain uninitialized stack data and leak sensitive data. Signed-off-by: Chris Salls <salls@cs.ucsb.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-04-08sysctl: report EINVAL if value is larger than UINT_MAX for proc_douintvecLiping Zhang1-0/+2
Currently, inputting the following command will succeed but actually the value will be truncated: # echo 0x12ffffffff > /proc/sys/net/ipv4/tcp_notsent_lowat This is not friendly to the user, so instead, we should report error when the value is larger than UINT_MAX. Fixes: e7d316a02f68 ("sysctl: handle error writing UINT_MAX to u32 fields") Signed-off-by: Liping Zhang <zlpnobody@gmail.com> Cc: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-04-08MAINTAINERS: separate out kernfs maintainershipTejun Heo1-2/+9
Separate out kernfs from driver core and add myself as a co-maintainer. Signed-off-by: Tejun Heo <tj@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08sysfs: be careful of error returns from ops->show()NeilBrown1-2/+4
ops->show() can return a negative error code. Commit 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.") (in v4.4) caused this to be stored in an unsigned 'size_t' variable, so errors would look like large numbers. As a result, if an error is returned, sysfs_kf_read() will return the value of 'count', typically 4096. Commit 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs") (in v4.8) extended this error to use the unsigned large 'len' as a size for memmove(). Consequently, if ->show returns an error, then the first read() on the sysfs file will return 4096 and could return uninitialized memory to user-space. If the application performs a subsequent read, this will trigger a memmove() with extremely large count, and is likely to crash the machine is bizarre ways. This bug can currently only be triggered by reading from an md sysfs attribute declared with __ATTR_PREALLOC() during the brief period between when mddev_put() deletes an mddev from the ->all_mddevs list, and when mddev_delayed_delete() - which is scheduled on a workqueue - completes. Before this, an error won't be returned by the ->show() After this, the ->show() won't be called. I can reproduce it reliably only by putting delay like usleep_range(500000,700000); early in mddev_delayed_delete(). Then after creating an md device md0 run echo clear > /sys/block/md0/md/array_state; cat /sys/block/md0/md/array_state The bug can be triggered without the usleep. Fixes: 65da3484d9be ("sysfs: correctly handle short reads on PREALLOC attrs.") Fixes: 17d0774f8068 ("sysfs: correctly handle read offset on PREALLOC attrs") Cc: stable@vger.kernel.org Signed-off-by: NeilBrown <neilb@suse.com> Acked-by: Tejun Heo <tj@kernel.org> Reported-and-tested-by: Miroslav Benes <mbenes@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08Documentation: stable-kernel-rules: fix stable-tag formatJohan Hovold1-1/+1
A patch documenting how to specify which kernels a particular fix should be backported to (seemingly) inadvertently added a minus sign after the kernel version. This particular stable-tag format had never been used prior to this patch, and was neither present when the patch in question was first submitted (it was added in v2 without any comment). Drop the minus sign to avoid any confusion. Fixes: fdc81b7910ad ("stable_kernel_rules: Add clause about specification of kernel versions to patch.") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-04-08msm/drm: gpu: Dynamically locate the clocks from the device treeJordan Crouse2-24/+58
Instead of using a fixed list of clock names use the clock-names list in the device tree to discover and get the list of clocks that we need. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm: gpu: Use OPP tables if we canJordan Crouse1-19/+66
If a OPP table is defined for the GPU device in the device tree use that in lieu of the downstream style GPU frequency table. If we do use the downstream table convert it to a OPP table so that we can take advantage of the OPP lookup facilities later. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm: Hard code the GPU "slow frequency"Jordan Crouse5-11/+11
Some A3XX and A4XX GPU targets required that the GPU clock be programmed to a non zero value when it was disabled so 27Mhz was chosen as the "invalid" frequency. Even though newer targets do not have the same clock restrictions we still write 27Mhz on clock disable and expect the clock subsystem to round down to zero. For unknown reasons even though the slow clock speed is always 27Mhz and it isn't actually a functional level the legacy device tree frequency tables always defined it and then did gymnastics to work around it. Instead of playing the same silly games just hard code the "slow" clock speed in the code as 27MHz and save ourselves a bit of infrastructure. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm: Add MSM_PARAM_GMEM_BASEJordan Crouse2-0/+4
User space needs to know where the GMEM whole starts so that they can set up the addressing correctly. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm: Reference count address spacesJordan Crouse6-13/+33
There are reasons for a memory object to outlive the file descriptor that created it and so the address space that a buffer object is attached to must also outlive the file descriptor. Reference count the address space so that it can remain viable until all the objects have released their addresses. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm: Make sure to detach the MMU during GPU cleanupJordan Crouse2-13/+19
We should be detaching the MMU before destroying the address space. To do this cleanly, the detach has to happen in adreno_gpu_cleanup() because it needs access to structs in adreno_gpu.c. Plus it is better symmetry to have the attach and detach at the same code level. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Enable 3D mux in mdp5_ctlArchit Taneja1-2/+7
3D mux is a small block placed after the DSPPs in MDP5. It can merge 2 LM/DSPP outputs and feed it to a single interface. Enable 3D Mux if our mdp5_pipeline has 2 active LMs. This check will need to be made more specific later when we add Dual DSI support with source split enabled. In that use case, each LM feeds to a separae INTF, so the 3D mux isn't needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Reset CTL blend registers before configuring themArchit Taneja1-0/+18
Assigning LMs dynamically to CRTCs results in REG_MDP5_CTL_LAYER_REGs and REG_MDP5_CTL_LAYER_EXT_REGs maintaining old values for a LM that isn't used by our CTL instance anymore. Clear the ctl's CTL_LAYER_REG and CTL_LAYER_EXT_REGs for all LM instances. The ones that need to be configured are configured later in this func. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Assign 'right' mixer to CRTC stateArchit Taneja3-22/+129
Dynamically assign a right mixer to mdp5_crtc_state in the CRTC's atomic_check path. Assigning the right mixer has some constraints, i.e, only a few LMs can be paired together. Update mdp5_mixer_assign to handle these constraints. Firstly, we need to identify whether we need a right mixer or not. At the moment, there are 2 scenarios where a right mixer might be needed: - If any of the planes connected to this CRTC is too wide (i.e, is comprised of 2 hwpipes). - If the CRTC's mode itself is too wide (i.e, a 4K mode on HDMI). We implement both these checks in the mdp5_crtc_atomic_check(), and pass 'need_right_mixer' to mdp5_setup_pipeline. If a CRTC is already assigned a single mixer, and a new atomic commit brings in a drm_plane that needs 2 hwpipes, we can successfully commit this mode without requiring a full modeset, provided that we still use the previously assigned mixer as the left mixer. If such an assignment isn't possible, we'd need to do a full modeset. This scenario has been ignored for now. The mixer assignment code is a bit messy, considering we have at most 4 LM instances in hardware. This can probably be re-visited later with simplified logic. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMsArchit Taneja1-10/+35
If a CRTC comprises of 2 LMs, it is mandatory to enable border out and assign it to the base stage. We had to enable border out also when the base plane wasn't fullscreen. Club these checks and put them in a separate function called get_start_stage() that returns the starting stage for assigning planes. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Stage right side hwpipes on Right-side Layer MixerArchit Taneja2-4/+20
Now that our mdp5_planes can consist of 2 hwpipes, update the blend_setup() code to stage the right hwpipe to the left and right LMs Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Prepare Layer Mixers for source splitArchit Taneja1-7/+32
In order to enable Source Split in HW, we need to add/modify a few LM register configurations: - Configure the LM width to be half the mode width, so that each LM manages one half of the scanout. - Tell the 'right' LM that it is configured to be the 'right' LM in source split mode. - Since we now have 2 places where REG_MDP5_LM_BLEND_COLOR_OUT is configured, do a read-update-store for the register instead of directly writing a value to it. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Configure 'right' hwpipeArchit Taneja2-1/+46
Now that we have a right hwpipe in mdp5_plane_state, configure it mdp5_plane_mode_set(). The only parameters that vary between the left and right hwpipes are the src_w, src_img_w, src_x and crtc_x as we just even chop the fb into left and right halves. Add a mdp5_plane_right_pipe() which will be used by the crtc code to set up LM stages. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Assign a 'right hwpipe' to plane stateArchit Taneja2-1/+57
If the drm_plane has a source width that's greater than the max width supported by a SSPP (2560 pixels on 8x96), then we assign a 'r_hwpipe' to it in mdp5_plane_atomic_check(). TODO: There are a few scenarios where the hwpipe assignments aren't recommended by HW. For example, an assignment which results in a drm_plane to of two different types of hwpipes (say RGB0 on left and DMA1 on right) is not recommended. Also, hwpipes have a priority mapping, where the higher priority pipe needs to be staged on left LM, and the lower priority needs to be staged on the right LM. For example, the priority order for VIG pipes in decreasing order of priority is VIG0, VIG1, VIG2, and VIG3. So, VIG0 on left and VIG1 on right is a correct configuration, but VIG1 on left and VIG0 on right isn't. These scenarios are ignored for now for the sake of simplicity. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Create mdp5_hwpipe_mode_setArchit Taneja1-97/+130
Refactor mdp5_plane_mode_set to call mdp5_hwpipe_mode_set. The latter func takes in only the hwpipe and the parameters that need to be programmed into the hwpipe registers. All the code that calculates these parameters is left as is in mdp5_plane_mode_set. In the future, when we let drm_plane be comprised of 2 hwpipes, this func allow us to configure each pipe without adding redundant code. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC stateArchit Taneja4-11/+103
Add another mdp5_hw_mixer pointer (r_mixer) in mdp5_crtc_state. This mixer will be used to generate the right half of the scanout. With Source Split, a SSPP can now be connected to 2 Layer Mixers, but has to be at the same blend level (stage #) on both Layer Mixers. A drm_plane that has a lesser width than the max width supported, will comprise of a single SSPP/hwpipe, staged on both the Layer Mixers at the same blend level. A plane that is greater than max width will comprise of 2 SSPPs, with the 'left' SSPP staged on the left LM, and the 'right' SSPP staged on the right LM at the same blend level. For now, the drm_plane consists of only one SSPP, therefore, it needs to be staged on both the LMs in blend_setup() and mdp5_ctl_blend(). We'll extend this logic to support 2 hwpipes per plane later. The crtc cursor ops (using the LM cursors, not SSPP cursors) simply return an error if they're called when the right mixer is assigned to the CRTC state. With source split is enabled, we're expected to only SSPP cursors. This commit adds code that configures the right mixer, but the r_mixer itself isn't assigned at the moment. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Add a CAP for Source SplitArchit Taneja2-6/+17
Some of the newer MDP5 versions support Source Split of SSPPs. It is a feature that allows us to route the output of a hwpipe to 2 Layer Mixers. This is required to achieve the following use cases: - Dual DSI: For high res DSI panels (such as 2560x1600 etc), a single DSI interface doesn't have the bandwidth to drive the required pixel clock. We use 2 DSI interfaces to drive the left and right halves of the panel (i.e, 1280x1600 each). The MDP5 pipeline here would look like: LM0 -- DSPP0 -- INTF1 -- DSI1 / hwpipe-- \ LM1 -- DSPP1 -- INTF2 -- DSI2 A single hwpipe is used to scan out the left and right halves to DSI1 and DSI2 respectively. In order to do this, we need to configure the 2 Layer Mixers in Source Split mode. - HDMI 4K: In order to support resolutions with width higher than the max width supported by a hwpipe, we club 2 hwpipes together: hwpipe1 --- LM0 -- DSPP0 - - \ - -- 3D Mux -- INTF0 -- HDMI - - / hwpipe2 --- LM1 -- DSPP1 hwpipe1 is staged on the 'left' Layer Mixer, and hwpipe2 is staged on the 'right' Layer Mixer. An additional block called the '3D Mux' is used to merge the output of the 2 DSPPs to a single interface. In this use case, it is possible that a 4K surface is downscaled and placed completely within one of the halves. In order to support such scenarios (and keep the programming simple), Layer Mixers with Source Split can be assigned 2 hw pipes per stage. While scanning out, the HW takes care of fetching the pixels fom the correct pipe. Add a MDP cap to tell whether the HW supports source split or not. Add a MDP LM cap that tells whether a LM instance can operate in source split mode (and generate the 'left' part of the display output). Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctlArchit Taneja7-63/+88
These are a part of CRTC state, it doesn't feel nice to leave them hanging in mdp5_ctl struct. Pass mdp5_pipeline pointer instead wherever it is needed. We still have some params in mdp5_ctl like start_mask etc which are derivative of atomic state, and should be rolled back if a commit fails, but it doesn't seem to cause much trouble. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Start using parameters from CRTC stateArchit Taneja3-66/+64
In the last few commits, we've been adding params to mdp5_crtc_state, and assigning them in the atomic_check() funcs. Now it's time to actually start using them. Remove the duplicated params from the mdp5_crtc struct, and start using them in the mdp5_crtc code. The majority of the references to these params is in code that executes after the atomic swap has occurred, so it's okay to use crtc->state in them. There are a couple of legacy LM cursor ops that may not use the updated state, but (I think) it's okay to live with that. Now that we dynamically allocate a mixer to the CRTC, we can also remove the static assignment to it in mdp5_crtc_init, and also drop the code that skipped init-ing WB bound mixers (those will now be rejected by mdp5_mixer_assign()). Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Add more stuff to CRTC stateArchit Taneja2-0/+26
Things like vblank/err irq masks, mode of operation (command mode or not) are derivative of the interface and mixer state. Therefore, they need to be a part of the CRTC state too. Add them to mdp5_crtc_state, and assign them in the CRTC's atomic_check() func, so that it can be rolled back to a clean state. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Assign INTF and CTL in encoder's atomic_check()Archit Taneja1-0/+16
The INTF and CTL used in a display pipeline are going to be maintained as a part of the CRTC state (i.e, in mdp5_crtc_state). These entities, however, are currently statically assigned to drm_encoders (i.e. mdp5_encoder). Since these aren't directly visible to the CRTC, we assign them to the CRTC state in the encoder's atomic_check() op. With this approach, we assign portions of CRTC state in two different places: the layer mixer in CRTC's atomic_check(), and the INTF and CTL pieces in the encoder's atomic_check() op. We'd have more options here if the drm core maintained encoder state too, but the current approach of clubbing everything in CRTC's state works just fine. Unlike hwpipes and mixers, we don't need to keep a track of INTF/CTL assignments in the global atomic state. This is because they're currently not sharable resources. For example, INTF0 and CTL0 will always be assigned to one drm_encoder. This can change later when we implement writeback and want a CRTC to use a CTL for a while, and then release it for others to use it. Or, when a drm_encoder can switch between using a single INTF vs 2 INTFs. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Prepare for dynamic assignment of mixersArchit Taneja5-0/+97
Add the stuff needed to allow dynamically assigning a mixer to a CRTC. Since mixers are a resource that can be shared across multiple CRTCs, we need to maintain a 'hwmixer_to_crtc' map in the global atomic state, acquire the mdp5_kms.state_lock modeset lock and so on. The mixer is assigned in the CRTC's atomic_check() func, a failure will result in the new state being cleanly rolled back. The mixer assignment itself is straightforward, and almost identical to what we do for hwpipes. We don't need to grab the old hwmixer_to_crtc state like we do in hwpipes since we don't need to compare anything with the old state at the moment. The only LM capability we care about at the moment is whether the mixer instance can be used to display stuff (i.e, connect to an INTF downstream). Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: subclass CRTC stateArchit Taneja2-6/+80
Subclass drm_crtc_state so that we can maintain additional state for our CRTCs. Add mdp5_pipeline and mdp5_ctl pointers in the subclassed state. mdp5_pipeline is a grouping of the HW entities that forms the downstream pipeline for a particular CRTC. It currently contains pointers to mdp5_interface and mdp5_hw_mixer tied to this CRTC. Later, we will have 2 hwmixers in this struct. (We could also have 2 intfs if we want to support dual DSI with Source Split enabled. Implementing that feature isn't planned at the moment). The mdp5_pipeline state isn't used at the moment. For now, we just introduce mdp5_crtc_state and the crtc funcs needed to manage the subclassed state. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Remove the pipeline stuff in mdp5_ctlArchit Taneja1-25/+17
The mdp5_ctl has an 'op_mode' struct which contains info on the downstream pipeline. Grouping these params together in a struct doesn't serve much purpose in the code. Maybe there was a plan to expand this further that never happened. Remove the op_mode struct, and place its members directly in mdp5_ctl. This will help avoid confusion later when I introduce my own verion of a mdp5 pipeline :) Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Clean up interface assignmentArchit Taneja5-64/+93
mdp5_interface struct contains data corresponding to a INTF instance in MDP5 hardware. This sturct is memcpy'd to the mdp5_encoder struct, and then later to the mdp5_ctl struct. Instead of copying around interface data, create mdp5_interface instances in mdp5_init, like how it's done currently done for pipes and layer mixers. Pass around the interface pointers to mdp5_encoder and mdp5_ctl. This simplifies the code, and allows us to decouple encoders from INTFs in the future if needed. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Simplify LM <-> PP mappingArchit Taneja4-12/+11
PingPong ID for a Layer Mixer is already contained in mdp5_hw_mixer. This avoids the need to retrieve PP ID using macros Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Start using mdp5_hw_mixerArchit Taneja8-43/+66
Use the mdp5_hw_mixer struct in the mdp5_crtc and mdp5_ctl instead of using the LM index. Like before, the Layer Mixers are assigned statically to the CRTCs. The hwmixer(s) will later be dynamically assigned to CRTCs. For now, ignore the hwmixers that can only do WB. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: Add structs for hw Layer MixersArchit Taneja5-0/+119
Create a struct to represent MDP5 Layer Mixer instances. This will eventually allow us to detach CRTCs from the Layer Mixers, and generally clean things up a bit. This is very similar to how hwpipes were previously abstracted away from drm planes. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
2017-04-08drm/msm/mdp5: describe LM instances in mdp5_cfgArchit Taneja3-0/+84
The number of Layer Mixers and the downstream blocks (DSPPs and PPs) connected to each LM can vary with different MDP5 revisions. These parameters are also static. Keep the per instance LM data in mdp5_cfg. This will avoid the need to have macros which identify PP id or DSPP id the LM is connected to. We don't configure DSPPs at the moment, but keeping the DSPP instance # here might come handy later. Also add a 'caps' field that identifies features supported by a LM instance. Introduce the caps MDP_LM_CAP_DISPLAY and MDP_LM_CAP_WB that identify whether a LM instance can be used for display or writeback. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.