Ursulin; dri-devel@lists.freedesktop.org; kernel-...@igalia.com;
Tvrtko Ursulin; Koenig, Christian; Deucher, Alexander; Luben Tuikov; Daniel
Vetter; amd-...@lists.freedesktop.org; sta...@vger.kernel.org
Betreff: Re: [PATCH] drm/scheduler: Fix drm_sched_entity_set_priority()
On Fri, Jul 19, 2024 at
;
xen-de...@lists.xenproject.org ;
linux-ker...@vger.kernel.org ; Sumit Semwal
; Koenig, Christian ;
linux-me...@vger.kernel.org ;
dri-devel@lists.freedesktop.org ;
linaro-mm-...@lists.linaro.org
Betreff: [PATCH v1 0/3] Add ioctls to map grant refs on the external backing
storage
Hello,
Let
Seconded, there is one include for each hardware version.
At least of hand I don't see a duplicate.
Von: Simon Ser
Gesendet: Donnerstag, 30. September 2021 12:17
An: Guo Zhengkui
Cc: Deucher, Alexander ; Koenig, Christian
; Pan, Xinhui ; David Airlie
; D
__
Von: Matthew Auld
Gesendet: Donnerstag, 9. September 2021 16:56
An: Christian König ; Koenig, Christian
Cc: Thomas Hellström ; ML dri-devel
Betreff: i915 ttm_tt shmem backend
Hi Christian,
We are looking into using shmem as a ttm_tt backend in i915 for cached
system memory objects. We would al
gards,
Christian.
Von: Quan, Evan
Gesendet: Donnerstag, 12. August 2021 04:42
An: Koenig, Christian ; Michel Dänzer
; Deucher, Alexander
Cc: Liu, Leo ; Zhu, James ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Betreff: RE: [PATCH 2/2] drm/a
ttwoch, 11. August 2021 18:52
An: Deucher, Alexander ; Koenig, Christian
Cc: Liu, Leo ; Zhu, James ;
amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org
Betreff: [PATCH 2/2] drm/amdgpu: Use mod_delayed_work in JPEG/UVD/VCE/VCN
ring_end_use hooks
From: Michel Dänzer
In c
Reviewed-by: Christian König
Von: Daniel Gomez
Gesendet: Donnerstag, 18. März 2021 09:32
Cc: dag...@gmail.com ; Daniel Gomez ;
Deucher, Alexander ; Koenig, Christian
; David Airlie ; Daniel Vetter
; amd-...@lists.freedesktop.org
; dri-devel
2021 11:46
An: Daniel Vetter ; Koenig, Christian
; linux-graphics-maintai...@vmware.com
Cc: DRI Development
Betreff: vmwgfx leaking bo pins?
Hi,
I tried latest drm-fixes today and saw a lot of these: Fallout from ttm
rework?
/Thomas
[ 298.404788] WARNING: CPU: 1 PID: 3839 at
drivers/g
Yes, that's a known issue. Patch for the revert is already underway.
Christian.
Am 12.09.2020 10:43 schrieb Borislav Petkov :
Hi,
this patch breaks X on my box - it is fully responsive and I can log in
into it from another machine but both monitors are black and show this:
"The current input ti
Am 09.09.2020 07:29 schrieb Huacai Chen :
Though RADEON_GEM_GTT_WC is initially used for GTT, but this flag is
bound to drm_arch_can_wc_memory(), and if arch doesn't support WC, then
VRAM should not use WC.
NAK, If System memory supports WC is completely independent from the VRAM BAR.
Christian
Sure.
Christian.
Am 29.07.2020 17:30 schrieb "Deucher, Alexander" :
[AMD Public Use]
Christian, Can you cc stable when you apply it to drm-misc?
Alex
From: Kuehling, Felix
Sent: Wednesday, July 29, 2020 10:15 AM
To: Koenig, Christian ;
Am 22.07.2020 18:04 schrieb Wei Yongjun :
The sparse tool complains as follows:
drivers/dma-buf/dma-fence.c:249:25: warning:
symbol 'dma_fence_lockdep_map' was not declared. Should it be static?
This variable is not used outside of dma-fence.c, so this commit
marks it static.
Fixes: 5fbff813a
Am 09.06.2020 18:37 schrieb "Grodzovsky, Andrey" :
On 6/5/20 2:40 PM, Christian König wrote:
> Am 05.06.20 um 16:29 schrieb Andrey Grodzovsky:
>>
>> On 5/11/20 2:45 AM, Christian König wrote:
>>> Am 09.05.20 um 20:51 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
---
Am 06.05.2020 18:00 schrieb Alex Deucher :
On Wed, May 6, 2020 at 10:27 AM Zheng Bin wrote:
>
> Zheng Bin (14):
> drm/radeon: remove comparison to bool in btc_dpm.c
> drm/radeon: remove comparison to bool in ci_dpm.c
> drm/radeon: remove comparison to bool in ni_dpm.c
> drm/radeon: remov
Am 10.04.2020 12:58 schrieb "Pan, Xinhui" :
The delayed delete list is per device which might be very huge. And in
a heavy workload test, the list might always not be empty. That will
trigger any RCU stall warnings or softlockups in non-preemptible kernels
Lets do break out the loops in that case
Am 24.03.2020 13:54 schrieb Geert Uytterhoeven :
Improve the help text for the CONFIG_DMABUF_MOVE_NOTIFY symbol by:
1. Removing duplicated single quotes,
2. Adding a missing subject,
3. Fixing a misspelling of "yet",
4. Wrapping long lines.
Fixes: bb42df4662a44765 ("dma-buf: add dynamic
Yeah, sure go ahead.
It's just that I am out of office because of COVID-19 and won't be able to help
if it goes up in flames :)
Cheers,
Christian
Am 24.03.2020 11:03 schrieb "Thomas Hellström (VMware)"
:
On 3/4/20 11:28 AM, Thomas Hellström (VMware) wrote:
> In order to reduce CPU usage [1]
Am 06.11.19 um 18:51 schrieb Andrey Grodzovsky:
> This reverts commit 3cdf9bd0089723c468d5f6240e54d1afa52e9a04.
>
> We will do a proper fix in next patch.
>
> Signed-off-by: Andrey Grodzovsky
The order of this one and patch #2 needs to be swapped, or otherwise we
have the bug in between those tw
Am 06.11.19 um 12:35 schrieb Pan Bian:
> The reference to object fence is dropped at the end of the loop.
> However, it is dropped again outside the loop. The reference can be
> dropped immediately after calling dma_fence_wait() in the loop and
> thus the dropping operation outside the loop can be
Am 06.11.19 um 10:53 schrieb Pan Bian:
> After dropping the reference of object fence in the loop, it should be
> set to NULL to protecting dropping its reference again outside the loop.
NAK, the actual bug is that we shouldn't drop the fence outside the loop
in the first place.
Just move the dm
Am 06.11.19 um 10:14 schrieb Pan Bian:
> The object fence is not set to NULL after its reference is dropped. As a
> result, its reference may be dropped again if error occurs after that,
> which may lead to a use after free bug. To avoid the issue, fence is
> explicitly set to NULL after dropping i
Am 05.11.19 um 14:50 schrieb Daniel Vetter:
> On Tue, Nov 5, 2019 at 2:39 PM Christian König
> wrote:
>> Am 05.11.19 um 11:52 schrieb Daniel Vetter:
>>> On Tue, Oct 29, 2019 at 11:40:49AM +0100, Christian König wrote:
Implement the importer side of unpinned DMA-buf handling.
Signed-
Am 04.11.19 um 18:37 schrieb Daniel Vetter:
> Full audit of everyone:
>
> - i915, radeon, amdgpu should be clean per their maintainers.
>
> - vram helpers should be fine, they don't do command submission, so
>really no business holding struct_mutex while doing copy_*_user. But
>I haven't ch
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> Remove the interval tree in the driver and rely on the tree maintained by
> the mmu_notifier for delivering mmu_notifier invalidation callbacks.
>
> For some reason amdgpu has a very complicated arrangement where it tries
>
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> find_vma() must be called under the mmap_sem, reorganize this code to
> do the vma check after entering the lock.
>
> Further, fix the unlocked use of struct task_struct's mm, instead use
> the mm from hmm_mirror which has a
Am 28.10.19 um 21:10 schrieb Jason Gunthorpe:
> From: Jason Gunthorpe
>
> The new API is an exact match for the needs of radeon.
>
> For some reason radeon tries to remove overlapping ranges from the
> interval tree, but interval trees (and mmu_range_notifier_insert)
> support overlapping ranges d
Am 25.10.19 um 17:56 schrieb Grodzovsky, Andrey:
> On 10/25/19 11:55 AM, Koenig, Christian wrote:
>> Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
>>> On 10/25/19 4:44 AM, Christian König wrote:
>>>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>>>>
Am 25.10.19 um 16:57 schrieb Grodzovsky, Andrey:
> On 10/25/19 4:44 AM, Christian König wrote:
>> Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
>>> Problem:
>>> When run_job fails and HW fence returned is NULL we still signal
>>> the s_fence to avoid hangs but the user has no way of knowing if
>>
Am 25.10.19 um 12:51 schrieb Steven Price:
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortunately some free callbacks (notably for Panfrost) do sleep.
>
> Instead let's rename drm_sc
Am 25.10.19 um 12:26 schrieb Steven Price:
> On 25/10/2019 10:49, Koenig, Christian wrote:
>> Am 24.10.19 um 18:24 schrieb Steven Price:
>>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>>> it is called as the condition of wait_event_
Am 24.10.19 um 18:24 schrieb Steven Price:
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortuantly some free callbacks (notibly for Panfrost) do sleep.
>
> Instead let's rename drm_sch
Am 21.10.19 um 20:09 schrieb Navid Emamdoost:
> In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
> and returns an errno, before returning the allocated memory for fence
> should be released.
>
> Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
> Si
Am 21.10.19 um 15:57 schrieb Jason Gunthorpe:
> On Sun, Oct 20, 2019 at 02:21:42PM +0000, Koenig, Christian wrote:
>> Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
>>> On Thu, Oct 17, 2019 at 04:47:20PM +, Koenig, Christian wrote:
>>> [SNIP]
>>>
&
Am 18.10.19 um 22:36 schrieb Jason Gunthorpe:
> On Thu, Oct 17, 2019 at 04:47:20PM +0000, Koenig, Christian wrote:
>
>>> get_user_pages/hmm_range_fault() and invalidate_range_start() both are
>>> called while holding mm->map_sem, so they are always serialized.
>
Am 17.10.19 um 14:30 schrieb Gerd Hoffmann:
> On Thu, Oct 17, 2019 at 11:06:33AM +0000, Koenig, Christian wrote:
>> Am 16.10.19 um 14:18 schrieb Christian König:
>>> Am 16.10.19 um 13:51 schrieb Gerd Hoffmann:
>>>> Factor out ttm vma setup to a new function.
>&
Sending once more as text.
Am 17.10.19 um 18:26 schrieb Yang, Philip:
> On 2019-10-17 4:54 a.m., Christian König wrote:
>> Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
>>> On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
> Fro
Am 17.10.2019 18:26 schrieb "Yang, Philip" :
On 2019-10-17 4:54 a.m., Christian König wrote:
> Am 16.10.19 um 18:04 schrieb Jason Gunthorpe:
>> On Wed, Oct 16, 2019 at 10:58:02AM +0200, Christian König wrote:
>>> Am 15.10.19 um 20:12 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
>>>
Am 16.10.19 um 14:18 schrieb Christian König:
> Am 16.10.19 um 13:51 schrieb Gerd Hoffmann:
>> Factor out ttm vma setup to a new function.
>> Reduces code duplication a bit.
>>
>> v2: don't change vm_flags (moved to separate patch).
>> v4: make ttm_bo_mmap_vma_setup static.
>>
>> Signed-off-by: Ger
Am 16.10.19 um 16:23 schrieb Daniel Vetter:
> On Wed, Oct 16, 2019 at 3:46 PM Koenig, Christian
> wrote:
>> Am 08.10.19 um 10:55 schrieb Daniel Vetter:
>>> On Wed, Oct 02, 2019 at 08:37:50AM +0000, Koenig, Christian wrote:
>>>> Hi Daniel,
>>>>
>&g
Am 08.10.19 um 10:55 schrieb Daniel Vetter:
> On Wed, Oct 02, 2019 at 08:37:50AM +0000, Koenig, Christian wrote:
>> Hi Daniel,
>>
>> once more a ping on this. Any more comments or can we get it comitted?
> Sorry got a bit smashed past weeks, but should be resurrected now b
Am 16.10.19 um 13:51 schrieb Gerd Hoffmann:
> Factor out ttm vma setup to a new function.
> Reduces code duplication a bit.
>
> v2: don't change vm_flags (moved to separate patch).
> v4: make ttm_bo_mmap_vma_setup static.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König for this one
Am 10.10.19 um 16:34 schrieb Alex Deucher:
> AOn Thu, Oct 10, 2019 at 5:54 AM Daniel Vetter wrote:
>> On Thu, Oct 10, 2019 at 6:17 AM Alex Deucher wrote:
>>> [SNIP]
>>> Christian König (22):
>>>drm/amdgpu: use moving fence instead of exclusive for VM updates
>>>drm/amdgpu: reserve
Hi Qiang,
oh, good point. Yes it certainly should.
Looks like I accidentally pushed it to the wrong branch.
Thanks,
Christian.
Am 10.10.19 um 16:27 schrieb Qiang Yu:
> Hi Chris,
>
> This fix has been pushed to drm-misc-next for a while. But Linux
> 5.4-rc kernels still does not have this fix.
>
Am 09.10.19 um 09:47 schrieb Arkadiusz Hiler:
> On Tue, Oct 08, 2019 at 09:13:41AM -0400, Alex Deucher wrote:
>> On Tue, Oct 8, 2019 at 4:04 AM Koenig, Christian
>> wrote:
>>> My git version should be relative new, but I'm usually using thunderbird
>>> to sen
Hi Yizhuo,
Am 10.10.19 um 07:09 schrieb Yizhuo Zhai:
> Hi All:
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:
> The function to_amdgpu_fence() could return NULL, but callers
> in this file does not check the return value but directly dereference it,
> which seems potentially unsafe.
> Such callers i
My git version should be relative new, but I'm usually using thunderbird
to send pull requests not git itself since I want to edit the message
before sending.
How would I do this in a way patchwork likes it with git?
Thanks,
Christian.
Am 07.10.19 um 21:58 schrieb Dave Airlie:
> For some reaso
Am 04.10.2019 18:02 schrieb Steven Price :
On 04/10/2019 16:34, Koenig, Christian wrote:
> Am 04.10.19 um 17:27 schrieb Steven Price:
>> On 04/10/2019 16:03, Neil Armstrong wrote:
>>> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
>>>> On 10/3/19 4:34 AM, Neil Ar
Am 04.10.19 um 17:27 schrieb Steven Price:
> On 04/10/2019 16:03, Neil Armstrong wrote:
>> On 04/10/2019 16:53, Grodzovsky, Andrey wrote:
>>> On 10/3/19 4:34 AM, Neil Armstrong wrote:
Hi Andrey,
Le 02/10/2019 à 16:40, Grodzovsky, Andrey a écrit :
> On 9/30/19 10:52 AM, Hillf Dant
Am 04.10.19 um 13:26 schrieb Das, Nirmoy:
> On 10/4/19 1:13 PM, Koenig, Christian wrote:
>>>> NAK, that is a double free. The bo list entries are freed by
>>>> amdgpu_bo_list_put().
>>> Thanks, didn't realize that.
>> Wait a second, what entries are y
Am 04.10.19 um 13:00 schrieb Das, Nirmoy:
> On 10/4/19 12:44 PM, Koenig, Christian wrote:
>> First of all please send mails regarding amdgpu to the amd-gfx mailing
>> list and not lkml/dri-devel.
> Okay.
>> Am 04.10.19 um 12:17 schrieb Nirmoy Das:
>>> In amdgpu_b
First of all please send mails regarding amdgpu to the amd-gfx mailing
list and not lkml/dri-devel.
Am 04.10.19 um 12:17 schrieb Nirmoy Das:
> In amdgpu_bo_list_ioctl when idr_alloc fails
> don't return without freeing bo list entry.
>
> Fixes: 964d0fbf6301d ("drm/amdgpu: Allow to create BO lists
Am 03.10.19 um 23:40 schrieb Colin King:
> From: Colin Ian King
>
> There is a return statement that is not reachable and a variable that
> is not used. Remove them.
>
> Addresses-Coverity: ("Structurally dead code")
> Fixes: de7b45babd9b ("drm/amdgpu: cleanup creating BOs at fixed location
> (v
Am 03.10.19 um 23:52 schrieb Colin King:
> From: Colin Ian King
>
> The boolean variable pasid_mapping_needed is not initialized and
> there are code paths that do not assign it any value before it is
> is read later. Fix this by initializing pasid_mapping_needed to
> false.
>
> Addresses-Coverit
Am 04.10.19 um 08:57 schrieb Christian König:
> Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
>> The generic tree tree really wants [a, b) intervals, not fully closed.
>> As such convert it to use the new interval_tree_gen.h. Most of the
>> conversions are straightforward, with the exception of per
Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
> The generic tree tree really wants [a, b) intervals, not fully closed.
> As such convert it to use the new interval_tree_gen.h. Most of the
> conversions are straightforward, with the exception of perhaps
> radeon_vm_bo_set_addr(), but semantics have
Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
> The amdgpu_vm interval tree really wants [a, b) intervals,
NAK, we explicitly do need an [a, b[ interval here.
Regards,
Christian.
> not fully closed ones. As such convert it to use the new
> interval_tree_gen.h, and also rename the 'last' endpoint
Hi Daniel,
once more a ping on this. Any more comments or can we get it comitted?
Thanks,
Christian.
Am 24.09.19 um 11:50 schrieb Christian König:
> Am 17.09.19 um 16:56 schrieb Daniel Vetter:
>> [SNIP]
+ /* When either the importer or the exporter
can't handl
Am 02.10.19 um 05:46 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocati
Am 30.09.19 um 23:26 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocati
Am 30.09.19 um 11:51 schrieb Frediano Ziglio:
>> Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
used in a driver.
>>> As far as I can see by your second patch QXL is just using exported
>>> (that is not internal)
Am 27.09.19 um 18:31 schrieb Frediano Ziglio:
>> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
>> used in a driver.
>>
> As far as I can see by your second patch QXL is just using exported
> (that is not internal) functions.
> Not that the idea of making them internal is
Am 30.09.19 um 09:22 schrieb Daniel Vetter:
> On Sun, Sep 22, 2019 at 2:08 PM Qiang Yu wrote:
>> This causes kernel crash when testing lima driver.
>>
>> Cc: Christian König
>> Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu a
>> bit")
>> Signed-off-by: Qiang Yu
> Self
Am 27.09.2019 20:07 schrieb Ilia Mirkin :
On Thu, Sep 26, 2019 at 5:44 PM Ben Skeggs wrote:
>
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
> >
> > Hi guys,
> >
> > while working through more old TTM functionality I stumbled over the
> > io_reserve_lru.
> >
> > Basic idea is that whe
Am 26.09.19 um 23:44 schrieb Ben Skeggs:
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
>> Hi guys,
>>
>> while working through more old TTM functionality I stumbled over the
>> io_reserve_lru.
>>
>> Basic idea is that when this flag is set the driver->io_mem_reserve()
>> callback can re
Am 26.09.19 um 15:43 schrieb Steven Price:
> On 26/09/2019 14:37, Koenig, Christian wrote:
>> Am 26.09.19 um 14:31 schrieb Steven Price:
>>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>>> it is called as the condition of wait_event_
Am 26.09.19 um 14:31 schrieb Steven Price:
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortuantly some free callbacks (notibly for Panfrost) do sleep.
>
> Instead let's rename drm_sch
Am 26.09.19 um 11:47 schrieb Steven Price:
> On 26/09/2019 08:07, Koenig, Christian wrote:
>> Am 25.09.19 um 17:14 schrieb Steven Price:
>>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>>> it is called as the condition of wait_event_
Am 25.09.19 um 16:54 schrieb Huang, Ray:
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Wednesday, September 25, 2019 10:47 PM
>> To: Huang, Ray ; amd-...@lists.freedesktop.org; dri-
>> de...@lists.freedesktop.org; Deucher, Alexander
>>
Am 25.09.19 um 17:14 schrieb Steven Price:
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortunately some free callbacks (notably for Panfrost) do sleep.
>
> Instead let's rename drm_sc
Am 25.09.19 um 16:38 schrieb Huang, Ray:
> Mark a job as secure, if and only if the command
> submission flag has the secure flag set.
>
> v2: fix the null job pointer while in vmid 0
> submission.
> v3: Context --> Command submission.
> v4: filling cs parser with cs->in.flags
>
> Signed-off-by: Hu
Am 25.09.19 um 16:06 schrieb Steven Price:
> On 24/09/2019 10:55, Koenig, Christian wrote:
>> Sorry for the delayed response, have been busy on other stuff last week.
>>
>> Am 17.09.19 um 14:46 schrieb Steven Price:
>>> On 17/09/2019 09:42, Koenig, C
Am 25.09.19 um 15:45 schrieb Huang, Ray:
> From: Alex Deucher
>
> If a buffer object is secure, i.e. created with
> AMDGPU_GEM_CREATE_ENCRYPTED, then the TMZ bit of
> the PTEs that belong the buffer object should be
> set.
>
> v1: design and draft the skeletion of TMZ bits setting on PTEs (Alex)
>
Am 25.09.19 um 15:45 schrieb Huang, Ray:
> Mark a job as secure, if and only if the command
> submission flag has the secure flag set.
>
> v2: fix the null job pointer while in vmid 0
> submission.
> v3: Context --> Command submission.
>
> Signed-off-by: Huang Rui
> Co-developed-by: Luben Tuikov
Am 25.09.19 um 10:07 schrieb Dave Airlie:
> On Sat, 31 Mar 2018 at 06:45, Takashi Iwai wrote:
>> amdgpu driver lacks of modeset module option other drm drivers provide
>> for enforcing or disabling the driver load. Interestingly, the
>> amdgpu_mode variable declaration is already found in the hea
Am 11.09.19 um 17:08 schrieb Thomas Hellström (VMware):
> On 9/11/19 4:06 PM, Koenig, Christian wrote:
>> Am 11.09.19 um 12:10 schrieb Thomas Hellström (VMware):
>> [SNIP]
>>>>> The problem seen in TTM is that we want to be able to change the
>>>>>
Am 24.09.19 um 13:48 schrieb Huang, Ray:
>> -Original Message-
>> From: Koenig, Christian
>> Sent: Thursday, September 12, 2019 7:49 PM
>> To: Huang, Ray
>> Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
>> Deucher, Alexa
Sorry for the delayed response, have been busy on other stuff last week.
Am 17.09.19 um 14:46 schrieb Steven Price:
> On 17/09/2019 09:42, Koenig, Christian wrote:
>> Hi Steven,
>>
>> thought about that issue a bit more and I think I came up with a
>> solution.
&g
Am 17.09.19 um 16:56 schrieb Daniel Vetter:
> [SNIP]
>>> +/* When either the importer or the exporter can't handle
>>> dynamic
>>> + * mappings we cache the mapping here to avoid issues with the
>>> + * reservation object lock.
>>> + */
From: Koenig, Christian
<mailto:christian.koe...@amd.com>
Sent: Saturday, September 21, 2019 7:32 AM
To: Navid Emamdoost
<mailto:navid.emamdo...@gmail.com>
Cc: emamd...@umn.edu<mailto:emamd...@umn.edu>
<mailto:emamd...@umn.edu>;
smcca...@umn.edu
Am 21.09.19 um 00:49 schrieb Navid Emamdoost:
> In amdgpu_vmid_grab_idle, fences is being leaked in one execution path.
> The missing kfree was added.
NAK, the array is freed by the dma_fence_array. This is a double free.
Regards,
Christian.
>
> Signed-off-by: Navid Emamdoost
> ---
> drivers
Am 19.09.19 um 16:28 schrieb Sven Van Asbroeck:
> Hi Christian,
>
> On Thu, Sep 19, 2019 at 4:05 AM Koenig, Christian
> wrote:
>>> +out4:
>>> + kfree(i2s_pdata);
>>> +out3:
>>> + kfree(adev->acp.acp_res);
>>> +out2:
>>
Am 18.09.19 um 21:05 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocati
Am 18.09.19 um 18:09 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocati
Am 17.09.19 um 15:45 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 01:24:10PM +0000, Koenig, Christian wrote:
>> Am 17.09.19 um 15:13 schrieb Daniel Vetter:
>>> On Tue, Sep 17, 2019 at 12:40:51PM +, Koenig, Christian wrote:
>>>> Am 17.09.19 um 14:31 schrieb Da
Am 17.09.19 um 15:13 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 12:40:51PM +0000, Koenig, Christian wrote:
>> Am 17.09.19 um 14:31 schrieb Daniel Vetter:
>>> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>>>> Ping? Any further comment on this
Am 17.09.19 um 14:31 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 02:23:13PM +0200, Christian König wrote:
>> Ping? Any further comment on this or can't we merge at least the locking
>> change?
> I was at plumbers ...
>> Christian.
>>
>> Am 11.09.19 um 12:53 schrieb Christian König:
>>> Am 03.0
Am 17.09.19 um 11:24 schrieb Gerd Hoffmann:
> Not obvious why this is needed. According to Deniel Vetter this is most
> likely a historic artefact dating back to the days where drm drivers
> exposed hardware registers as mmap'able gem objects, to avoid dumping
> touching those registers.
Clearly
Hi Steven,
thought about that issue a bit more and I think I came up with a solution.
What you could do is to split up drm_sched_cleanup_jobs() into two
functions.
One that checks if jobs to be cleaned up are present and one which does
the actual cleanup.
This way we could call drm_sched_clea
Am 17.09.19 um 10:17 schrieb Daniel Vetter:
> On Tue, Sep 17, 2019 at 10:12 AM Christian König
> wrote:
>> Am 17.09.19 um 07:47 schrieb Jani Nikula:
>>> On Mon, 16 Sep 2019, Marek Olšák wrote:
The purpose is to get rid of all PCI ID tables for all drivers in
userspace. (or at least stop
Am 16.09.19 um 16:24 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 10:11 AM Koenig, Christian
> wrote:
>> Hi Steven,
>>
>> the problem seems to be than panfrost is trying to sleep while freeing a
>> job. E.g. it tries to take a mutex.
>>
>> That is
Hi Steven,
the problem seems to be than panfrost is trying to sleep while freeing a
job. E.g. it tries to take a mutex.
That is not allowed any more since we need to free the jobs from atomic
and even interrupt context.
Your suggestion wouldn't work because this way jobs are not freed when
th
Am 13.09.19 um 13:07 schrieb Thomas Hellström (VMware):
> On 9/13/19 12:53 PM, Koenig, Christian wrote:
>> Am 12.09.19 um 20:38 schrieb Thomas Hellström (VMware):
>>> From: Thomas Hellstrom
>>>
>>> Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new re
Am 12.09.19 um 20:38 schrieb Thomas Hellström (VMware):
> From: Thomas Hellstrom
>
> Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
> broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
> VM_FAULT_NOPAGE, prefaulting stops after the second PTE.
>
> Re
Am 12.09.19 um 12:27 schrieb Huang, Ray:
> On Wed, Sep 11, 2019 at 08:13:19PM +0800, Koenig, Christian wrote:
>> Am 11.09.19 um 13:50 schrieb Huang, Ray:
>>> From: Alex Deucher
>>>
>>> If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ
&g
Am 11.09.19 um 12:10 schrieb Thomas Hellström (VMware):
[SNIP]
>>> The problem seen in TTM is that we want to be able to change the
>>> vm_page_prot from the fault handler, but it's problematic since we
>>> have the mmap_sem typically only in read mode. Hence the fake vma
>>> hack. From what I can
Am 11.09.19 um 13:50 schrieb Huang, Ray:
> From: Alex Deucher
>
> If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ bits
> of
> PTEs that belongs that bo should be set. Then psp is able to protect the pages
> of this bo to avoid the access from an "untrust" domain such as CP
Patches #1-#4, #8, #9 are Reviewed-by: Christian König
Patches #10, #11 are Acked-by: Christian König
Patches #7 and the resulting workaround in patch #13 are a clear NAK.
The ttm_mem_reg can't be used like this to get back to the ttm_bo object.
Going to reply separately on patch #14 regardi
I agree with Daniels analysis.
It looks like the problem is simply that PM turns of a block before all
work is done on that block.
Have you opened a bug report yet? If not then that would certainly help
cause it is really hard to extract all necessary information from that
mail thread.
Regard
Am 05.09.19 um 09:05 schrieb Gerd Hoffmann:
> No users left. Drivers either setup vma_offset_manager themself
> (vmwgfx) or pass the gem vma_offset_manager to ttm_bo_device_init
> (all other drivers).
>
> Signed-off-by: Gerd Hoffmann
Patches #4, #5 and #8 in this series are Reviewed-by: Christia
Am 04.09.19 um 10:19 schrieb Thomas Hellström (VMware):
> Hi, Christian,
>
> On 9/4/19 9:33 AM, Koenig, Christian wrote:
>> Am 03.09.19 um 23:05 schrieb Thomas Hellström (VMware):
>>> On 9/3/19 10:51 PM, Dave Hansen wrote:
>>>> On 9/3/19 1:36 PM, Thomas He
1 - 100 of 483 matches
Mail list logo
