summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/msm/msm_gpu.c
Commit message (Collapse)AuthorAgeFilesLines
...
* drm/msm: gpu: Add A5XX target supportJordan Crouse2016-11-281-3/+10
| | | | | | | Add support for the A5XX family of Adreno GPUs. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Remove 'src_clk' from adreno configurationJordan Crouse2016-11-281-23/+13Star
| | | | | | | | | | | | | | The adreno code inherited a silly workaround from downstream from the bad old days before decent clock control. grp_clk[0] (named 'src_clk') doesn't actually exist - it was used as a proxy for whatever the core clock actually was (usually 'core_clk'). All targets should be able to correctly request 'core_clk' and get the right thing back so zap the anachronism and directly use grp_clk[0] to control the clock rate. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: convert iova to 64bRob Clark2016-11-281-1/+1
| | | | | | | | | For a5xx the gpu is 64b so we need to change iova to 64b everywhere. On the display side, iova is still 32b so it can ignore the upper bits. (Although all the armv8 devices have an iommu that can map 64b pa to 32b iova.) Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: support multiple address spacesRob Clark2016-11-271-7/+12
| | | | | | | | We can have various combinations of 64b and 32b address space, ie. 64b CPU but 32b display and gpu, or 64b CPU and GPU but 32b display. So best to decouple the device iova's from mmap offset. Signed-off-by: Rob Clark <robdclark@gmail.com>
* dma-buf: Rename struct fence to dma_fenceChris Wilson2016-10-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I plan to usurp the short name of struct fence for a core kernel struct, and so I need to rename the specialised fence/timeline for DMA operations to make room. A consensus was reached in https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html that making clear this fence applies to DMA operations was a good thing. Since then the patch has grown a bit as usage increases, so hopefully it remains a good thing! (v2...: rebase, rerun spatch) v3: Compile on msm, spotted a manual fixup that I broke. v4: Try again for msm, sorry Daniel coccinelle script: @@ @@ - struct fence + struct dma_fence @@ @@ - struct fence_ops + struct dma_fence_ops @@ @@ - struct fence_cb + struct dma_fence_cb @@ @@ - struct fence_array + struct dma_fence_array @@ @@ - enum fence_flag_bits + enum dma_fence_flag_bits @@ @@ ( - fence_init + dma_fence_init | - fence_release + dma_fence_release | - fence_free + dma_fence_free | - fence_get + dma_fence_get | - fence_get_rcu + dma_fence_get_rcu | - fence_put + dma_fence_put | - fence_signal + dma_fence_signal | - fence_signal_locked + dma_fence_signal_locked | - fence_default_wait + dma_fence_default_wait | - fence_add_callback + dma_fence_add_callback | - fence_remove_callback + dma_fence_remove_callback | - fence_enable_sw_signaling + dma_fence_enable_sw_signaling | - fence_is_signaled_locked + dma_fence_is_signaled_locked | - fence_is_signaled + dma_fence_is_signaled | - fence_is_later + dma_fence_is_later | - fence_later + dma_fence_later | - fence_wait_timeout + dma_fence_wait_timeout | - fence_wait_any_timeout + dma_fence_wait_any_timeout | - fence_wait + dma_fence_wait | - fence_context_alloc + dma_fence_context_alloc | - fence_array_create + dma_fence_array_create | - to_fence_array + to_dma_fence_array | - fence_is_array + dma_fence_is_array | - trace_fence_emit + trace_dma_fence_emit | - FENCE_TRACE + DMA_FENCE_TRACE | - FENCE_WARN + DMA_FENCE_WARN | - FENCE_ERR + DMA_FENCE_ERR ) ( ... ) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
* drm/msm: move fence allocation out of msm_gpu_submit()Rob Clark2016-09-151-11/+2Star
| | | | | | Prep work for next patch. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: print offender task name on hangcheck recoveryRob Clark2016-05-081-4/+19
| | | | | | | Track the pid per submit, so we can print the name of the task which submitted the batch that caused the gpu to hang. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: fix leak in failed submit pathRob Clark2016-05-081-3/+1Star
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: drop return from gpu->submit()Rob Clark2016-05-081-2/+2
| | | | | | | | At this point, there is nothing left to fail. And submit already has a fence assigned and is added to the submit_list. Any problems from here on out are asynchronous (ie. hangcheck/recovery). Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: 'struct fence' conversionRob Clark2016-05-081-10/+17
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: introduce msm_fence_contextRob Clark2016-05-081-9/+14
| | | | | | | | Better encapsulate the per-timeline stuff into fence-context. For now there is just a single fence-context, but eventually we'll also have one per-CRTC to enable fully explicit fencing. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm/gpu: simplify tracking in-flight bo'sRob Clark2016-05-081-29/+22Star
| | | | | | | | Since we already track the array of bo's in the submit object, just unconditionally take and drop ref's per submit (rather than only taking ref's if bo is not already active). This simplifies later patches. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: move fence code to it's own fileRob Clark2016-05-081-0/+1
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: Fix IOMMU clean up path in case msm_iommu_new() failsStephane Viau2015-10-221-0/+8
| | | | | | | | | msm_iommu_new() can fail and this change makes sure that we detect the failure and free the allocated domain before going any further. Signed-off-by: Stephane Viau <sviau@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: restart queued submits after hangRob Clark2015-06-111-3/+46
| | | | | | | | | | Track the list of in-flight submits. If the gpu hangs, retire up to an including the offending submit, and then re-submit the remainder. This way, for concurrently running piglit tests (for example), one failing test doesn't cause unrelated tests to fail simply because it's submit was queued up after one that triggered a hang. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: adreno a306 supportRob Clark2015-06-111-0/+1
| | | | | | | | | As found in apq8016 (used in DragonBoard 410c) and msm8916. Note that numerically a306 is actually 307 (since a305c already claimed 306). Nice and confusing. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: clarify downstream bus scalingRob Clark2015-06-111-1/+1
| | | | | | | | | | A few spots in the driver have support for downstream android CONFIG_MSM_BUS_SCALING. This is mainly to simplify backporting the driver for various devices which do not have sufficient upstream kernel support. But the intentionally dead code seems to cause some confusion. Rename the #define to make this more clear. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: fix potential deadlock in gpu initRob Clark2014-08-041-0/+3
| | | | | | | | | | | | | Somewhere along the way, the firmware loader sprouted another lock dependency, resulting in possible deadlock scenario: &dev->struct_mutex --> &sb->s_type->i_mutex_key#2 --> &mm->mmap_sem which is problematic vs things like gem mmap. So introduce a separate mutex to synchronize gpu init. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: use upstream iommuRob Clark2014-08-041-8/+1Star
| | | | | | | | | | | | | | | | | Downstream kernel IOMMU had a non-standard way of dealing with multiple devices and multiple ports/contexts. We don't need that on upstream kernel, so rip out the crazy. Note that we have to move the pinning of the ringbuffer to after the IOMMU is attached. No idea how that managed to work properly on the downstream kernel. For now, I am leaving the IOMMU port name stuff in place, to simplify things for folks trying to backport latest drm/msm to device kernels. Once we no longer have to care about pre-DT kernels, we can drop this and instead backport upstream IOMMU driver. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add perf logging debugfsRob Clark2014-06-021-0/+103
| | | | Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add rd logging debugfsRob Clark2014-06-021-0/+4
| | | | | | | | | | To ease debugging, add debugfs file which can be cat/tail'd to log submits, along with fence #. If GPU hangs, you can look at 'gpu' debugfs file to find last completed fence and current register state, and compare with logged rd file to narrow down the DRAW_INDX which triggered the GPU hang. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: crank down gpu when inactiveRob Clark2014-03-311-3/+82
| | | | | | | Shut down the clks when the gpu has nothing to do. A short inactivity timer is used to provide a low pass filter for power transitions. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: bigger synchronization hammerRob Clark2014-02-071-3/+0Star
| | | | | | | | | Because we use a list_head in the bo to track it's position in a submit, we need to serialize at a higher layer. Otherwise there are problems when multiple contexts are SUBMIT'ing in parallel cmdstreams referencing a shared bo. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add support for non-IOMMU systemsRob Clark2014-01-091-8/+11
| | | | | | | | | | | | | | | | | | | | | | Add a VRAM carveout that is used for systems which do not have an IOMMU. The VRAM carveout uses CMA. The arch code must setup a CMA pool for the device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not cool). The user can configure the VRAM pool size using msm.vram module param. Technically, the abstraction of IOMMU behind msm_mmu is not strictly needed, but it simplifies the GEM code a bit, and will be useful later when I add support for a2xx devices with GPUMMU, so I decided to keep this part. It appears to be possible to configure the GPU to restrict access to addresses within the VRAM pool, but this is not done yet. So for now the GPU will refuse to load if there is no sort of mmu. Once address based limits are supported and tested to confirm that we aren't giving the GPU access to arbitrary memory, this restriction can be lifted Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: fix bus scalingRob Clark2014-01-091-15/+5Star
| | | | | | | This got a bit broken with original patches when re-arranging things to move dependencies on mach-msm inside #ifndef OF. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: rework inactive-workRob Clark2013-11-011-2/+2
| | | | | | | | | | | | Re-arrange things a bit so that we can get work requested after a bo fence passes, like pageflip, done before retiring bo's. Without any sort of bo cache in userspace, some games can trigger hundred's of transient bo's, which can cause retire to take a long time (5-10ms). Obviously we want a bo cache.. but this cleanup will make things a bit easier for atomic as well and makes things a bit cleaner. Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: David Brown <davidb@codeaurora.org>
* drm/msm: fix potential NULL pointer dereferenceWei Yongjun2013-09-121-1/+2
| | | | | | The dereference to 'pdata' should be moved below the NULL test. Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
* drm/msm: workaround for missing irqRob Clark2013-09-111-2/+5
| | | | | | | | Occasionally we seem to miss an IRQ from the ME (microengine). I'm not entirely sure the root cause, but for now we can unwedge things by retiring from the hangcheck timer. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: hangcheck harderRob Clark2013-09-101-1/+8
| | | | | | | | | | | | | | If gpu locks up with the rptr shortly beyond the wrap-around point in the ringbuffer, because the rptr was not reset (but wptr is, by virtue of resetting rb->cur), we could end up in a scenario where we think there is not enough space in the ringbuffer for the next cmds. And since the CP won't reset rptr until after processing an IB, this leaves things in a sort of deadlock. So reset rptr too. And a bit more spiffing up of hangcheck to make things easier to debug. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: handle read vs write fencesRob Clark2013-09-101-2/+7
| | | | | | | | | The userspace API already had everything needed to handle read vs write synchronization. This patch actually bothers to hook it up properly, so that we don't need to (for example) stall on userspace read access to a buffer that gpu is also still reading. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add basic hangcheck/recovery mechanismRob Clark2013-08-241-0/+52
| | | | | | | | | | A basic, no-frills recovery mechanism in case the gpu gets wedged. We could try to be a bit more fancy and restart the next submit after the one that got wedged, but for now keep it simple. This is enough to recover things if, for example, the gpu hangs mid way through a piglit run. Signed-off-by: Rob Clark <robdclark@gmail.com>
* drm/msm: add a3xx gpu supportRob Clark2013-08-241-0/+411
Add initial support for a3xx 3d core. So far, with hardware that I've seen to date, we can have: + zero, one, or two z180 2d cores + a3xx or a2xx 3d core, which share a common CP (the firmware for the CP seems to implement some different PM4 packet types but the basics of cmdstream submission are the same) Which means that the eventual complete "class" hierarchy, once support for all past and present hw is in place, becomes: + msm_gpu + adreno_gpu + a3xx_gpu + a2xx_gpu + z180_gpu This commit splits out the parts that will eventually be common between a2xx/a3xx into adreno_gpu, and the parts that are even common to z180 into msm_gpu. Note that there is no cmdstream validation required. All memory access from the GPU is via IOMMU/MMU. So as long as you don't map silly things to the GPU, there isn't much damage that the GPU can do. Signed-off-by: Rob Clark <robdclark@gmail.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-03 22:49:03 +0200