summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/panfrost/panfrost_gpu.c
AgeCommit message (Collapse)AuthorFilesLines
2022-05-26drm/panfrost: Add Mali-G57 "Natt" supportAlyssa Rosenzweig1-0/+3
Add the features, issues, and GPU ID for Mali-G57, a first-generation Valhall GPU. Other first- and second-generation Valhall GPUs should be similar. v2: Split out issue list for r0p0 from newer Natt GPUs, as TTRX_3485 was fixed in r0p1. Unfortunately, MT8192 has a r0p0, so we do need to handle TTRX_3485. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-9-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Don't set L2_MMU_CONFIG quirksAlyssa Rosenzweig1-12/+0
L2_MMU_CONFIG is an implementation-defined register. Different Mali GPUs define slightly different MAX_READS and MAX_WRITES fields, which throttle outstanding reads and writes when set to non-zero values. When left as zero, reads and writes are not throttled. Both kbase and panfrost always zero these registers. Per discussion with Steven Price, there are two reasons these quirks may be used: 1. Simulating slower memory subsystems. This use case is only of interest to system-on-chip designers; it is not relevant to mainline. 2. Working around broken memory subsystems. Hopefully we never see this case in mainline. If we do, we'll need to set this register based on an SoC-compatible, rather than generally matching on the GPU model. To the best of our knowledge, these fields are zero at reset, so the write is not necessary. Let's remove the write to aid porting to new Mali GPUs, which have different layouts for the L2_MMU_CONFIG register. Suggested-by: Steven Price <steven.price@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-8-alyssa.rosenzweig@collabora.com
2022-05-26drm/panfrost: Handle HW_ISSUE_TTRX_2968_TTRX_3162Alyssa Rosenzweig1-0/+3
Add handling for the HW_ISSUE_TTRX_2968_TTRX_3162 quirk. Logic ported from kbase. kbase lists this workaround as used on Mali-G57. Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220525145754.25866-3-alyssa.rosenzweig@collabora.com
2022-02-11drm/panfrost: Handle IDVS_GROUP_SIZE featureAlyssa Rosenzweig1-0/+3
The IDVS group size feature was missing. It is used on some Bifrost and Valhall GPUs, and is the last kernel-relevant Bifrost feature we're missing. This feature adds an extra IDVS group size field to the JM_CONFIG register. In kbase, the value is configurable via the device tree; kbase uses 0xF as a default if no value is specified. Until we find a device demanding otherwise, let's always set the 0xF default on devices which support this feature mimicking kbase's behaviour. Tuning this register slightly improves performance of index-driven vertex shading. On Mali-G52 (with Mesa), overall glmark2 score is improved from 1026 to 1037. Geometry-heavy scenes like -bshading are improved from 1068 to 1098. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220211145849.3148-1-alyssa.rosenzweig@collabora.com
2022-01-17drm/panfrost: initial dual core group GPUs supportAlexey Sheplyakov1-5/+22
On a dual core group GPUs (such as T628) fragment shading can be performed over all cores (because a fragment shader job doesn't need coherency between threads), however vertex shading requires to be run on the same core group as the tiler (which always lives in core group 0). As a first step to support T628 power on only the first core group (so no jobs are scheduled on the second one). This makes T628 look like every other Midgard GPU (and throws away up to half the cores). With this patch panfrost is able to drive T628 (r1p0) GPU on some armv8 SoCs (in particular BE-M1000). Without the patch rendering is horribly broken (desktop is completely unusable) and eventually the GPU locks up (it takes from a few seconds to a couple of minutes). Using the second core group requires support in Mesa (and an UABI change): the userspace should 1) set PANFROST_JD_DOESNT_NEED_COHERENCY_ON_GPU flag to opt-in to allowing the job to run across all cores. 2) set PANFROST_RUN_ON_SECOND_CORE_GROUP flag to allow compute jobs to be run on the second core group (at the moment Mesa does not advertise compute support on anything older than Mali T760) But there's little point adding such flags until someone (myself) steps up to do the Mesa work. Signed-off-by: Alexey Sheplyakov <asheplyakov@basealt.ru> Signed-off-by: Vadim V. Vlasov <vadim.vlasov@elpitech.ru> Tested-by: Alexey Sheplyakov <asheplyakov@basealt.ru> Co-developed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220115160658.582646-1-asheplyakov@basealt.ru
2022-01-12drm/panfrost: Check for error num after setting maskJiasheng Jiang1-1/+4
Because of the possible failure of the dma_supported(), the dma_set_mask_and_coherent() may return error num. Therefore, it should be better to check it and return the error if fails. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> [Steve: fix Fixes: line] Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220106030326.2620942-1-jiasheng@iscas.ac.cn
2021-07-12drm/panfrost:fix the exception name always "UNKNOWN"ChunyouTang1-1/+1
The exception_code in register is only 8 bits,So if fault_status in panfrost_gpu_irq_handler() don't (& 0xFF),it can't get correct exception reason. and it's better to show all of the register value to custom,so it's better fault_status don't (& 0xFF). Signed-off-by: ChunyouTang <tangchunyou@icubecorp.cn> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708073407.2015-1-tangchunyou@163.com
2021-07-01drm/panfrost: Drop the pfdev argument passed to panfrost_exception_name()Boris Brezillon1-1/+1
Currently unused. We'll add it back if we need per-GPU definitions. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210630062751.2832545-6-boris.brezillon@collabora.com
2021-06-04drm/panfrost: Add AFBC_FEATURES parameterAlyssa Rosenzweig1-0/+1
The value of the AFBC_FEATURES register is required by userspace to determine AFBC support on Bifrost. A user on our IRC channel (#panfrost) reported a workload that raised a fault on one system's Mali G31 but worked flawlessly with another system's Mali G31. We determined the cause to be missing AFBC support on one vendor's Mali implementation -- it turns out AFBC is optional on Bifrost! Whether AFBC is supported or not is exposed in the AFBC_FEATURES register on Bifrost, which reads back as 0 on Midgard. A zero value indicates AFBC is fully supported, provided the architecture itself supports AFBC, allowing backwards-compatibility with Midgard. Bits 0 and 15 indicate that AFBC support is absent for texturing and rendering respectively. The user experiencing the fault reports that AFBC_FEATURES reads back 0x10001 on their system, confirming the architectural lack of AFBC. Userspace needs this parameter to know to disable AFBC on that chip, and perhaps others. v2: Fix typo from copy-paste fail. v3: Bump the UABI version. This commit was cherry-picked from another series so chalking this up to a rebase fail. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Cc: Rob Herring <robh@kernel.org> Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210604130011.3203-1-alyssa.rosenzweig@collabora.com
2020-10-09drm/panfrost: increase readl_relaxed_poll_timeout valuesChristian Hewitt1-2/+2
Amlogic SoC devices report the following errors frequently causing excessive dmesg log spam and early log rotataion, although the errors appear to be harmless as everything works fine: [ 7.202702] panfrost ffe40000.gpu: error powering up gpu L2 [ 7.203760] panfrost ffe40000.gpu: error powering up gpu shader ARM staff have advised increasing the timeout values to eliminate the errors in most normal scenarios, and testing with several different G31/G52 devices shows 20000 to be a reliable value. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Suggested-by: Steven Price <steven.price@arm.com> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201008141738.13560-1-christianshewitt@gmail.com
2020-09-21drm/panfrost: add amlogic reset quirk callbackNeil Armstrong1-0/+11
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM, G12A/SM1 & G12B SoCs needs a quirk in the PWR registers at the GPU reset time. Since the Amlogic's integration of the GPU cores with the SoC is not publicly documented we do not know what does these values, but they permit having a fully functional GPU running with Panfrost. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> [Steven: Fix typo in commit log] Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-3-narmstrong@baylibre.com
2020-09-21drm/panfrost: add support for vendor quirkNeil Armstrong1-0/+4
The T820, G31 & G52 GPUs integrated by Amlogic in the respective GXM, G12A/SM1 & G12B SoCs needs a quirk in the PWR registers after each reset. This adds a callback in the device compatible struct of permit this. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> [Steven: Fix typo in commit log] Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200916150147.25753-2-narmstrong@baylibre.com
2020-09-10drm/panfrost: Ensure GPU quirks are always initialisedSteven Price1-1/+2
The GPU 'CONFIG' registers used to work around hardware issues are cleared on reset so need to be programmed every time the GPU is reset. However panfrost_device_reset() failed to do this. To avoid this in future instead move the call to panfrost_gpu_init_quirks() to panfrost_gpu_power_on() so that the regsiters are always programmed just before the cores are powered. Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200909122957.51667-1-steven.price@arm.com
2020-09-10drm/panfrost: Set DMA max segment sizeRobin Murphy1-0/+1
Since all we do with scatterlists is map them in the MMU, we don't have any hardware constraints on how they're laid out. Let the DMA layer know so it won't warn when DMA API debugging is enabled. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/04371bc36512076b7feee07f854e56b80675d953.1599141563.git.robin.murphy@arm.com
2020-08-07drm/panfrost: Make sure GPU is powered on when reading GPU_LATEST_FLUSH_IDTomeu Vizoso1-2/+12
Bifrost devices do support the flush reduction feature, so on first job submit we were trying to read the register while still powered off. If the GPU is powered off, the feature doesn't bring any benefit, so don't try to read. Tested-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200611085900.49740-1-tomeu.vizoso@collabora.com
2020-02-25drm/panfrost: Improve error reporting in panfrost_gpu_power_onNicolas Boichat1-4/+7
It is useful to know which component cannot be powered on. Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200207052627.130118-4-drinkcat@chromium.org
2020-01-21drm/panfrost: Prefix interrupt handlers' namesEzequiel Garcia1-1/+1
Currently, the interrupt lines requested by Panfrost use unmeaningful names, which adds some obscurity to interrupt introspection (i.e. any tool based on procfs' interrupts file). In order to improve this, prefix each requested interrupt with the module name: panfrost-{gpu,job,mmu}. Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191214045952.9452-1-ezequiel@collabora.com
2020-01-21drm/panfrost: Remove core stack power managementSteven Price1-5/+0
Explicit management of the GPU's core stacks is only necessary in the case of a broken integration with the PDC. Since there are no known platforms which have such a broken integration let's remove the explicit control from the driver since this apparently causes problems on other platforms and will have a small performance penality. The out of tree mali_kbase driver contains this text regarding controlling the core stack (CONFIGMALI_CORESTACK): Enabling this feature on supported GPUs will let the driver powering on/off the GPU core stack independently without involving the Power Domain Controller. This should only be enabled on platforms which integration of the PDC to the Mali GPU is known to be problematic. This feature is currently only supported on t-Six and t-HEx GPUs. If unsure, say N. Signed-off-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200109133104.11661-1-steven.price@arm.com
2019-10-14drm/panfrost: Add missing GPU feature registersSteven Price1-0/+3
Three feature registers were declared but never actually read from the GPU. Add THREAD_MAX_THREADS, THREAD_MAX_WORKGROUP_SIZE and THREAD_MAX_BARRIER_SIZE so that the complete set are available. Fixes: 4bced8bea094 ("drm/panfrost: Export all GPU feature registers") Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191014151515.13839-1-steven.price@arm.com
2019-07-25drm/panfrost: Export all GPU feature registersSteven Price1-0/+2
Midgard/Bifrost GPUs have a bunch of feature registers providing details of what the hardware supports. Panfrost already reads these, this patch exports them all to user space so that the jobs created by the user space driver can be tuned for the particular hardware implementation. Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190724105626.53552-1-steven.price@arm.com
2019-06-18drm/panfrost: Expose performance counters through unstable ioctlsBoris Brezillon1-0/+7
Expose performance counters through 2 driver specific ioctls: one to enable/disable the perfcnt block, and one to dump the counter values. There are discussions to expose global performance monitors (those counters that can't be retrieved on a per-job basis) in a consistent way, but this is likely to take time to settle on something that works for various HW/users. The ioctls are marked unstable so we can get rid of them when the time comes. We initally went for a debugfs-based interface, but this was making the transition to per-FD address space more complicated (we need to specify the namespace the GPU has to use when dumping the perf counters), hence the decision to switch back to driver specific ioctls which are passed the FD they operate on and thus will have a dedicated address space attached to them. Other than that, the implementation is pretty simple: it basically dumps all counters and copy the values to a userspace buffer. The parsing is left to userspace which has to know the specific layout that's used by the GPU (layout differs on a per-revision basis). Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618081648.17297-5-boris.brezillon@collabora.com
2019-06-18drm/panfrost: Move gpu_{write, read}() macros to panfrost_regs.hBoris Brezillon1-3/+0
So they can be used from other files. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190618081648.17297-2-boris.brezillon@collabora.com
2019-05-03drm/panfrost: Show stored feature registersRobin Murphy1-7/+7
Re-reading the feature registers for the sake of displaying the raw values seems pointless, and in fact showing the copies that we've already read and stored is arguably more useful in terms of giving exposure to any potential bugs in that part of the process. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/ce5e414adb008baeed9e2ceb9c88f28d5c74ea42.1556195258.git.robin.murphy@arm.com
2019-05-03drm/panfrost: Set DMA masks earlierRobin Murphy1-0/+5
The DMA masks need to be set correctly before any DMA API activity kicks off, and the current point in panfrost_probe() is way too late in that regard. since panfrost_mmu_init() has already set up a live address space and DMA-mapped MMU pagetables. We can't set masks until we've queried the appropriate value from MMU_FEATURES, but as soon as reasonably possible after that should suffice. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/64361b929a5c61d2ab9580262ecb3d369164cfcb.1556195258.git.robin.murphy@arm.com
2019-04-12drm/panfrost: Add initial panfrost driverRob Herring1-0/+362
This adds the initial driver for panfrost which supports Arm Mali Midgard and Bifrost family of GPUs. Currently, only the T860 and T760 Midgard GPUs have been tested. v2: - Add GPU reset on job hangs (Tomeu) - Add RuntimePM and devfreq support (Tomeu) - Fix T760 support (Tomeu) - Add a TODO file (Rob, Tomeu) - Support multiple in fences (Tomeu) - Drop support for shared fences (Tomeu) - Fill in MMU de-init (Rob) - Move register definitions back to single header (Rob) - Clean-up hardcoded job submit todos (Rob) - Implement feature setup based on features/issues (Rob) - Add remaining Midgard DT compatible strings (Rob) v3: - Add support for reset lines (Neil) - Add a MAINTAINERS entry (Rob) - Call dma_set_mask_and_coherent (Rob) - Do MMU invalidate on map and unmap. Restructure to do a single operation per map/unmap call. (Rob) - Add a missing explicit padding to struct drm_panfrost_create_bo (Rob) - Fix 0-day error: "panfrost_devfreq.c:151:9-16: ERROR: PTR_ERR applied after initialization to constant on line 150" - Drop HW_FEATURE_AARCH64_MMU conditional (Rob) - s/DRM_PANFROST_PARAM_GPU_ID/DRM_PANFROST_PARAM_GPU_PROD_ID/ (Rob) - Check drm_gem_shmem_prime_import_sg_table() error code (Rob) - Re-order power on sequence (Rob) - Move panfrost_acquire_object_fences() before scheduling job (Rob) - Add NULL checks on array pointers in job clean-up (Rob) - Rework devfreq (Tomeu) - Fix devfreq init with no regulator (Rob) - Various WS and comments clean-up (Rob) Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Marty E. Plummer <hanetzer@startmail.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190409205427.6943-4-robh@kernel.org
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-20 07:49:02 +0000