This patch fixes:
-Wunused-function
v2: Always enable amdgpu_ras_test().
Signed-off-by: Luben Tuikov
---
tests/amdgpu/ras_tests.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tests/amdgpu/ras_tests.c b/tests/amdgpu/ras_tests.c
index d714be73..f745166b 100644
--- a/tests/amdgpu
-by: Luben Tuikov
---
amdgpu/amdgpu_bo.c | 2 -
tests/amdgpu/basic_tests.c | 7 +-
tests/amdgpu/bo_tests.c | 9 +-
tests/amdgpu/cs_tests.c | 1 +
tests/amdgpu/ras_tests.c | 241 +--
tests/amdgpu/syncobj_tests.c | 2 +-
6 files changed
This patch fixes the following warning:
-Wformat-overflow=
Signed-off-by: Luben Tuikov
---
tests/amdgpu/meson.build | 1 +
tests/amdgpu/ras_tests.c | 41
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/tests/amdgpu/meson.build b/tests
This patch fixes:
-Wunused-function
Signed-off-by: Luben Tuikov
---
tests/amdgpu/ras_tests.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tests/amdgpu/ras_tests.c b/tests/amdgpu/ras_tests.c
index d714be73..4c395382 100644
--- a/tests/amdgpu/ras_tests.c
+++ b/tests
-by: Luben Tuikov
---
amdgpu/amdgpu_bo.c | 2 -
tests/amdgpu/basic_tests.c | 7 +-
tests/amdgpu/bo_tests.c | 9 +-
tests/amdgpu/cs_tests.c | 1 +
tests/amdgpu/ras_tests.c | 241 +--
tests/amdgpu/syncobj_tests.c | 2 +-
6 files changed
This patch fixes the following warning:
-Wformat-overflow=
Signed-off-by: Luben Tuikov
---
tests/amdgpu/meson.build | 1 +
tests/amdgpu/ras_tests.c | 41
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/tests/amdgpu/meson.build b/tests
On 2019-12-06 3:47 a.m., Christian König wrote:
> Am 06.12.19 um 09:03 schrieb Chen, Guchun:
>> [AMD Official Use Only - Internal Distribution Only]
>>
>>
>>
>> -Original Message-
>> From: amd-gfx On Behalf Of Luben
>> Tuikov
>> Sen
On 2019-12-06 3:49 a.m., Christian König wrote:
> Am 06.12.19 um 05:32 schrieb Luben Tuikov:
>> This patch fixes the following warnings:
>> -Wformat=
>> -Wmaybe-uninitialized
>> -Wmisleading-indentation
>> -Wstringop-truncation
>> -Wunused-function
>
On 2019-11-18 12:18 a.m., Aaron Liu wrote:
> This patch enables TMZ bit in FRAME_CONTROL for gfx10.
>
> Signed-off-by: Aaron Liu
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
>
On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui
>
> This patch expand write linear helper for security to submit the command
> with secure context.
>
> v2: refine the function implementation.
> v3: remove amdgpu_cs_ctx_create3.
>
> Signed-off-by: Huang Rui
> Signed-off-by: Aaron
On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui
>
> To align the kernel uapi change from Alex:
>
> "Add a flag to the GEM_CREATE ioctl to create encrypted buffers. Buffers with
> this flag set will be created with the TMZ bit set in the PTEs or engines
> accessing them. This is
Hi Iago,
Thank you for finding and reporting this potential double lock.
Yes indeed, I see it--it can indeed happen.
Now, since the primitives used--macros using "amdgpu_mm_(r|w)reg\(.*\)"--in
"amdgpu_device_vram_access()" do use their own register-access spinlocks,
it maybe wise to remove the
On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> From: Huang Rui
>
> This patch is to add add device handle as input param for exec_cs_helper
> and write_linear_helper.
>
> Because they are needed in security tests.
>
> v2: fix typo that basic tests should be un-secure.
> v3: refine the function
On 2019-11-20 12:24, Christian König wrote:
> Am 20.11.19 um 18:16 schrieb Christian König:
>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>> On 2019-11-19 21:41, Marek Olšák wrote:
>>>> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov >>> <mailto:luben.tui.
On 2019-11-20 13:40, Christian König wrote:
> Am 20.11.19 um 18:50 schrieb Luben Tuikov:
>> On 2019-11-20 12:24, Christian König wrote:
>>> Am 20.11.19 um 18:16 schrieb Christian König:
>>>> Am 20.11.19 um 17:49 schrieb Luben Tuikov:
>>>>> On 2019-11-19
On 2019-11-19 21:41, Marek Olšák wrote:
> On Tue, Nov 19, 2019 at 8:52 PM Luben Tuikov <mailto:luben.tui...@amd.com>> wrote:
>
> On 2019-11-14 10:34 p.m., Aaron Liu wrote:
> > From: Huang Rui mailto:ray.hu...@amd.com>>
> >
> >
lready initialized and
set adev and adev->tmz.
Add "void amdgpu_tmz_set(adev)" to check and set
adev->tmz.* at initialization time. After which
one uses "bool amdgpu_is_tmz(adev)" to query
whether adev supports TMZ.
Also, remove circular header file include.
v2: Remove
2: Remove amdgpu_tmz.[ch] as requested.
v3: Move TMZ into GMC.
Signed-off-by: Luben Tuikov
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 10 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +-
drivers/gpu/drm
On 2019-11-27 3:37 p.m., Alex Deucher wrote:
> On Tue, Nov 26, 2019 at 9:03 PM Luben Tuikov wrote:
>>
>> Implement an accessor of adev->tmz.enabled. Let not
>> code around access it as "if (adev->tmz.enabled)"
>> as the organization may change. Instea
Simplify padding calculations.
v2: Comment update and spacing.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 4
On 2019-11-20 10:02 p.m., Liu, Aaron wrote:
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Luben Tuikov
>> Sent: Thursday, November 21, 2019 9:33 AM
>> To: amd-gfx@lists.freedesktop.org
>> Cc: Deucher, Alexander ; Tuikov, Luben
>> ;
On 2019-11-20 10:21 p.m., Luben Tuikov wrote:
> On 2019-11-20 10:02 p.m., Liu, Aaron wrote:
>>> -Original Message-
>>> From: amd-gfx On Behalf Of
>>> Luben Tuikov
>>> Sent: Thursday, November 21, 2019 9:33 AM
>>> To: amd-gfx@lists.freedeskto
lready initialized and
set adev and adev->tmz.
Add "void amdgpu_tmz_set(adev)" to check and set
adev->tmz.* at initialization time. After which
one uses "bool amdgpu_is_tmz(adev)" to query
whether adev supports TMZ.
Also, remove circular header file include.
v2: Remove
I wonder if we really do need yet another function argument,
thus increasing the argument list, or if the "tmz" boolean
can/is already a property of the job/command/ib/etc., and
if it can indeed be had from the latter entity...?
Regards,
Luben
On 2019-11-18 12:18 a.m., Aaron Liu wrote:
> This
Yep! That's perfect--good job!
Regards,
Luben
On 2019-12-19 04:16, Tianci Yin wrote:
> From: "Tianci.Yin"
>
> The method of getting fb_loc changed from parsing VBIOS to
> taking certain offset from top of VRAM
>
> Change-Id: I053b42fdb1d822722fa7980b2cd9f86b3fdce539
> Signed-off-by:
On 2019-12-18 4:14 a.m., Yin, Tianci (Rico) wrote:
> Hi Kevin,
>
> You mean like this? It's a bit lengthy.
> - ctx->c2p_train_data_offset &= ~(ONE_MiB - 1);
> + ctx->c2p_train_data_offset = ALIGN(ctx->c2p_train_data_offset, ONE_MiB);
>
> - ctx->c2p_train_data_offset =
n
On 2019-12-18 6:12 p.m., Luben Tuikov wrote:
> Simplify padding calculations.
>
> 1. Taking the remainder of a binary value when
> the divisor is a power of two, such as,
> a % 2^n is identical to, a & (2^n - 1) in base-2
> arithmetic, and so expressions like this:
>
& 0x7)) % 8
becomes, simply,
(-ib->length_dw) & 7.
This patch implements all of the above in this code.
v2: Comment update and spacing.
v3: Add 1, 2, 3, above, in this commit message.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/cik_sdma.c | 4 ++--
drivers/gpu
ev->gmc.mc_vram_size -
GDDR6_MEM_TRAINING_OFFSET);
ctx->train_data_size = GDDR6_MEM_TRAINING_DATA_SIZE_IN_BYTES;
And when someone looks at this, they can read down, the assignments, explictly
inline assignment
operators. It's open to see. (And maybe the '=' equal chars would be column
alig
below the original commit
>> text of the single sentence of "Simplify padding calculations." Identical
>> diffstat as v2.
>>
>> Regards,
>> Luben
>>
>> On 2019-12-18 6:12 p.m., Luben Tuikov wrote:
>>> Simplify padding calculations.
>>>
On 2019-12-20 10:27 a.m., Alex Deucher wrote:
> On Thu, Dec 19, 2019 at 9:00 PM Yin, Tianci (Rico) wrote:
>>
>> [AMD Official Use Only - Internal Distribution Only]
>>
>>
>> Hi Luben,
>>
>> May I have your Review-by?
>>
If you'd like--it's completely up to you. If you choose to, like Alex's
Hi Lucas,
Thank you for bringing awareness of this issue, publicly.
As soon as this patch showed up back in November of 2019,
I objected to it, privately.
I suggested to instead use a _list_ to store the "state" of
all jobs of the same state. Then, at any time, timeout interrupt
or whatever, we
Move from a per-CS secure flag (TMZ) to a per-IB
secure flag.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 23 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 3 ---
drivers/gpu/drm/amd/amdgpu
On 2020-02-11 4:27 p.m., Andrey Grodzovsky wrote:
>
> On 2/11/20 10:55 AM, Andrey Grodzovsky wrote:
>> On 2/10/20 4:50 PM, Luben Tuikov wrote:
>>> Hi Lucas,
>>>
>>> Thank you for bringing awareness of this issue, publicly.
>>>
>>> As soo
Move from a per-CS secure flag (TMZ) to a per-IB
secure flag.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 23 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 3 ---
drivers/gpu/drm/amd/amdgpu
Thanks for fixing this Ray.
I think we can simplify the logic introduced in this patch.
Regards,
Luben
On 2020-02-25 8:57 a.m., Huang Rui wrote:
> Since 6643ba1 frame control packets are only issued in presence of secure
> IB(s).
> This causes hangs on some hardware (eg: Raven1). This patch
On 2020-02-25 8:57 a.m., Huang Rui wrote:
> Since 6643ba1 frame control packets are only issued in presence of secure
> IB(s).
> This causes hangs on some hardware (eg: Raven1). This patch restores the
> unconditionnal frame control packets issuing, that's to keep the per-IB logic
> regarding the
I was thinking like something like this, Ray.
It optimizes the body of the loop, and pulls
out invariant conditionals out of the loop,
and a few other optimizations.
Luben Tuikov (1):
drm/amdgpu: Fix per-IB secure flag GFX hang
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 87
MZ we have
to send a stop with TMZ followed by a start with
non-TMZ, and similarly for transitioning from
non-TMZ into TMZ.
This patch implements this, thus fixing the GFX
hang.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 87 +---
drivers/gpu/drm/
Add fine-grained per-ASIC TMZ support.
At the moment TMZ support is experimental for all
ASICs which support it.
Signed-off-by: Luben Tuikov
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 30 -
1 file changed, 20 insertions(+), 10 deletions
On 2020-03-04 10:56, Andrey Grodzovsky wrote:
>
> On 3/3/20 6:14 PM, Luben Tuikov wrote:
>> On 2020-03-03 17:02, Andrey Grodzovsky wrote:
>>> Add the programming sequence.
>>>
>>> v2:
>>> Change donwload wait loop to more efficient.
>>> Mo
Reviewed-by: Luben Tuikov
On 2020-03-04 11:23, Andrey Grodzovsky wrote:
> Add the programming sequence.
>
> v2:
> Change donwload wait loop to more efficient.
> Move C2PMSG_CMD_GFX_USB_PD_FW_VER defintion
>
> v3: Fix lack of loop counter increment typo
>
> v4: R
Reviewed-by: Luben Tuikov
On 2020-03-04 11:23, Andrey Grodzovsky wrote:
> Starts USBC PD FW download and reads back the latest FW version.
>
> v2:
> Move sysfs file creation to late init
> Add locking around PSP calls to avoid concurrent access to PSP's C2P registers
>
>
On 2020-03-03 7:50 a.m., Nirmoy Das wrote:
> implement drm_sched_entity_modify_sched() which can modify existing
> sched_list with a different one. This is going to be helpful when
> userspace changes priority of a ctx/entity then driver can switch to
> corresponding hw shced list for that
On 2020-03-03 7:50 a.m., Nirmoy Das wrote:
> Switch to appropriate sched list for an entity on priority override.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 32 +
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git
On 2020-03-03 7:50 a.m., Nirmoy Das wrote:
> We were changing compute ring priority while rings were being used
> before every job submission which is not recommended. This patch
> sets compute queue priority at mqd initialization for gfx8, gfx9 and
> gfx10.
>
> Policy: make queue 0 of each pipe
On 2020-03-03 7:50 a.m., Nirmoy Das wrote:
> amdgpu statically set priority for compute queues
> at initialization so remove all the functions
> responsible changing compute queue priority dynamically
If this is just a blob of words and not a proper
sentence or paragraph, how can we trust the
On 2020-03-04 4:41 p.m., Luben Tuikov wrote:
> On 2020-03-03 7:50 a.m., Nirmoy Das wrote:
[snip]
>> +case DRM_SCHED_PRIORITY_HIGH_HW:
>> +case DRM_SCHED_PRIORITY_KERNEL:
>> +return AMDGPU_GFX_PIPE_PRIO_HIGH;
>> +default:
>> +r
t; + return -ETIME;
> +done:
> + reg_status = RREG32_SOC15(MP0, 0, mmMP0_SMN_C2PMSG_35);
3. You had _just_ read the register, right before the goto jump.
You do not need to read it again. (Else a race would exist,
and you'd need to poll, _again_.) You shou
On 2020-03-03 14:06, Christian König wrote:
> Am 02.03.20 um 21:47 schrieb Luben Tuikov:
>> On 2020-02-28 2:47 a.m., Christian König wrote:
>>> Am 28.02.20 um 06:08 schrieb Luben Tuikov:
>>>> On 2020-02-27 4:40 p.m., Nirmoy Das wrote:
>>>>&
On 2020-03-02 4:51 p.m., Andrey Grodzovsky wrote:
>
> On 3/2/20 4:19 PM, Luben Tuikov wrote:
>> On 2020-03-02 2:24 p.m., Andrey Grodzovsky wrote:
>>> Add the programming sequence.
>>>
>>> Signed-off-by: Andrey Grodzovsky
>>> ---
&
On 2020-02-26 3:37 p.m., Nirmoy Das wrote:
> We were changing compute ring priority while rings were being used
> before every job submission which is not recommended. This patch
> recreates entity with higher/normal priority sched list when user
> changes ctx's priority.
>
> high/normal priority
On 2020-02-27 4:40 p.m., Nirmoy Das wrote:
> Switch to appropriate sched list for an entity on priority override.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 54 -
> 1 file changed, 53 insertions(+), 1 deletion(-)
>
> diff --git
On 2020-02-26 3:37 p.m., Nirmoy Das wrote:
> init_priority will set second compute queue(gfx8 and gfx9) of a pipe to high
> priority
> and 1st queue to normal priority.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
>
On 2020-02-27 4:40 p.m., Nirmoy Das wrote:
> implement drm_sched_entity_modify_sched() which can modify existing
> sched_list with a different one. This is going to be helpful when
> userspace changes priority of a ctx/entity then driver can switch to
> corresponding hw shced list for that
On 2020-03-05 08:29, Nirmoy Das wrote:
> GPU address should belong to driver not in memory management.
> This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
>
> Signed-off-by: Nirmoy Das
> Acked-by: Huang Rui
> Reviewed-by: Christian König
> ---
>
On 2020-03-05 08:29, Nirmoy Das wrote:
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6
On 2020-03-05 08:29, Nirmoy Das wrote:
> Calculate GPU offset in radeon_bo_gpu_offset without depending on
> bo->offset.
>
> Signed-off-by: Nirmoy Das
> Reviewed-and-tested-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h| 1 +
> drivers/gpu/drm/radeon/radeon_object.h | 16
On 2020-03-05 16:13, Nirmoy wrote:
>
> On 3/5/20 7:42 PM, Luben Tuikov wrote:
>>
>>> A quick search leads me amdgpu_sched_ioctl() which is using
>>> DRM_SCHED_PRIORITY_INVALID
>>>
>>> to indicate a invalid value from userspace. I don't kn
On 2020-03-05 14:37, Ho, Kenny wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
>
> I believe bo->tbo.mem.mem_type is of uint32_t type and not an enum, is the
> index lookup method safe? (i.e., how do you deal with the possibility of
> having value TTM_PL_PRIV or above or are
It is very difficult to find your comment replies when
you do not add an empty line around them.
Do you not see how everyone responds and adds
an empty line around them?
Why don't you?
cont'd below
On 2020-03-05 01:21, Nirmoy wrote:
>
> On 3/4/20 10:41 PM, Luben Tuikov wrote:
>> O
On 2020-02-28 2:47 a.m., Christian König wrote:
> Am 28.02.20 um 06:08 schrieb Luben Tuikov:
>> On 2020-02-27 4:40 p.m., Nirmoy Das wrote:
>>> implement drm_sched_entity_modify_sched() which can modify existing
>>> sched_list with a different one. This is going to be
On 2020-03-02 2:24 p.m., Andrey Grodzovsky wrote:
> Add the programming sequence.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 76
> ++
> 1 file changed, 76 insertions(+)
>
> diff --git
On 2020-03-02 2:24 p.m., Andrey Grodzovsky wrote:
> Starts USBC PD FW download and reads back the latest FW version.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 94
> +
> 1 file changed, 94 insertions(+)
>
> diff --git
On 2020-03-02 2:24 p.m., Andrey Grodzovsky wrote:
> Add the programming sequence.
>
> Signed-off-by: Andrey Grodzovsky
> ---
> drivers/gpu/drm/amd/amdgpu/psp_v11_0.c | 76
> ++
> 1 file changed, 76 insertions(+)
>
> diff --git
On 2020-02-28 2:38 a.m., Christian König wrote:
> Am 28.02.20 um 04:29 schrieb Luben Tuikov:
>> On 2020-02-26 3:37 p.m., Nirmoy Das wrote:
>>> init_priority will set second compute queue(gfx8 and gfx9) of a pipe to
>>> high priority
>>> and 1st queue to
Thanks Christian. I'll take a look and play with it.
Regards,
Luben
On 2020-03-02 7:17 a.m., Christian König wrote:
> Because of a shift in priorities I won't work on TMZ this week.
>
> So attached are a few smaller patches I already prepared, but the bounce copy
> for system eviction is still
On 2020-02-25 18:40, Luben Tuikov wrote:
> On 2020-02-25 8:57 a.m., Huang Rui wrote:
>> Since 6643ba1 frame control packets are only issued in presence of secure
>> IB(s).
>> This causes hangs on some hardware (eg: Raven1). This patch restores the
>> unconditionnal fr
TMZ into TMZ.
>>
>> This patch implements this, thus fixing the GFX
>> hang.
>>
>> Signed-off-by: Luben Tuikov
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 87 +---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +-
>&g
On 2020-02-27 6:47 a.m., Christian König wrote:
> Am 27.02.20 um 12:38 schrieb Huang Rui:
>> Since 6643ba1 frame control packets are only issued in presence of secure
>> IB(s).
>> This causes hangs on some hardware (eg: Raven1). This patch restores the
>> unconditionnal frame control packets
On 2020-02-27 5:10 p.m., Luben Tuikov wrote:
> On 2020-02-27 6:47 a.m., Christian König wrote:
>> Am 27.02.20 um 12:38 schrieb Huang Rui:
>>> Since 6643ba1 frame control packets are only issued in presence of secure
>>> IB(s).
>>> This causes hangs on so
On 2020-02-17 10:08 a.m., Christian König wrote:
> Am 17.02.20 um 15:44 schrieb Alex Deucher:
>> On Fri, Feb 14, 2020 at 7:17 PM Luben Tuikov wrote:
>>> Add a AMDGPU_GEM_CREATE_MASK and use it to check
>>> for valid/invalid GEM create flags coming in from
>&
On 2020-02-17 9:44 a.m., Alex Deucher wrote:
> On Fri, Feb 14, 2020 at 7:17 PM Luben Tuikov wrote:
>>
>> Add a AMDGPU_GEM_CREATE_MASK and use it to check
>> for valid/invalid GEM create flags coming in from
>> userspace.
>>
>> Fix a bug in checking whether
On 2020-02-18 3:27 a.m., Huang Rui wrote:
> On Tue, Feb 18, 2020 at 04:04:15PM +0800, Koenig, Christian wrote:
>> Am 18.02.20 um 07:12 schrieb Huang Rui:
>>> While the current amdgpu doesn't support TMZ, it will return the error if
>>> user
>>> mode would like to allocate secure buffer.
>>>
>>>
small jitter:
$patch -p1 < /tmp/\[PATCH\]\ drm_amdgpu\:\ add\ VM\ update\ fences\ back\ to\
the\ root\ PD.eml
patching file amdgpu_vm.c
Hunk #2 succeeded at 1599 (offset -20 lines).
I've been running 'glxgears' on the root window and 'pinion'
and no problems--clean log.
Tested-by: Luben T
On 2020-02-19 3:20 a.m., Christian König wrote:
> Am 18.02.20 um 22:46 schrieb Luben Tuikov:
>> On 2020-02-17 10:08 a.m., Christian König wrote:
>>> Am 17.02.20 um 15:44 schrieb Alex Deucher:
>>>> On Fri, Feb 14, 2020 at 7:17 PM Luben Tuikov wrote:
>>>
On 2020-02-19 08:53, Nirmoy Das wrote:
> GPU address should belong to driver not in memory management.
> This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
>
> Signed-off-by: Nirmoy Das
> Acked-by: Huang Rui
> Reviewed-by: Christian König
> ---
>
On 2020-02-19 08:53, Nirmoy Das wrote:
> Calculate GPU offset in radeon_bo_gpu_offset without depending on
> bo->offset
>
> Signed-off-by: Nirmoy Das
> Reviewed-and-tested-by: Christian König
> ---
> drivers/gpu/drm/radeon/radeon.h| 1 +
> drivers/gpu/drm/radeon/radeon_object.h | 16
On 2020-02-19 08:53, Nirmoy Das wrote:
> Store ttm bo->offset in struct nouveau_bo instead.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6
On 2020-02-13 05:30, Christian König wrote:
> Am 13.02.20 um 01:54 schrieb Luben Tuikov:
>> Move from a per-CS secure flag (TMZ) to a per-IB
>> secure flag.
>
> Well that seems to make a lot of sense to me, but need to bit of time to
> read into the PM4 handling of TM
On 2020-02-13 09:57, Huang Rui wrote:
> On Thu, Feb 13, 2020 at 11:30:43AM +0100, Christian König wrote:
>> Am 13.02.20 um 01:54 schrieb Luben Tuikov:
>>> Move from a per-CS secure flag (TMZ) to a per-IB
>>> secure flag.
>>
>> Well that seems to make a lot
Add a AMDGPU_GEM_CREATE_MASK and use it to check
for valid/invalid GEM create flags coming in from
userspace.
Fix a bug in checking whether TMZ is supported at
GEM create time.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 11 ++-
include/uapi/drm
I was able to bisect it to this commit:
$git bisect good
6643ba1ff05d252e451bada9443759edb95eab3b is the first bad commit
commit 6643ba1ff05d252e451bada9443759edb95eab3b
Author: Luben Tuikov
Date: Mon Feb 10 18:16:45 2020 -0500
drm/amdgpu: Move to a per-IB secure flag (TMZ)
Move
Run Summary:Type TotalRan Passed Failed Inactive
suites 11 0n/a 00
tests 63 1 1 00
asserts 526725 526725 526725 0 n/a
Elapsed time =0.027 seconds
Regards,
Luben
On 2020-02-19 4:4
Move from a per-CS secure flag (TMZ) to a per-IB
secure flag.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 --
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 23 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 3 ---
drivers/gpu/drm/amd/amdgpu
Looks fine to me as well. Just as Christian said, would have to be approved by
Marek.
Regards,
Luben
On 2020-02-11 9:57 a.m., Deucher, Alexander wrote:
> Yes, correct.
>
> Alex
>
On 2020-01-16 09:43, Nirmoy Das wrote:
> This also replaces old artifacts with a correct one in drm_sched_entity_init()
> declaration
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
> include/drm/gpu_scheduler.h | 10 +-
> 2 files
On 2020-01-21 11:50 a.m., Nirmoy Das wrote:
> Currently we pre-allocate entities and fences for all the HW IPs on
> context creation and some of which are might never be used.
>
> This patch tries to resolve entity/fences wastage by creating entities
> for a HW IP only when it is required.
>
>
Do we have user-space/libs rely on this errno in particular?
On 2020-01-22 9:03 a.m., Christian König wrote:
> That we can't find a PD above the root is expected can only happen if
> we try to update a larger range than actually managed by the VM.
>
> Signed-off-by: Christian König
> ---
>
(c-indent-line-or-region)
Lisp function, when the major mode is "C".) Pressing TAB anywhere
in a line which has already been indented according to mode, does
nothing.
You can also indent the whole file (region) by pressing C-M-\.
>
> On 1/22/20 1:07 AM, Luben Tuikov wrote:
>> O
On 2020-01-22 4:32 a.m., Nirmoy wrote:
>
> On 1/22/20 12:34 AM, Luben Tuikov wrote:
>>
>>> + for (j = 0; j < amdgpu_ctx_num_entities[i]; ++j) {
>>> + struct amdgpu_ctx_entity *entity = >entities[i][j];
>>
On 2020-01-15 12:31, Alex Deucher wrote:
> Switch to a blacklist so we can disable specific boards
> that are problematic.
>
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 42 ---
> 1 file changed, 38 insertions(+), 4 deletions(-)
>
> diff
On 2020-01-17 5:59 a.m., Nirmoy wrote:
> Hi Luben,
>
> On 1/16/20 6:13 PM, Luben Tuikov wrote:
>>> - * Note: the rq_list should have atleast one element to schedule
>>> + * Note: the sched_list should have atleast one element to schedule
>> "atleast" --&
That looks excellent--thank you for submitting it.
Hopefully, the documentation would be more accessible
to everyone, so that everyone would contribute.
Regards,
Luben
On 2020-01-20 11:35 a.m., Nirmoy Das wrote:
> expand sched_list definition for better understanding.
> Also fix a typo atleast
On 2020-01-21 11:50 a.m., Nirmoy Das wrote:
> Do not allocate all the entity at once. This is required for
> dynamic amdgpu_ctx_entity creation.
>
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 130
> 1 file changed, 65 insertions(+), 65
On 2020-03-05 01:23, Nirmoy wrote:
>
> On 3/4/20 11:00 PM, Luben Tuikov wrote:
>> On 2020-03-03 7:50 a.m., Nirmoy Das wrote:
>>> implement drm_sched_entity_modify_sched() which can modify existing
>>> sched_list with a different one. This is going to be helpful when
On 2020-03-05 01:28, Nirmoy wrote:
>
> On 3/4/20 11:25 PM, Luben Tuikov wrote:
>> On 2020-03-03 7:50 a.m., Nirmoy Das wrote:
>>> Switch to appropriate sched list for an entity on priority override.
>>>
>>> Signed-off-by: Nirmoy Das
>>> ---
&g
On 2020-03-05 04:10, Nirmoy wrote:
>
> On 3/4/20 11:00 PM, Luben Tuikov wrote:
>> struct drm_sched_entity *entity,
>>>void *owner);
>>> +void drm_sched_entity_modify_sched(struct drm_sched_entity *entity,
>>> +
On 2020-04-20 6:16 a.m., Hawking Zhang wrote:
> asd is unified ucode across asic. it is not necessary
> to keep its software structure to be ip specific one
Sentences usually start with a capital letter.
"ASD is unified uCode across ASICs."
The second sentence uses "it" twice and it is not clear
On 2020-04-20 11:29 a.m., Luben Tuikov wrote:
> On 2020-04-20 6:16 a.m., Hawking Zhang wrote:
>> asd is unified ucode across asic. it is not necessary
>> to keep its software structure to be ip specific one
>
> Sentences usually start with a capital letter.
> "ASD
1 - 100 of 878 matches
Mail list logo
