- Aug 19, 2019
-
-
Rob Herring authored
This fixes 2 lockdep problems. First, it uses mutex_trylock for the pages_lock. Second, it drops the call to panfrost_mmu_unmap which takes several locks due to runtime PM. The call is not necessary because the unmapping will get done in GEM close instead. Signed-off-by:Rob Herring <robh@kernel.org>
-
Rob Herring authored
Avoids a potential deadlock found by lockdep. Signed-off-by: -
Rob Herring authored
[ 174.218372] Unable to handle kernel paging request at virtual address ffff8000098ed000 [ 174.219072] Mem abort info: [ 174.219323] ESR = 0x96000147 [ 174.219596] Exception class = DABT (current EL), IL = 32 bits [ 174.220158] SET = 0, FnV = 0 [ 174.220432] EA = 0, S1PTW = 0 [ 174.220712] Data abort info: [ 174.220970] ISV = 0, ISS = 0x00000147 [ 174.221310] CM = 1, WnR = 1 [ 174.221583] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000002f51000 [ 174.222172] [ffff8000098ed000] pgd=00000000401f8003, pud=00000000401f7003, pmd=00000000401b1003, pte=00e80000098ed712 [ 174.223261] Internal error: Oops: 96000147 [#1] SMP [ 174.223690] Modules linked in: panfrost gpu_sched [ 174.224110] CPU: 5 PID: 902 Comm: gnome-shell Not tainted 5.3.0-rc1+ #95 [ 174.224694] Hardware name: 96boards Rock960 (DT) [ 174.225100] pstate: 40000005 (nZcv daif -PAN -UAO) [ 174.225528] pc : __dma_inv_area+0x40/0x58 [ 174.225881] lr : arch_sync_dma_for_cpu+0x28/0x30 [ 174.226287] sp : ffff00001321ba30 [ 174.226579] x29: ffff00001321ba30 x28: ffff00001321bd08 [ 174.227045] x27: 0000000000000000 x26: 0000000000000009 [ 174.227511] x25: 0000ffffc1f86170 x24: 0000000000000000 [ 174.227976] x23: 0000000000000000 x22: 0000000000000000 [ 174.228443] x21: 0000000000021000 x20: ffff80003bb2d810 [ 174.228908] x19: 00000000098ed000 x18: 0000000000000000 [ 174.229373] x17: 0000000000000000 x16: ffff800023fd9480 [ 174.229838] x15: 0000000000000000 x14: 0000000000000000 [ 174.230303] x13: 0000000000000000 x12: 0000000000000000 [ 174.230769] x11: 00000000fffb9fff x10: 0000000000000000 [ 174.231234] x9 : 0000000000000000 x8 : ffff800023fd9c18 [ 174.231699] x7 : 0000000000000000 x6 : 00000000ffffffff [ 174.232164] x5 : 0000000000000000 x4 : 0000000000021000 [ 174.232276] Purging 5693440 bytes [ 174.232630] x3 : 000000000000003f x2 : 0000000000000040 [ 174.232634] x1 : ffff80000990e000 x0 : ffff8000098ed000 [ 174.233851] Call trace: [ 174.234071] __dma_inv_area+0x40/0x58 [ 174.234397] dma_direct_sync_single_for_cpu+0x7c/0x80 [ 174.234840] dma_direct_unmap_page+0x80/0x88 [ 174.235214] dma_direct_unmap_sg+0x54/0x80 [ 174.235577] drm_gem_shmem_free_object+0xfc/0x108 [ 174.236009] panfrost_gem_free_object+0x118/0x128 [panfrost] [ 174.236510] drm_gem_object_free+0x18/0x90 [ 174.236871] drm_gem_object_put_unlocked+0x58/0x80 [ 174.237292] drm_gem_object_handle_put_unlocked+0x64/0xb0 [ 174.237764] drm_gem_object_release_handle+0x70/0x98 [ 174.238204] drm_gem_handle_delete+0x64/0xb0 [ 174.238579] drm_gem_close_ioctl+0x28/0x38 [ 174.238938] drm_ioctl_kernel+0xb8/0x110 [ 174.239282] drm_ioctl+0x244/0x3f0 [ 174.239585] do_vfs_ioctl+0xbc/0x910 [ 174.239900] ksys_ioctl+0x78/0xa8 [ 174.240192] __arm64_sys_ioctl+0x1c/0x28 [ 174.240539] el0_svc_common.constprop.0+0x88/0x150 [ 174.240958] el0_svc_handler+0x28/0x78 [ 174.241289] el0_svc+0x8/0xc [ 174.241547] Code: 8a230000 54000060 d50b7e20 14000002 (d5087620) [ 174.242081] ---[ end trace aebddb72b5a04754 ]--- Signed-off-by: -
Rob Herring authored
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:909 in_atomic(): 1, irqs_disabled(): 0, pid: 974, name: glmark2-es2-drm 1 lock held by glmark2-es2-drm/974: CPU: 5 PID: 974 Comm: glmark2-es2-drm Tainted: G W L 5.3.0-rc1+ #94 Hardware name: 96boards Rock960 (DT) Call trace: dump_backtrace+0x0/0x130 show_stack+0x14/0x20 dump_stack+0xc4/0x10c ___might_sleep+0x158/0x228 __might_sleep+0x50/0x88 __mutex_lock+0x58/0x800 mutex_lock_interruptible_nested+0x1c/0x28 drm_gem_shmem_get_pages+0x24/0xa0 drm_gem_shmem_get_pages_sgt+0x48/0xd0 panfrost_mmu_map+0x38/0xf8 [panfrost] panfrost_gem_open+0xc0/0xd8 [panfrost] drm_gem_handle_create_tail+0xe8/0x198 drm_gem_handle_create+0x3c/0x50 panfrost_gem_create_with_handle+0x70/0xa0 [panfrost] panfrost_ioctl_create_bo+0x48/0x80 [panfrost] drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x90/0x168 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc Signed-off-by:
-
- Aug 13, 2019
-
-
Rob Herring authored
Up until now, a single shared GPU address space was used. This is not ideal as there's no protection between processes and doesn't work for supporting the same GPU/CPU VA feature. Most importantly, this will hopefully mitigate Alyssa's fear of WebGL, whatever that is. Most of the changes here are moving struct drm_mm and struct panfrost_mmu objects from the per device struct to the per FD struct. The critical function is panfrost_mmu_as_get() which handles allocating and switching the h/w address spaces. There's 3 states an AS can be in: free, allocated, and in use. When a job runs, it requests an address space and then marks it not in use when job is complete(but stays assigned). The first time thru, we find a free AS in the alloc_mask and assign the AS to the FD. Then the next time thru, we most likely already have our AS and we just mark it in use with a ref count. We need a ref count because we have multiple job slots. If the job/FD doesn't have an AS assigned and there are no free ones, then we pick an allocated one not in use from our LRU list and switch the AS from the old FD to the new one. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Steven Price <steven.price@arm.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by:
-
- Aug 09, 2019
-
-
Rob Herring authored
Increment the driver version to expose the new BO allocation flags. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Steven Price <steven.price@arm.com> Acked-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by:
-
Rob Herring authored
The midgard/bifrost GPUs need to allocate GPU heap memory which is allocated on GPU page faults and not pinned in memory. The vendor driver calls this functionality GROW_ON_GPF. This implementation assumes that BOs allocated with the PANFROST_BO_NOEXEC flag are never mmapped or exported. Both of those may actually work, but I'm unsure if there's some interaction there. It would cause the whole object to be pinned in memory which would defeat the point of this. On faults, we map in 2MB at a time in order to utilize huge pages (if enabled). Currently, once we've mapped pages in, they are only unmapped if the BO is freed. Once we add shrinker support, we can unmap pages with the shrinker. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Acked-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Rob Herring authored
In preparation to handle mapping of page faults, we need the MMU handler to be threaded as code paths take a mutex. As the IRQ may be shared, we can't use the default handler and must disable the MMU interrupts locally. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by:
-
Rob Herring authored
Runtime PM resume and job timeouts both call the same sequence of functions, so consolidate them to a common function. This will make changing the reset related code easier. The MMU also needs some re-initialization on reset, so rework its call. In the process, we hide the address space details within the MMU code in preparation to support multiple address spaces. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Robin Murphy <robin.murphy@arm.com> Cc: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
-
Rob Herring authored
Executable buffers have an alignment restriction that they can't cross 16MB boundary as the GPU program counter is 24-bits. This restriction is currently not handled and we just get lucky. As current userspace assumes all BOs are executable, that has to remain the default. So add a new PANFROST_BO_NOEXEC flag to allow userspace to indicate which BOs are not executable. There is also a restriction that executable buffers cannot start or end on a 4GB boundary. This is mostly avoided as there is only 4GB of space currently and the beginning is already blocked out for NULL ptr detection. Add support to handle this restriction fully regardless of the current constraints. For existing userspace, all created BOs remain executable, but the GPU VA alignment will be increased to the size of the BO. This shouldn't matter as there is plenty of GPU VA space. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by:
-
Rob Herring authored
In preparation to create partial GPU mappings of BOs on page faults, split out the SG list handling of panfrost_mmu_map(). Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed: Steven Price <steven.price@arm.com> Acked-by:
-
Rob Herring authored
Setting the GPU VA when creating the GEM object doesn't allow for any conditional adjustments to the mapping. In preparation to support adjusting the mapping and per FD address spaces, restructure the GEM object creation to map and unmap the GEM object in the GEM object .open() and .close() hooks. While panfrost_gem_free_object() and panfrost_gem_prime_import_sg_table() are not really needed after this commit, keep them as we'll need them in subsequent commits. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Robin Murphy <robin.murphy@arm.com> Reviewed-by:
-
Rob Herring authored
If a driver does its own management of pages, the shmem helper object's pages array could be allocated when a SG table is not. There's not really any good reason to tie putting pages with having a SG table when freeing the object, so just put pages if the pages array is populated. 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> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Rob Herring authored
Panfrost has a need for pages allocated on demand via GPU page faults. When releasing the pages, the only thing preventing using drm_gem_put_pages() is needing to skip over unpopulated pages, so allow for skipping over NULL struct page pointers. 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: dri-devel@lists.freedesktop.org Reviewed-by:
-
- Aug 08, 2019
-
-
Rob Herring authored
Add support for madvise and a shrinker similar to other drivers. This allows userspace to mark BOs which can be freed when there is memory pressure. Unlike other implementations, we don't depend on struct_mutex. The driver maintains a list of BOs which can be freed when the shrinker is called. Access to the list is serialized with the shrinker_lock. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by:
-
Rob Herring authored
Add support to the shmem GEM helpers for tracking madvise state and purging pages. This is based on the msm implementation. The BO provides a list_head, but the list management is handled outside of the shmem helpers as there are different locking requirements. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> 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: Eric Anholt <eric@anholt.net> Acked-by:
-
Rob Herring authored
There's a few features the driver supports which we forgot to remove, so remove them now. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190802195727.1963-1-robh@kernel.org
-
- Aug 07, 2019
-
-
John Keeping authored
Commit 9a61c54b ("drm/rockchip: vop: group vop registers") seems to have unintentionally changed the defintion of this macro. Since it is unused, this was not spotted but any attempt to use it results in compilation errors. Revert to the previous definition. Fixes: 9a61c54b ("drm/rockchip: vop: group vop registers") Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190703095111.29117-1-john@metanate.com
-
Rob Herring authored
This reverts commit 220df83a. Turns out drm_gem_dumb_map_offset really only worked for the dumb buffer case, so revert the name change. Signed-off-by:
Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190807145253.2037-2-sean@poorly.run
-
Rob Herring authored
This reverts commit 583bbf46. Turns out we need mmap to work on imported BOs even if the current code is buggy. Signed-off-by:
-
Emil Velikov authored
The authentication can be circumvented, by design, by using the render node. From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190527081741.14235-11-emil.l.velikov@gmail.com
-
Emil Velikov authored
The authentication can be circumvented, by design, by using the render node. From the driver POV there is no distinction between primary and render nodes, thus we can drop the token. Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: freedreno@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Emil Velikov authored
Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by:
-
Sean Paul authored
This reverts commit ccdae425. Mandatory review was missing from this patch. Acked-by:
Maxime Ripard <maxime.ripard@bootlin.com> Acked-by:
-
Sean Paul authored
This reverts commit 88209d2c. Mandatory review was missing from this patch. Acked-by:
-
Sean Paul authored
This reverts commit e4eee93d. Mandatory review was missing from this patch. Acked-by:
-
Sean Paul authored
This reverts commit be855382. Mandatory review was missing from this patch. Acked-by:
-
Sean Paul authored
This reverts commit 415d2e9e. Mandatory review was missing from this patch. Acked-by:
-
Sam Ravnborg authored
Use the drm_panel_(enable|disable|get_modes) functions. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190804201637.1240-9-sam@ravnborg.org
-
Christian König authored
We can add the exclusive fence to the list after making sure we got a consistent state. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/322034/?series=64786&rev=1
-
Christian König authored
After waiting for a reservation object use reservation_object_test_signaled_rcu to opportunistically prune the fences on the object. This allows removal of the seqcount handling in the reservation object. Signed-off-by:
-
Christian König authored
Add some helpers to correctly allocate/free reservation_object_lists. Otherwise we might forget to drop dma_fence references on list destruction. Signed-off-by:
-
Christian König authored
When reservation_object_add_shared_fence is replacing an old fence with a new one we should not drop the old one before the new one is in place. Otherwise other cores can busy wait for the new one to appear. Signed-off-by:
-
- Aug 06, 2019
-
-
Brian Starkey authored
CRC generation can be impacted by commits coming from userspace, and enabling CRC generation may itself trigger a commit. Add notes about this to the kerneldoc. Changes since v1: - Clarified that anything that would disable CRCs counts as a full modeset, and so userspace needs to reconfigure after full modesets Changes since v2: - Add these notes - Rebase onto drm-misc-next (trivial conflict in comment) Signed-off-by:
Brian Starkey <brian.starkey@arm.com> Signed-off-by:
Ayan Kumar Halder <ayan.halder@arm.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link:- https://patchwork.freedesktop.org/patch/321974/
-
Ramalingam C authored
In the kernel documentation, HDCP specifications links are shared as a reference for SRM table format. v2: Fixed small nits. [Shashank] Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Shashank Sharma <shashank.sharma@intel.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/320968/?series=57232&rev=14
-
Ramalingam C authored
drm function to update the content protection property state and to generate a uevent is invoked from the intel hdcp property work. Hence whenever kernel changes the property state, userspace will be updated with a uevent. v2: state update is moved into drm function [daniel] Signed-off-by:
-
Ramalingam C authored
drm function is defined and exported to update a connector's content protection property state and to generate a uevent along with it. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: Update only when state is different from old one. v3: KDoc is added [Daniel] v4: KDoc is extended bit more [pekka] v5: Uevent usage is documented at kdoc of "Content Protection" also [pekka] Signed-off-by:
-
Ramalingam C authored
DRM API for generating uevent for a status changes of connector's property. This uevent will have following details related to the status change: HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id> Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: Minor fixes at KDoc comments [Daniel] v3: Check the property is really attached with connector [Daniel] v4: Typos and string length suggestions are addressed [Sean] Signed-off-by:
-
Ramalingam C authored
Attaches the content type property for HDCP2.2 capable connectors. Implements the update of content type from property and apply the restriction on HDCP version selection. Need ACK for content type property from userspace consumer. v2: s/cp_content_type/content_protection_type [daniel] disable at hdcp_atomic_check to avoid check at atomic_set_property [Maarten] v3: s/content_protection_type/hdcp_content_type [Pekka] v4: hdcp disable incase of type change is moved into commit [daniel]. v5: Simplified the Type change procedure. [Daniel] v6: Type change with UNDESIRED state is ignored. Signed-off-by:
-
Ramalingam C authored
This patch adds a DRM ENUM property to the selected connectors. This property is used for mentioning the protected content's type from userspace to kernel HDCP authentication. Type of the stream is decided by the protected content providers. Type 0 content can be rendered on any HDCP protected display wires. But Type 1 content can be rendered only on HDCP2.2 protected paths. So when a userspace sets this property to Type 1 and starts the HDCP enable, kernel will honour it only if HDCP2.2 authentication is through for type 1. Else HDCP enable will be failed. Pekka have completed the Weston DRM-backend review in https://gitlab.freedesktop.org/wayland/weston/merge_requests/48 and the UAPI for HDCP 2.2 looks good. The userspace is accepted in Weston. v2: cp_content_type is replaced with content_protection_type [daniel] check at atomic_set_property is removed [Maarten] v3: %s/content_protection_type/hdcp_content_type [Pekka] v4: property is created for the first requested connector and then reused. [Danvet] v5: kernel doc nits addressed [Daniel] Rebased as part of patch reordering. v6: Kernel docs are modified [pekka] v7: More details in Kernel docs. [pekka] v8: Few more clarification into kernel doc of content type [pekka] v9: Small fixes in coding style. v10: Moving DRM_MODE_HDCP_CONTENT_TYPEx definition to drm_hdcp.h [pekka] Signed-off-by:
-
