summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/msm
Commit message (Collapse)AuthorAgeFilesLines
* drm/msm: Fix potential buffer overflow issueKasin Li2017-06-191-3/+6
| | | | | | | | | | In function submit_create, if nr_cmds or nr_bos is assigned with negative value, the allocated buffer may be small than intended. Using this buffer will lead to buffer overflow issue. Signed-off-by: Kasin Li <donglil@codeaurora.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Separate locking of buffer resources from struct_mutexSushmita Susheelendra2017-06-1717-144/+238
| | | | | | | | | | | | | | Buffer object specific resources like pages, domains, sg list need not be protected with struct_mutex. They can be protected with a buffer object level lock. This simplifies locking and makes it easier to avoid potential recursive locking scenarios for SVM involving mmap_sem and struct_mutex. This also removes unnecessary serialization when creating buffer objects, and also between buffer object creation and GPU command submission. Signed-off-by: Sushmita Susheelendra <ssusheel@codeaurora.org> [robclark: squash in handling new locking for shrinker] Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/hdmi: Fix HDMI pink strip issue seen on 8x96Archit Taneja2017-06-161-3/+67
| | | | | | | | | | | | | | | A 2 pixel wide pink strip was observed on the left end of some HDMI monitors configured in a HDMI mode. It turned out that we were missing out on configuring AVI infoframes, and unlike APQ8064, the 8x96 HDMI H/W seems to be sensitive to that. Add configuration of AVI infoframes. While at it, make sure that hdmi_audio_update is only called when we've detected that the monitor supports HDMI. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/hdmi: 8996 PLL: Populate unprepareArchit Taneja2017-06-161-0/+5
| | | | | | | | | | | | Without doing anything in unprepare, the HDMI driver isn't able to switch modes successfully. Calling set_rate with a new rate results in an un-locked PLL. If we reset the PLL in unprepare, the PLL is able to lock with the new rate. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/hdmi: Use bitwise operators when building register valuesLiviu Dudau2017-06-161-3/+3
| | | | | | | | | | | Commit c0c0d9eeeb8d ("drm/msm: hdmi audio support") uses logical OR operators to build up a value to be written in the REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it should have used bitwise operators. Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support") Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: update generated headersRob Clark2017-06-1615-337/+2059
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: remove address-space idRob Clark2017-06-168-46/+0
| | | | | | | | Now that the msm_gem supports an arbitrary number of vma's, we no longer need to assign an id (index) to each address space. So rip out the associated code. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: support for an arbitrary number of address spacesRob Clark2017-06-162-43/+99
| | | | | | | It means we have to do a list traversal where we once had an index into a table. But the list will normally have one or two entries. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: refactor how we handle vram carveout buffersRob Clark2017-06-161-21/+27
| | | | | | | | | | | Pull some of the logic out into msm_gem_new() (since we don't need to care about the imported-bo case), and don't defer allocating pages. The latter is generally a good idea, since if we are using VRAM carveout to allocate contiguous buffers (ie. no IOMMU), the allocation is more likely to fail. So failing at allocation time is a more sane option. Plus this simplifies things in the next patch. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: pass address-space to _get_iova() and friendsRob Clark2017-06-1617-58/+78
| | | | | | | | No functional change, that will come later. But this will make it easier to deal with dynamically created address spaces (ie. per- process pagetables for gpu). Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/mdp4+5: move aspace/id to base classRob Clark2017-06-1611-40/+56
| | | | | | | | | | | Before we can shift to passing the address-space object to _get_iova(), we need to fix a few places (dsi+fbdev) that were hard-coding the adress space id. That gets somewhat easier if we just move these to the kms base class. Prep work for next patch. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/mdp5: kill pipe_lockRob Clark2017-06-161-10/+0
| | | | | | | | It serves no purpose, things should be sufficiently synchronized already by atomic framework. And it is somewhat awkward to be holding a spinlock when msm_gem_iova() is going to start needing to grab a mutex. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: fix locking inconsistency for gpu->hw_init()Rob Clark2017-06-166-16/+17
| | | | | | | | | | | | Most, but not all, paths where calling the with struct_mutex held. The fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run the first time) was masking this issue. So lets just always hold struct_mutex for hw_init(). And sprinkle some WARN_ON()'s and might_lock() to avoid this sort of problem in the future. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Remove memptrs->wptrJordan Crouse2017-06-162-4/+0
| | | | | | | | memptrs->wptr seems to be unused. Remove it to avoid confusing the upcoming preemption code. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Add a struct to pass configuration to msm_gpu_init()Jordan Crouse2017-06-163-10/+26
| | | | | | | | | The amount of information that we need to pass into msm_gpu_init() is steadily increasing, so add a new struct to stabilize the function call and make it easier to add new configuration down the line. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Add hint to DRM_IOCTL_MSM_GEM_INFO to return an object IOVAJordan Crouse2017-06-161-2/+21
| | | | | | | | | | | Modify the 'pad' member of struct drm_msm_gem_info to 'flags'. If the user sets 'flags' to non-zero it means that they want a IOVA for the GEM object instead of a mmap() offset. Return the iova in the 'offset' member. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> [robclark: s/hint/flags in commit msg] Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Remove idle function hookJordan Crouse2017-06-166-11/+10
| | | | | | | There isn't any generic code that uses ->idle so remove it. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Remove DRM_MSM_NUM_IOCTLSJordan Crouse2017-06-161-1/+1
| | | | | | | | | | The ioctl array is sparsely populated but the compiler will make sure that it is sufficiently sized for all the values that we have so we can safely use ARRAY_SIZE() instead of having a constantly changing #define in the uapi header. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: gpu: Enable zap shader for A5XXJordan Crouse2017-06-165-2/+183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The A5XX GPU powers on in "secure" mode. In secure mode the GPU can only render to buffers that are marked as secure and inaccessible to the kernel and user through a series of hardware protections. In practice secure mode is used to draw things like a UI on a secure video frame. In order to switch out of secure mode the GPU executes a special shader that clears out the GMEM and other sensitve registers and then writes a register. Because the kernel can't be trusted the shader binary is signed and verified and programmed by the secure world. To do this we need to read the MDT header and the segments from the firmware location and put them in memory and present them for approval. For targets without secure support there is an out: if the secure world doesn't support secure then there are no hardware protections and we can freely write the SECVID_TRUST register from the CPU. We don't have 100% confidence that we can query the secure capabilities at run time but we have enough calls that need to go right to give us some confidence that we're at least doing something useful. Of course if we guess wrong you trigger a permissions violation which usually ends up in a system crash but thats a problem that shows up immediately. [v2: use child device per Bjorn] [v3: use generic MDT loader per Bjorn] [v4: use managed dma functions and ifdefs for the MDT loader] [v5: Add depends for QCOM_MDT_LOADER] Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> [robclark: fix Kconfig to use select instead of depends + #if IS_ENABLED()] Signed-off-by: Rob Clark <robdclark@gmail.com>
* BackMerge tag 'v4.12-rc5' into drm-nextDave Airlie2017-06-1610-20/+35
|\ | | | | | | Linux 4.12-rc5 for nouveau fixes
| * drm/msm: Fix the check for the command sizeJordan Crouse2017-05-271-2/+3
| | | | | | | | | | | | | | | | | | | | The overrun check for the size of submitted commands is off by one. It should allow the offset plus the size to be equal to the size of the memory object when the command stream is very tightly constructed. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm: Take the mutex before calling msm_gem_new_implJordan Crouse2017-05-271-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Amongst its other duties, msm_gem_new_impl adds the newly created GEM object to the shared inactive list which may also be actively modifiying the list during submission. All the paths to modify the list are protected by the mutex except for the one through msm_gem_import which can end up causing list corruption. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> [add extra WARN_ON(!mutex_is_locked(&dev->struct_mutex))] Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm: for array in-fences, check if all backing fences are from our own ↵Philipp Zabel2017-05-271-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | context before waiting Use the dma_fence_match_context helper to check if all backing fences are from our own context, in which case we don't have to wait. Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Cc: Rob Clark <robdclark@gmail.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.com> [rebased on code-motion] Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm: constify irq_domain_opsTobias Klauser2017-05-271-1/+1
| | | | | | | | | | | | | | struct irq_domain_ops is not modified, so it can be made const. Signed-off-by: Tobias Klauser <tklauser@distanz.ch> Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm/mdp5: release hwpipe(s) for unused planesRob Clark2017-05-271-0/+4
| | | | | | | | | | | | | | Otherwise, if userspace doesn't re-use a given plane, it's hwpipe(s) could stay permanently assigned. Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm: Reuse dma_fence_release.Eric Anholt2017-05-271-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | If we follow the typical pattern of the base class being the first member, we can use the default dma_fence_free function. Signed-off-by: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm: Expose our reservation object when exporting a dmabuf.Eric Anholt2017-05-273-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Without this, polling on the dma-buf (and presumably other devices synchronizing against our rendering) would return immediately, even while the BO was busy. Signed-off-by: Eric Anholt <eric@anholt.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm/gpu: check legacy clk names in get_clocks()Rob Clark2017-05-271-2/+2
| | | | | | | | | | | | | | | | | | Otherwise if someone was using old bindings with "core_clk" instead of "core" as the clock name, we'd never find it and gpu would be stuck at 27MHz (or whatever it's slowest rate is). Fixes: 98db803 ("msm/drm: gpu: Dynamically locate the clocks from the device tree") Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm/mdp5: use __drm_atomic_helper_plane_duplicate_state()Rob Clark2017-05-271-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Somehow the helper was never retrofitted for mdp5. Which meant when plane_state->fence was added, it could get copied into new state in mdp5_plane_duplicate_state(). If an update to disable the plane (for example on rmfb) managed to sneak in after an nonblock update had swapped state, but before it was committed, we'd get a splat: WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061 drm_atomic_helper_wait_for_fences+0xe0/0xf8 Modules linked in: CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: G W 4.11.0-rc8+ #1187 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) Workqueue: events drm_mode_rmfb_work_fn task: ffffffc036560d00 task.stack: ffffffc036550000 PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8 LR is at complete_commit.isra.1+0x44/0x1c0 pc : [<ffffff80084f6040>] lr : [<ffffff800854176c>] pstate: 20000145 sp : ffffffc036553b60 x29: ffffffc036553b60 x28: ffffffc0264e6a00 x27: ffffffc035659000 x26: 0000000000000000 x25: ffffffc0240e8000 x24: 0000000000000038 x23: 0000000000000000 x22: ffffff800858f200 x21: ffffffc0240e8000 x20: ffffffc02f56a800 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: ffffffc00a192700 x13: 0000000000000004 x12: 0000000000000000 x11: ffffff80089a1690 x10: 00000000000008f0 x9 : ffffffc036553b20 x8 : ffffffc036561650 x7 : ffffffc03fe6cb40 x6 : 0000000000000000 x5 : 0000000000000001 x4 : 0000000000000002 x3 : ffffffc035659000 x2 : ffffffc0240e8c80 x1 : 0000000000000000 x0 : ffffffc02adbe588 ---[ end trace 13aeec77c3fb55e2 ]--- Call trace: Exception stack(0xffffffc036553990 to 0xffffffc036553ac0) 3980: 0000000000000000 0000008000000000 39a0: ffffffc036553b60 ffffff80084f6040 0000000000004ff0 0000000000000038 39c0: ffffffc0365539d0 ffffff800857e098 ffffffc036553a00 ffffff800857e1b0 39e0: ffffffc036553a10 ffffff800857c554 ffffffc0365e8400 ffffffc0365e8400 3a00: ffffffc036553a20 ffffff8008103358 000000000001aad7 ffffff800851b72c 3a20: ffffffc036553a50 ffffff80080e9228 ffffffc02adbe588 0000000000000000 3a40: ffffffc0240e8c80 ffffffc035659000 0000000000000002 0000000000000001 3a60: 0000000000000000 ffffffc03fe6cb40 ffffffc036561650 ffffffc036553b20 3a80: 00000000000008f0 ffffff80089a1690 0000000000000000 0000000000000004 3aa0: ffffffc00a192700 0000000000000000 0000000000000000 0000000000000000 [<ffffff80084f6040>] drm_atomic_helper_wait_for_fences+0xe0/0xf8 [<ffffff800854176c>] complete_commit.isra.1+0x44/0x1c0 [<ffffff8008541c64>] msm_atomic_commit+0x32c/0x350 [<ffffff8008516230>] drm_atomic_commit+0x50/0x60 [<ffffff8008517548>] drm_atomic_remove_fb+0x158/0x250 [<ffffff80085186d0>] drm_framebuffer_remove+0x50/0x158 [<ffffff8008518818>] drm_mode_rmfb_work_fn+0x40/0x58 [<ffffff80080d5668>] process_one_work+0x1d0/0x378 [<ffffff80080d5a54>] worker_thread+0x244/0x488 [<ffffff80080db7fc>] kthread+0xfc/0x128 [<ffffff8008082ec0>] ret_from_fork+0x10/0x50 Fixes: 9626014 ("drm/fence: add in-fences support") Cc: stable@vger.kernel.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-by: Stanimir Varbanov <stanimir.varbanov@linaro.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
| * drm/msm: select PM_OPPRob Clark2017-05-271-0/+1
| | | | | | | | | | | | | | | | Otherwise, if nothing else enabled selects it, dev_pm_opp_of_add_table() will return -ENOTSUPP. Fixes: e2af8b6 ("drm/msm: gpu: Use OPP tables if we can") Signed-off-by: Rob Clark <robdclark@gmail.com>
* | drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPIRobert Foss2017-05-221-15/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI as a convenience. Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up through the atomic API, but realizing that userspace is likely to take shortcuts and assume that the enum values are what is sent over the wire. As a result these defines are provided purely as a convenience to userspace applications. Changes since v3: - Switched away from past tense in comments - Add define name change to previously mis-spelled DRM_REFLECT_X comment - Improved the comment for the DRM_MODE_REFLECT_<axis> comment Changes since v2: - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_ - Fix compilation errors - Changed comment formatting - Deduplicated comment lines - Clarified DRM_MODE_PROP_REFLECT_ comment Changes since v1: - Moved defines from drm.h to drm_mode.h - Changed define prefix from DRM_ to DRM_MODE_PROP_ - Updated uses of the defines to the new prefix - Removed include from drm_rect.c - Stopped using the BIT() macro Signed-off-by: Robert Foss <robert.foss@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170519205017.23307-2-robert.foss@collabora.com
* | drm: drop drm_[cm]alloc* helpersMichal Hocko2017-05-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that drm_[cm]alloc* helpers are simple one line wrappers around kvmalloc_array and drm_free_large is just kvfree alias we can drop them and replace by their native forms. This shouldn't introduce any functional change. Changes since v1 - fix typo in drivers/gpu//drm/etnaviv/etnaviv_gem.c - noticed by 0day build robot Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Michal Hocko <mhocko@suse.com>drm: drop drm_[cm]alloc* helpers [danvet: Fixup vgem which grew another user very recently.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170517122312.GK18247@dhcp22.suse.cz
* | drm/msm: fix include notation and remove -Iinclude/drm flagMasahiro Yamada2017-05-1714-42/+43
| | | | | | | | | | | | | | | | | | | | | | | | Include <drm/*.h> instead of relative path from include/drm, then remove the -Iinclude/drm compiler flag. While we are here, sort the touched parts with public headers first. mdp4_kms.h must declare struct device_node to be self-contained. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1493009447-31524-11-git-send-email-yamada.masahiro@socionext.com
* | drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutposDaniel Vetter2017-05-101-37/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence the final timestamps might be a bit off. But since this is an existing bug I'm not going to change it, but just try to be bug-for-bug compatible with the current code. This only applies to radeon&amdgpu. - i915 tries to get it perfect by updating crtc->hwmode when the pipe is off (i.e. vblank->enabled = false). - All other atomic drivers look at crtc->state->adjusted_mode. Those that look at state->requested_mode simply don't adjust their mode, so it's the same. That has two problems: Accessing crtc->state from interrupt handling code is unsafe, and it's updated before we shut down the pipe. For nonblocking modesets it's even worse. For atomic drivers try to implement what i915 does. To do that we add a new hwmode field to the vblank structure, and update it from drm_calc_timestamping_constants(). For atomic drivers that's called from the right spot by the helper library already, so all fine. But for safety let's enforce that. For legacy driver this function is only called at the end (oh the fun), which is broken, so again let's not bother and just stay bug-for-bug compatible. The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos directly to implement ->get_vblank_timestamp in every driver, deleting a lot of code. v2: Completely new approach, trying to mimick the i915 solution. v3: Fixup kerneldoc. v4: Drop the WARN_ON to check that the vblank is off, atomic helpers currently unconditionally call this. Recomputing the same stuff should be harmless. v5: Fix typos and move misplaced hunks to the right patches (Neil). v6: Undo hunk movement (kbuild). Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
* | drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestampDaniel Vetter2017-05-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3: kbuild says v1 was better ... Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch
* | drm/vblank: Switch drm_driver->get_vblank_timestamp to return a boolDaniel Vetter2017-05-101-6/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything else). Again, we DRM_ERROR. - EINVAL is checked at higher levels already, and if we'd use struct drm_crtc * instead of (dev, pipe) it would be real obvious that those are again core bugs. The only valid failure mode is crap hardware that couldn't sample a useful timestamp, to ask the core to just grab a not-so-accurate timestamp. Bool is perfectly fine for that. v2: Also fix up the one caller, I lost that in the shuffling (Jani). v3: Fixup commit message (Neil). Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch
* Merge branch 'msm-next' of git://people.freedesktop.org/~robclark/linux into ↵Dave Airlie2017-04-1134-622/+1568
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm-next Noteworthy changes this time: 1) 4k support for newer chips (ganging up hwpipes and mixers) 2) using OPP bindings for gpu 3) more prep work towards per-process pagetables * 'msm-next' of git://people.freedesktop.org/~robclark/linux: (47 commits) msm/drm: gpu: Dynamically locate the clocks from the device tree drm/msm: gpu: Use OPP tables if we can drm/msm: Hard code the GPU "slow frequency" drm/msm: Add MSM_PARAM_GMEM_BASE drm/msm: Reference count address spaces drm/msm: Make sure to detach the MMU during GPU cleanup drm/msm/mdp5: Enable 3D mux in mdp5_ctl drm/msm/mdp5: Reset CTL blend registers before configuring them drm/msm/mdp5: Assign 'right' mixer to CRTC state drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMs drm/msm/mdp5: Stage right side hwpipes on Right-side Layer Mixer drm/msm/mdp5: Prepare Layer Mixers for source split drm/msm/mdp5: Configure 'right' hwpipe drm/msm/mdp5: Assign a 'right hwpipe' to plane state drm/msm/mdp5: Create mdp5_hwpipe_mode_set drm/msm/mdp5: Add optional 'right' Layer Mixer in CRTC state drm/msm/mdp5: Add a CAP for Source Split drm/msm/mdp5: Remove mixer/intf pointers from mdp5_ctl drm/msm/mdp5: Start using parameters from CRTC state drm/msm/mdp5: Add more stuff to CRTC state ...
| * msm/drm: gpu: Dynamically locate the clocks from the device treeJordan Crouse2017-04-082-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>
| * drm/msm: gpu: Use OPP tables if we canJordan Crouse2017-04-081-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>
| * drm/msm: Hard code the GPU "slow frequency"Jordan Crouse2017-04-085-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>
| * drm/msm: Add MSM_PARAM_GMEM_BASEJordan Crouse2017-04-081-0/+3
| | | | | | | | | | | | | | | | 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>
| * drm/msm: Reference count address spacesJordan Crouse2017-04-086-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>
| * drm/msm: Make sure to detach the MMU during GPU cleanupJordan Crouse2017-04-082-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>
| * drm/msm/mdp5: Enable 3D mux in mdp5_ctlArchit Taneja2017-04-081-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>
| * drm/msm/mdp5: Reset CTL blend registers before configuring themArchit Taneja2017-04-081-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>
| * drm/msm/mdp5: Assign 'right' mixer to CRTC stateArchit Taneja2017-04-083-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>
| * drm/msm/mdp5: Stage border out on base stage if CRTC has 2 LMsArchit Taneja2017-04-081-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>
| * drm/msm/mdp5: Stage right side hwpipes on Right-side Layer MixerArchit Taneja2017-04-082-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>
| * drm/msm/mdp5: Prepare Layer Mixers for source splitArchit Taneja2017-04-081-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>
| * drm/msm/mdp5: Configure 'right' hwpipeArchit Taneja2017-04-082-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>
OpenPOWER on IntegriCloud