- 02 12月, 2017 1 次提交
-
-
由 Philipp Zabel 提交于
The etnaviv driver causes a link failure if it is built-in but THERMAL is built as a module: drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_bind': etnaviv_gpu.c:(.text+0x4c4): undefined reference to `thermal_of_cooling_device_register' etnaviv_gpu.c:(.text+0x600): undefined reference to `thermal_cooling_device_unregister' drivers/gpu/drm/etnaviv/etnaviv_gpu.o: In function `etnaviv_gpu_unbind': etnaviv_gpu.c:(.text+0x2aac): undefined reference to `thermal_cooling_device_unregister' Adding a Kconfig dependency on THERMAL || !THERMAL to avoid this causes a dependency loop on x86_64: drivers/gpu/drm/tve200/Kconfig:1:error: recursive dependency detected! For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/tve200/Kconfig:1: symbol DRM_TVE200 depends on CMA For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" mm/Kconfig:489: symbol CMA is selected by DRM_ETNAVIV For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/etnaviv/Kconfig:2: symbol DRM_ETNAVIV depends on THERMAL For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/thermal/Kconfig:5: symbol THERMAL is selected by ACPI_VIDEO For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/acpi/Kconfig:189: symbol ACPI_VIDEO is selected by BACKLIGHT_CLASS_DEVICE For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/video/backlight/Kconfig:158: symbol BACKLIGHT_CLASS_DEVICE is selected by DRM_PARADE_PS8622 For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/bridge/Kconfig:62: symbol DRM_PARADE_PS8622 depends on DRM_BRIDGE For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_BRIDGE is selected by DRM_TVE200 To work around this, add a new option DRM_ETNAVIV_THERMAL to optionally enable thermal throttling support and make DRM_ETNAVIV select THERMAL at the same time. Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
- 03 11月, 2017 1 次提交
-
-
由 Kees Cook 提交于
In preparation for unconditionally passing the struct timer_list pointer to all timer callbacks, switch to using the new timer_setup() and from_timer() to pass the timer pointer explicitly. Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: David Airlie <airlied@linux.ie> Cc: etnaviv@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: NKees Cook <keescook@chromium.org>
-
- 10 10月, 2017 12 次提交
-
-
由 Philipp Zabel 提交于
There is no reason to wait for clock stabilization here, as the clock framework guarantees that PLL clock sources are stable before clk_enable returns. Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Philipp Zabel 提交于
After reset assertion, we only have to wait for the reset signals to propagate through the GPU before deasserting the reset again. A few hundred clock cycles should be more than enough. Replace the msleep(1), which can actually take about 30 ms on i.MX6Q in some configurations, with an usleep_range of a few microseconds. If the delay was too short, the FE would not be idle afterwards, and the reset would be retried. Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
This comment is outdated as the driver is taking care about clock gating and the pulse eater for quite some time already. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
-
由 Christian Gmeiner 提交于
Some performance register are debug register and they need to be enabled in order to be functional. Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: NLucas Stach <l.stach@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Christian Gmeiner 提交于
As done by Vivante kernel driver. Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: NLucas Stach <l.stach@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Christian Gmeiner 提交于
With 'sync points' we can sample the reqeustes perform signals before and/or after the submited command buffer. Changes v2 -> v3: - fixed indentation and init nr_events to 1 Changes v4 -> v5: - simplify logic around fence handling. Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Christian Gmeiner 提交于
Results in less code as the users do not set every struct member to 0/NULL. Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Reviewed-by: NLucas Stach <l.stach@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Christian Gmeiner 提交于
In order to support performance counters in a sane way we need to provide a method to sync the GPU with the CPU. The GPU can process multpile command buffers/events per irq. With the help of a 'sync point' we can trigger an event and stop the GPU/FE immediately. When the CPU is done with is processing it simply needs to restart the FE and the GPU will process the command stream. Changes from v1 -> v2: - process sync point with a work item to keep irq as fast as possible Changes from v4 -> v5: - renamed pmrs_* to sync_point_* - call event_free(..) in sync_point_worker(..) Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Christian Gmeiner 提交于
This commits extends etnaviv_gpu_cmdbuf_new(..) to define the number of struct etnaviv_perfmon elements gets used. Changes from v1 -> v2: - make use of goto as requested by Lucas Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Christian Gmeiner 提交于
This makes it possible to allocate multiple events under the event spinlock. This change is needed to support 'sync'-points. Changes v2 -> v3: - wait for the completion of all events - use 10sec timeout regardless of the number of events - removed validation if there are enough free events - fixed return value evaluation of event_alloc(..) in etnaviv_gpu_submit(..) Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Christian Gmeiner 提交于
This is prep work to be able to allocate multiple events in one go. Signed-off-by: NChristian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
The reset path wants to initialize the clock control register regardless of the DYNAMIC_FREQUENCY_SCALING feature, so don't call clock update, but explicitly load the register. Also disabling of the debug registers is moved into the reset function, so we always get to the same state after a GPU reset. This means the clock update function should not touch the bits already set in the clock control register, but instead only update the scaling bits. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
-
- 15 8月, 2017 1 次提交
-
-
由 Lucas Stach 提交于
The stub functions returns -ENODEV when trying to register the cooling device, thus failing the GPU bind, rendering the GPU subsystem unusable when CONFIG_THERMAL isn't enabled. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
- 05 5月, 2017 2 次提交
-
-
由 Lucas Stach 提交于
GPU cores with the DYNAMIC_FREQUENCY_SCALING feature bit set expect the platform to provide the clock scaling and ignore any requests to use the internal FSCALE divider. Writes to this register still work, but don't have any effect on the GPU clock frequency. Save the initial core and shader clock frequency and ask the platform to provide a slower clock when cooling is requested. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
PA clock gating can be enabled when the right bugfix bit is present. There are broken revs of GC4000 and GC2000, which need TX clock gating to be disabled. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
- 12 4月, 2017 1 次提交
-
-
由 Wei Yongjun 提交于
Add the missing unlock before return from function etnaviv_gpu_submit() in the error handling case. lst: fixed label name. Fixes: f3cd1b06 ("drm/etnaviv: (re-)protect fence allocation with GPU mutex") CC: stable@vger.kernel.org #4.9+ Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
- 29 3月, 2017 5 次提交
-
-
由 Lucas Stach 提交于
The next patch will need the complete dma_fence, instead of just the seqno, to create the sync_file in etnaviv_ioctl_gem_submit, in case an out_fence_fd is requested. The submit needs to hold a reference to the dma_fence, to avoid raceing with the GPU completing the fence. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Tested-by: NPhilipp Zabel <p.zabel@pengutronix.de> --- New patch in v3.
-
由 Philipp Zabel 提交于
Loosely based on commit f0a42bb5 ("drm/msm: submit support for in-fences"). Unfortunately, struct drm_etnaviv_gem_submit doesn't have a flags field yet, so we have to extend the structure and trust that drm_ioctl will clear the flags for us if an older userspace only submits part of the struct. Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de> Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com> Reviewed-by: NSumit Semwal <sumit.semwal@linaro.org> Reviewed-by: NLucas Stach <l.stach@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Russell King 提交于
Each Vivante GPU contains a clock divider which can divide the GPU clock by 2^n, which can lower the power dissipation from the GPU. It has been suggested that the GC600 on Dove is responsible for 20-30% of the power dissipation from the SoC, so lowering the GPU clock rate provides a way to throttle the power dissiptation, and reduce the temperature when the SoC gets hot. This patch hooks the Etnaviv driver into the kernel's thermal management to allow the GPUs to be throttled when necessary, allowing a reduction in GPU clock rate from /1 to /64 in power of 2 steps. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk> Reviewed-by: NLucas Stach <l.stach@pengutronix.de> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
Make sure the GPU lock is taken, so that fence completion order matches seqno order. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
The fence allocation needs to be protected by the GPU mutex, otherwise the fence seqnos of concurrent submits might not match the insertion order of the jobs in the kernel ring. This breaks the assumption that jobs complete with monotonically increasing fence seqnos. Fixes: d9853490 (drm/etnaviv: take GPU lock later in the submit process) CC: stable@vger.kernel.org #4.9+ Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
- 02 2月, 2017 3 次提交
-
-
由 Lucas Stach 提交于
There are 3 big benefits to suballocating a single big DMA buffer for command submission: 1. Avoid hammering CMA. The old way of allocating and freeing a DMA buffer for each submission was hitting some of the real slow pathes in CMA, as this allocator was not designed for a concurrent small buffers load. 2. Less TLB flushes on IOMMUv2. If a new command buffer is mapped into the GPU address space the MMU TLBs need to be flushed. By having one big buffer statically mapped to the GPU, a lot of those flushes can be avoided. 3. No funky workarounds for GC3000. The FE TLB flush on GC3000 isn't reliable. To work around that we tried to lay out the cmdbufs in the GPU address space in a way to avoid this issue. This hasn't always worked if the address space is crowded. A single statically mapped buffer avoids the erratum completely. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
-
由 Lucas Stach 提交于
Don't call the IOMMU directly, but go through the new cmdbuf abstraction. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
-
由 Lucas Stach 提交于
This will get more complex with the following changes, so move it into its own place. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Reviewed-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
-
- 30 1月, 2017 1 次提交
-
-
由 Wladimir J. van der Laan 提交于
Set up the PULSE_EATER register (0x0010C) in etnaviv_gpu_hw_init. This ports three mostly undocumented model/revision-specific register overrides from the Vivante kernel driver. This is relevant as at least the "disable internal DFS" for revisions > 0x5420 has shown to have a huge impact on shader performance (sped up memory read performance by 7.5x and write performance by 1.5x) on an affected GPU. Signed-off-by: NWladimir J. van der Laan <laanwj@gmail.com> Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
- 03 12月, 2016 1 次提交
-
-
由 Lucas Stach 提交于
On i.MX6SX the physical memory is placed above the 2GB mark, so the GPU linear window has to be moved for the GPU to work at all. This doesn't mix with the FAST_CLEAR feature, as the TS unit doesn't take the linear window offset into account and will corrupt memory when used with a non-zero offset. Move the linear window if it's necessary for the GPU to work, but avoid announcing FAST_CLEAR support to userspace in this case. Signed-off-by: NLucas Stach <l.stach@pengutronix.de> Tested-by: NMarek Vasut <marex@denx.de>
-
- 25 10月, 2016 1 次提交
-
-
由 Chris Wilson 提交于
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: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: NSumit Semwal <sumit.semwal@linaro.org> Acked-by: NChristian König <christian.koenig@amd.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
-
- 15 9月, 2016 11 次提交
-
-
由 Lucas Stach 提交于
If we reset the GPU to get it back into a usable state we lose all context, not just the MMU one. Mark the whole context as lost to trigger a restore of the exec and MMU state. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
GC2000+ on the i.MX6QP is just a re-branded GC3000, lets call it by its real name to avoid confusion in other parts of the driver. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
Bit 30 of the interrupt status signals an MMU exception. Handle this condition properly and dump some useful registers. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
With MMUv2 all buffers need to be mapped through the MMU once it is enabled. Align the buffer size to 4K, as the MMU is only able to map page aligned buffers. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
Split out into a new externally visible function, as the IOMMUv2 code needs this functionality, too. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
Split out into a new externally visible function, as the IOMMUv2 code needs this functionality, too. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
The GPU virtual address for the command buffers differs depending on the IOMMU version. Move the calculation of the iova into etnaviv mmu, to enable proper dispatch. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
The GPU code doesn't need to deal with the IOMMU directly, instead it can all be hidden behind the etnaviv mmu interface. Move the last remaining part into etnaviv mmu. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
So we can call the v2 restore code once it is there. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
It is only relevant for the V1 MMU, so we should not do this in the common code. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-
由 Lucas Stach 提交于
This function has external visibility and only handles the Vivant IOMMU version 1. Rename to make this more clear and allow a clear separation of the different IOMMU versions. Also drop the domain parameter, as we can infer it from the GPU we are dealing with. Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
-