- 11 Dec, 2018 40 commits
-
-
Sean Paul authored
The crtc runtime resume doesn't actually operate on the crtc, but rather its encoders. The problem with this is that we need to inspect the crtc state to get the currently connected encoders. Since runtime resume isn't guaranteed to be called while holding the modeset locks (although it sometimes is), this presents a race condition. Now that we have ->enabled on the virtual encoders, and a lock to protect it, just call resume on each encoder and only restore the ones that are enabled. Changes in v2: - None Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Reviewed-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Sean Paul authored
Add a bool to dpu_encoder_virt to track whether the encoder is enabled or not. Repurpose the enc_lock mutex to ensure that it is consistent with the hw state. Changes in v2: - None Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Reviewed-by:
-
Sean Paul authored
enc_spinlock instead of enc_spin_lock. Changes in v2: - None Reviewed-by:
-
Sean Paul authored
Now that we don't have any event handlers, remove dpu_power_handle! Changes in v2: - None Reviewed-by:
-
Sean Paul authored
It's only used in core_perf, so stick it there (and change the name to reflect that). Changes in v2: - None Reviewed-by:
-
Sean Paul authored
It's needed for struct dss_module_power, and is currently being pulled in by dpu_power_handle.h Changes in v2: - None Reviewed-by:
-
Sean Paul authored
It's unused Changes in v2: - None Reviewed-by:
-
Sean Paul authored
Instead of registering through dpu_power_handle just to get a call on runtime_resume, call the crtc function directly. Changes in v2: - None Reviewed-by:
-
Sean Paul authored
power_events are only used for pm_runtime, and that's all handled in dpu_kms. So just call vbif_init_memtypes at the correct times. Changes in v2: - Removed obsolete comment (Jeykumar) Cc: Jeykumar Sankaran <jsanka@codeaurora.org> Reviewed-by:
-
Sean Paul authored
There's only one client -- core, and it's only used for runtime pm which is already refcounted. Changes in v2: - None Reviewed-by:
-
Sean Paul authored
Changes in v2: - None Reviewed-by:
-
Sean Paul authored
It's only used for debugfs, so just output the enum value instead. Changes in v2: - None Reviewed-by:
-
Sean Paul authored
Since dpu_crtc subclasses crtc_state, we need a custom .reset hook in order to allocate the right amount of memory to accommodate the additional struct members in dpu_crtc_state. So bring it [partially] back. Relevant KASAN splat: [ 10.333382] ================================================================== [ 10.344288] BUG: KASAN: slab-out-of-bounds in kmemdup+0x50/0x80 [ 10.350390] Read of size 736 at addr ffffffc0d9f06080 by task frecon/394 [ 10.358861] CPU: 6 PID: 394 Comm: frecon Tainted: G W 4.19.4 #121 [ 10.366476] Hardware name: Google Cheza (rev2) (DT) [ 10.371514] Call trace: [ 10.374087] dump_backtrace+0x0/0x194 [ 10.377878] show_stack+0x20/0x28 [ 10.381330] dump_stack+0xa0/0xc8 [ 10.384783] print_address_description+0x78/0x2e0 [ 10.389639] kasan_report+0x290/0x2d0 [ 10.393428] check_memory_region+0x20/0x14c [ 10.397740] __asan_loadN+0x14/0x1c [ 10.401345] kmemdup+0x50/0x80 [ 10.404524] dpu_crtc_duplicate_state+0x58/0xa0 [ 10.409228] drm_atomic_get_crtc_state+0xac/0x178 [ 10.414095] __drm_atomic_helper_set_config+0x54/0x4a4 [ 10.419393] drm_atomic_helper_set_config+0x60/0xb4 [ 10.424435] drm_mode_setcrtc+0x720/0x760 [ 10.428570] drm_ioctl_kernel+0xd8/0x13c [ 10.432617] drm_ioctl+0x380/0x4f4 [ 10.436150] drm_compat_ioctl+0x54/0x13c [ 10.440219] __arm64_compat_sys_ioctl+0x1d8/0xef4 [ 10.445086] el0_svc_common+0xd8/0x138 [ 10.448961] el0_svc_compat_handler+0x58/0x68 [ 10.453463] el0_svc_compat+0x8/0x18 [ 10.458712] Allocated by task 56: [ 10.462148] kasan_kmalloc.part.4+0x48/0xf4 [ 10.466465] kasan_kmalloc+0x8c/0xa0 [ 10.470165] kmem_cache_alloc_trace+0x25c/0x27c [ 10.474848] drm_atomic_helper_crtc_reset+0x68/0x98 [ 10.479877] drm_mode_config_reset+0xc4/0x19c [ 10.484383] msm_drm_bind+0x814/0x8dc [ 10.488169] try_to_bring_up_master.part.7+0x48/0xac [ 10.493282] component_master_add_with_match+0x158/0x198 [ 10.498758] msm_pdev_probe+0x328/0x348 [ 10.502736] platform_drv_probe+0x74/0xc8 [ 10.506877] really_probe+0x1ac/0x35c [ 10.510659] driver_probe_device+0xd4/0x118 [ 10.514975] __device_attach_driver+0xc8/0xf4 [ 10.519477] bus_for_each_drv+0xb4/0xe4 [ 10.523439] __device_attach+0xd0/0x158 [ 10.527394] device_initial_probe+0x24/0x30 [ 10.531715] bus_probe_device+0x50/0xe4 [ 10.535681] deferred_probe_work_func+0xac/0xdc [ 10.540376] process_one_work+0x3f0/0x6d4 [ 10.544521] worker_thread+0x3f4/0x520 [ 10.548399] kthread+0x1b4/0x1c8 [ 10.551740] ret_from_fork+0x10/0x18 [ 10.556986] Freed by task 0: [ 10.559967] (stack is not available) [ 10.565216] The buggy address belongs to the object at ffffffc0d9f06080 which belongs to the cache kmalloc-1024 of size 1024 [ 10.578268] The buggy address is located 0 bytes inside of 1024-byte region [ffffffc0d9f06080, ffffffc0d9f06480) [ 10.590248] The buggy address belongs to the page: [ 10.595195] page:ffffffbf0367c000 count:1 mapcount:0 mapping:ffffffc0de40f680 index:0x0 compound_mapcount: 0 [ 10.605321] flags: 0x4000000000008100(slab|head) [ 10.610100] raw: 4000000000008100 ffffffbf0369fa08 ffffffbf0367f008 ffffffc0de40f680 [ 10.618077] raw: 0000000000000000 0000000000150015 00000001ffffffff 0000000000000000 [ 10.626049] page dumped because: kasan: bad access detected [ 10.633341] Memory state around the buggy address: [ 10.638282] ffffffc0d9f06180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 10.645710] ffffffc0d9f06200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 10.653139] >ffffffc0d9f06280: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc [ 10.660571] ^ [ 10.665774] ffffffc0d9f06300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 10.673210] ffffffc0d9f06380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 10.680639] ================================================================== Fixes: a6ba45afda41 (drm/msm/dpu: Replace dpu_crtc_reset by atomic helper) Cc: Sean Paul <seanpaul@chromium.org> Cc: Bruce Wang <bzwang@chromium.org> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:Bruce Wang <bzwang@chromium.org> Signed-off-by:
-
Jonathan Marek authored
This patch allows using drm/msm without qcom display hardware. It adds a amd,imageon compatible, which is used instead of qcom,adreno, but does not require a top level msm node. Signed-off-by:
Jonathan Marek <jonathan@marek.ca> Signed-off-by:
-
Matthias Kaehlcke authored
Allow the PHY drivers to get the ref clock from the DT. Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Jonathan Marek authored
Document the new amd,imageon compatible, used for non-qcom hardware that uses the drm/msm driver (iMX5). Signed-off-by:
-
Jonathan Marek authored
This allows controlling which of the 8 lanes are used for 6 bit color. Signed-off-by:
-
Jonathan Marek authored
A2XX has its own very simple MMU. Added a msm_use_mmu() function because we can't rely on iommu_present to decide to use MMU or not. Signed-off-by:
-
Douglas Anderson authored
When trying to get the display up on my sdm845 board I noticed that the display wouldn't probe if I had the dsi1 node marked as "disabled" even though my board doesn't use dsi1. It looks like the msm code adds all nodes to its list of components even if they are disabled. I believe this doesn't work because all registered components need to come up before we finish probing. Let's do like other DRM code and only add available components. Signed-off-by:
-
Jordan Crouse authored
Add a buffer object name for the a6xx crashdumper so it can be seen with the changes introduced by 7799a98edd ("drm/msm: Add a name field for gem objects"). Signed-off-by:Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
-
Jordan Crouse authored
dadb36b7ec42 ("drm/msm: Add a common function to free kernel buffer objects") missed freeing the crashdumper state for a6xx. Signed-off-by: -
Sean Paul authored
This patch sprinkles a few async/legacy_cursor_update checks through commit to ensure that cursor updates aren't blocked on vsync. There are 2 main components to this, the first is that we don't want to wait_for_commit_done in msm_atomic before returning from atomic_complete. The second is that in dpu we don't want to wait for frame_done events when updating the cursor. Changes in v2: - None Reviewed-by:
-
Sean Paul authored
There exists a case where a flush of a plane/dma may have been triggered & started from an async commit. If that plane/dma is subsequently disabled by the next commit, the flush register will continue to hold the flush bit for the disabled plane. Since the bit remains active, pending_kickoff_cnt will never decrement and we'll miss frame_done events. This patch limits the check of flush_register to include only those bits which have been updated with the latest commit. Changes in v2: - None Reviewed-by:
-
Jayant Shekhar authored
In case of msm drm bind failure, dpu_mdss_destroy is triggered. In this function, resources are freed and pm runtime disable is called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable, driver tries to access a memory which is already freed. This results in kernel panic. Fix this by ensuring proper sequence of dpu destroy and disable calls. Changes in v2: - Removed double spacings [Jeykumar] Tested-by:
Jayant Shekhar <jshekhar@codeaurora.org> Signed-off-by:
-
Abhinav Kumar authored
Fix the dsi clock names in the DSI 10nm PLL driver to match the names in the dispcc driver as those are according to the clock plan of the chipset. Changes in v2: - Update the clock diagram with the new clock name Reviewed-by:
Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by:
-
Jonathan Marek authored
otherwise, priv->kms is non-NULL and msm_drm_uninit will cause a panic. Signed-off-by:
-
Jonathan Marek authored
Add the mdp5_cfg_hw entry for MDP5 version v1.15 found on msm8917. Signed-off-by:
-
Jonathan Marek authored
derived from the a3xx driver and tested on the following hardware: imx51-zii-rdu1 (a200 with 128kb gmem) imx53-qsrb (a200) msm8060-tenderloin (a220) Signed-off-by:
-
Jonathan Marek authored
Makes it possible to have MMU for GPU but not display. Signed-off-by:
-
Jonathan Marek authored
For allocation in contiguous memory when the GPU has MMU but not mdp4. Signed-off-by:
-
Jonathan Marek authored
Signed-off-by:
-
Rob Clark authored
Signed-off-by: -
Rob Clark authored
Add UAPI to get/set GEM objects' debug name. Signed-off-by: -
Rob Clark authored
Prep work to add a way to get/set the GEM objects debug name. Signed-off-by: -
Rob Clark authored
To lower CPU overhead, future userspace will be switching to pinning iova and avoiding the use of relocs, and only include cmds table entries for IB1 level cmdstream (but not IB2 or state-groups). This leaves the kernel unsure what to dump for rd/hangrd cmdstream dumping. So add a MSM_SUBMIT_BO_DUMP flag so userspace can indicate buffers that contain cmdstream (or are otherwise important to dump). Signed-off-by: -
Sharat Masetty authored
When the userspace tries to read the crashstate dump, the read side implementation in the driver currently ascii85 encodes all the binary buffers and it does this each time the read system call is called. A userspace tool like cat typically does a page by page read and the number of read calls depends on the size of the data captured by the driver. This is certainly not desirable and does not scale well with large captures. This patch encodes the buffer only once in the read path. With this there is an immediate >10X speed improvement in crashstate save time. Signed-off-by:
Sharat Masetty <smasetty@codeaurora.org> Reviewed-by:
-
Jordan Crouse authored
For reasons that I'm sure made perfect sense at the time we were opting to defer the iova alloc / pin on the ringbuffer until HW init time so when we moved to iova reference counting we ended up adding a reference count every time the hardware started. Not that it mattered (because the ring is always around) but it did make the debug output look odd. Allocate and pin the iova at create time instead. Signed-off-by:
-
Jordan Crouse authored
For debugging purposes it is useful to assign descriptions to buffers so that we know what they are used for. Add a field to the buffer object and use that to name the various kernel side allocations which ends up looking like like this in /d/dri/X/gem: flags id ref offset kaddr size madv name 00040000: I 0 ( 1) 00000000 0000000070b79eca 00004096 memptrs vmas: [gpu: 01000000,mapped,inuse=1] 00020000: I 0 ( 1) 00000000 0000000031ed4074 00032768 ring0 Signed-off-by: -
Jordan Crouse authored
Add a reference count to track how many times a particular chunk of iova memory is pinned (mapped) in the iomu and add msm_gem_unpin_iova to give up references. It is important to note that msm_gem_unpin_iova replaces msm_gem_put_iova because the new implicit behavior that an assigned iova in a given vma is now valid for the life of the buffer and what we are really focusing on is the use of that iova. For now the unmappings are lazy; once the reference counts go to zero they *COULD* be unmapped dynamically but that will require an outside force such as a shrinker or mm_notifiers. For now, we're just focusing on getting the counting right and setting ourselves up to be ready for the future. Signed-off-by:
-
Jordan Crouse authored
Add a new function to get and pin the iova memory in one step (basically renaming the old msm_gem_get_iova function) and switch msm_gem_get_iova() to only allocate an iova but not map it in the IOMMU. This is only currently used by msm_ioctl_gem_info() since all other users of of the iova expect that the memory be immediately available. Signed-off-by:
-
