Am 17.07.2018 um 22:16 schrieb Alex Deucher:
On Tue, Jul 17, 2018 at 4:12 PM, Sonny Jiang wrote:
Signed-off-by: Sonny Jiang
Please add a basic commit message. With that:
Reviewed-by: Alex Deucher
Oh, thanks. Got to clean that up on my todo list for ages.
Patch is Reviewed-by: Christian K
>shouldn't we still assign simple_clocks.level to clocks->max_clocks_state if
>it's non-zero?
Yes, Thanks for your reminding.
Best Regards
Rex
From: Wentland, Harry
Sent: Wednesday, July 18, 2018 2:29 AM
To: Zhu, Rex; amd-gfx@lists.freedesktop.org
Subject: R
On 07/18/2018 03:38 AM, Alex Deucher wrote:
Needs ATPX rather than _PR3.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=200517
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
Reviewed-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
1 file changed, 1
On 2018-07-17 06:39 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Allowing CONFIG_DRM_AMD_DC_DCN1_0 to be disabled on X86 was an
> opportunity for display with Raven Ridge accidentally not working.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/
On Tue, Jul 17, 2018 at 4:12 PM, Sonny Jiang wrote:
> Signed-off-by: Sonny Jiang
Please add a basic commit message. With that:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> 2 files changed, 1
Signed-off-by: Sonny Jiang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
2 files changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index d852d11..a9f09da 100644
--- a
On Tue, Jul 17, 2018 at 3:35 PM, Sonny Jiang wrote:
> Signed-off-by: Sonny Jiang
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 6 --
> 3 files changed, 26 deletions(-)
>
Needs ATPX rather than _PR3.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=200517
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
b
Signed-off-by: Sonny Jiang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 6 --
3 files changed, 26 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/d
Hi Alex,
Il giorno mar 17 lug 2018 alle ore 15:43 Alex Deucher
ha scritto:
> On Sun, Jul 15, 2018 at 10:03 PM, Mauro Rossi
> wrote:
> > From: Mauro Rossi
> >
> > (v1) {A,X}BGR code paths are added in amdgpu_dm, by using an
> fb_format
> > already listed in dc/dc_hw_types.h
> (SURFACE_
On 2018-07-17 08:36 AM, Rex Zhu wrote:
> Except special naming as *_in_khz, The default clock unit in powerplay
> is in 10KHz. so need to * 10 as expecting clock frequency in display
> is in kHz.
>
> Signed-off-by: Rex Zhu
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display
On 2018-07-17 08:36 AM, Rex Zhu wrote:
> avoid the error in dmesg:
> [drm:dm_pp_get_static_clocks]
> *ERROR* DM_PPLIB: invalid powerlevel state: 0!
>
> Signed-off-by: Rex Zhu
> ---
> drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
Michel, I think you are wasting your time. This change can be misused
as easily as any other API. It's not more dangerous that any other
amdgpu libdrm function. You won't achieve anything by optimizing the
hash table (= losing time), and you also won't achieve anything by
NAKing this (= losing perf
On Tue, Jul 17, 2018 at 12:22 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Only supported with the advanced colour management properties available
> with DC as of kernel 4.17.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Alex Deucher
> ---
> src/drmmode_display.c | 47
From: Michel Dänzer
Only supported with the advanced colour management properties available
with DC as of kernel 4.17.
Signed-off-by: Michel Dänzer
---
src/drmmode_display.c | 47 +++
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/src/dr
On Tue, Jul 17, 2018 at 5:29 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err error message.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
> 1 file changed, 5 insertions
On Mon, Jul 16, 2018 at 7:10 PM, Felix Kuehling wrote:
> User mode queue submissions don't go through KFD. Therefore we don't
> know exactly when compute is idle or not idle. We use the existence
> of user mode queues on a device as an approximation.
>
> register_process is called when the first q
On Tue, Jul 17, 2018 at 8:36 AM, Rex Zhu wrote:
> Except special naming as *_in_khz, The default clock unit in powerplay
> is in 10KHz. so need to * 10 as expecting clock frequency in display
> is in kHz.
>
> Signed-off-by: Rex Zhu
Series is:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/
On Tue, Jul 17, 2018 at 10:54 AM, Harry Wentland wrote:
> [Why]
> We were only setting this mask for DCN, but should really use it
> universally for all ASICs.
>
> [How]
> Move the assignment out of the Raven switch statement.
>
> Cc: rex@amd.com
> Cc: feifei...@amd.com
> Cc: kenneth.f...@amd.
On Tue, Jul 17, 2018 at 9:29 AM, wrote:
> From: Bhawanpreet Lakha
>
> [Why]
> Aux engine is created from i2caux layer. We want to remove this layer
> and use the engine directly.
>
> [How]
> Decouple aux engine from i2caux. Move aux engine related code to dce folder
> and use
> dc resource pool
On Tue, Jul 17, 2018 at 11:47 AM, Paul Menzel
wrote:
> Dear AMD Linux folks,
>
>
> Using Linux 4.18.0-rc5+ I get the warning and error below in the logs.
> I am using a Ryzen 3 2200g.
>
> ```
> $ dmesg
> [0.00] Linux version 4.18.0-rc5+ (paul@tokeiihto) (gcc version 8.1.0
> (Debian 8.1.0-
Dear AMD Linux folks,
Using Linux 4.18.0-rc5+ I get the warning and error below in the logs.
I am using a Ryzen 3 2200g.
```
$ dmesg
[0.00] Linux version 4.18.0-rc5+ (paul@tokeiihto) (gcc version 8.1.0
(Debian 8.1.0-10)) #1 SMP Tue Jul 17 11:43:33 CEST 2018
[0.00] Command line:
On Tue, Jul 17, 2018 at 5:43 AM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> We continued using the stale cached handle, causing issues e.g. when
> resizing the screen via RandR.
>
> Reported-by: iive on IRC
> Signed-off-by: Michel Dänzer
Acked-by: Alex Deucher
> ---
> src/radeon.h | 1 +
On 2018-07-17 11:15 AM, Michel Dänzer wrote:
> On 2018-07-17 05:10 PM, Harry Wentland wrote:
>> On 2018-07-17 10:17 AM, Michel Dänzer wrote:
>>> On 2018-07-17 03:29 PM, sunpeng...@amd.com wrote:
From: Mikita Lipski
[why]
The warning message floods the dmesg log on Tonga even
>>
On 2018-07-17 05:10 PM, Harry Wentland wrote:
> On 2018-07-17 10:17 AM, Michel Dänzer wrote:
>> On 2018-07-17 03:29 PM, sunpeng...@amd.com wrote:
>>> From: Mikita Lipski
>>>
>>> [why]
>>> The warning message floods the dmesg log on Tonga even
>>> though it is expected to have a pix_clk set to zero
On 2018-07-17 10:17 AM, Michel Dänzer wrote:
> On 2018-07-17 03:29 PM, sunpeng...@amd.com wrote:
>> From: Mikita Lipski
>>
>> [why]
>> The warning message floods the dmesg log on Tonga even
>> though it is expected to have a pix_clk set to zero,
>> when there is no display connected.
>> [how]
>> r
[Why]
We were only setting this mask for DCN, but should really use it
universally for all ASICs.
[How]
Move the assignment out of the Raven switch statement.
Cc: rex@amd.com
Cc: feifei...@amd.com
Cc: kenneth.f...@amd.com
Cc: evan.q...@amd.com
Cc: bhawanpreet.la...@amd.com
Cc: jordan.laz...@a
On 2018-07-17 03:29 PM, sunpeng...@amd.com wrote:
> From: Mikita Lipski
>
> [why]
> The warning message floods the dmesg log on Tonga even
> though it is expected to have a pix_clk set to zero,
> when there is no display connected.
> [how]
> remove the assert
>
> Change-Id: I4ca1e42439369b230569
On Sun, Jul 15, 2018 at 10:03 PM, Mauro Rossi wrote:
> From: Mauro Rossi
>
> (v1) {A,X}BGR code paths are added in amdgpu_dm, by using an fb_format
> already listed in dc/dc_hw_types.h (SURFACE_PIXEL_FORMAT_GRPH_ABGR),
> and in dce 8.0, 10.0 and 11.0, i.e. Bonaire and later.
>
From: Harry Wentland
Change-Id: I788210abbb33e0a38267c9bfd3656f51c844d5ac
Signed-off-by: Harry Wentland
Reviewed-by: Aric Cyr
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/dri
From: Jun Lei
[why]
confusing as to which part of debug is informational, and which part causes
behavioral change
Change-Id: I3248c1576c405d3e4deb30e9514098d13390158d
Signed-off-by: Jun Lei
Reviewed-by: Tony Cheng
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c |
From: David Francis
[Why]
When a dce100 asic was suspended, the clocks were not set to 0.
Upon resume, the new clock was compared to the existing clock,
they were found to be the same, and so the clock was not set.
This resulted in a pernicious blackscreen.
[How]
In atomic commit, check to see i
From: Tony Cheng
[why]
diag specify what the full config and is only concerned about pass/fail at the
end
having inter-op code like verifiying we can actually train at reported link rate
slows down diag test and add complexity we don't need
[how]
add dc_debug option to skip capability link tri
From: Bhawanpreet Lakha
[Why]
Aux engine is created from i2caux layer. We want to remove this layer
and use the engine directly.
[How]
Decouple aux engine from i2caux. Move aux engine related code to dce folder and
use
dc resource pool to manage the engine. And use the engine functions directly
From: "Leo (Sunpeng) Li"
Summary of change:
* De-midlayering work on AUX engine
* Fix S3 resume blackscreen for DCE10
* De-spamming of log for DCE10
Bhawanpreet Lakha (1):
drm/amd/display: Decouple aux from i2c
David Francis (1):
drm/amd/display: On dce100, set clocks to 0 on suspend
Harry
From: Mikita Lipski
[why]
The warning message floods the dmesg log on Tonga even
though it is expected to have a pix_clk set to zero,
when there is no display connected.
[how]
remove the assert
Change-Id: I4ca1e42439369b2305694b403457b5de60fc4ab1
Signed-off-by: Mikita Lipski
Reviewed-by: Harry
From: vikrant mhaske
[why]
Diags has POR to run the video workload using AYCRCB through DCN;
capture it through DWB and send it to VCN hardware to encode
[how]
added the code to support this format so that DPP ICSC will be able to
convert it from YUV444 to internal RGB and DWB OCSC will be a
From: Colin Ian King
Trivial fix to spelling mistake in dev_err error message.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/d
avoid the error in dmesg:
[drm:dm_pp_get_static_clocks]
*ERROR* DM_PPLIB: invalid powerlevel state: 0!
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
Except special naming as *_in_khz, The default clock unit in powerplay
is in 10KHz. so need to * 10 as expecting clock frequency in display
is in kHz.
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
di
avoid the error in dmesg:
[drm:dm_pp_get_static_clocks]
*ERROR* DM_PPLIB: invalid powerlevel state: 0!
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/amd_powerplay.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
From: Michel Dänzer
Allowing CONFIG_DRM_AMD_DC_DCN1_0 to be disabled on X86 was an
opportunity for display with Raven Ridge accidentally not working.
Signed-off-by: Michel Dänzer
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 2 +-
drivers/gpu/drm/amd/display/Kconfig | 8 -
Dear Alex,
On 07/17/18 00:00, Paul Menzel wrote:
> Am 16.07.2018 um 18:30 schrieb Alex Deucher:
>> On Mon, Jul 16, 2018 at 12:14 PM, Paul Menzel
>> wrote:
>>> Dear Linux folks,
>>>
>>>
>>> Trying to boot Debian Buster/testing with Linux 4.16.16 on a MSI B350M
>>> MORTAR [1]
>>> with a Ryzen 3
From: Michel Dänzer
We continued using the stale cached handle, causing issues e.g. when
resizing the screen via RandR.
Reported-by: iive on IRC
Signed-off-by: Michel Dänzer
---
src/radeon.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/radeon.h b/src/radeon.h
index 450c69aa8..1a1edb
On Tue, 17 Jul 2018 10:56:37 +0200,
jimqu wrote:
>
>
>
> On 2018年07月17日 16:52, Takashi Iwai wrote:
> > On Tue, 17 Jul 2018 10:38:58 +0200,
> > Lukas Wunner wrote:
> >> On Tue, Jul 17, 2018 at 04:20:50PM +0800, Jim Qu wrote:
> >>> On modern laptop, there are more and more platforms
> >>> have two
On 07/17/2018 05:04 PM, Christian König wrote:
Otherwise we leak file descriptors into child processes.
Signed-off-by: Christian König
Yeah, that's the key point that dup could remove CLOEXEC effect.
Reviewed-and-Tested-by: Junwei Zhang
---
amdgpu/amdgpu_device.c | 5 +++--
1 file chan
On 2018-07-17 11:04 AM, Christian König wrote:
> Otherwise we leak file descriptors into child processes.
>
> Signed-off-by: Christian König
> ---
> amdgpu/amdgpu_device.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device
Otherwise we leak file descriptors into child processes.
Signed-off-by: Christian König
---
amdgpu/amdgpu_device.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 34ac95b8..d7aec6a4 100644
--- a/amdgpu/amdgpu_device.c
On 2018年07月17日 16:52, Takashi Iwai wrote:
On Tue, 17 Jul 2018 10:38:58 +0200,
Lukas Wunner wrote:
On Tue, Jul 17, 2018 at 04:20:50PM +0800, Jim Qu wrote:
On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio codec
for HDMP/DP output. For some dGP
On 2018-07-16 08:51 PM, Marek Olšák wrote:
> On Mon, Jul 16, 2018 at 12:05 PM, Michel Dänzer wrote:
>> On 2018-07-13 08:47 PM, Marek Olšák wrote:
>>> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer wrote:
>>
I'd rather add the handle to the hash table in amdgpu_bo_alloc,
amdgpu_create_bo
On Tue, 17 Jul 2018 10:38:58 +0200,
Lukas Wunner wrote:
>
> On Tue, Jul 17, 2018 at 04:20:50PM +0800, Jim Qu wrote:
> > On modern laptop, there are more and more platforms
> > have two GPUs, and each of them maybe have audio codec
> > for HDMP/DP output. For some dGPU which is no output,
> > audio
On Tue, Jul 17, 2018 at 04:20:50PM +0800, Jim Qu wrote:
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
>
> In currect HDA audio driver, it will
Am 17.07.2018 um 10:30 schrieb Michel Dänzer:
On 2018-07-17 10:19 AM, Christian König wrote:
Am 17.07.2018 um 10:03 schrieb Michel Dänzer:
On 2018-07-17 09:59 AM, Christian König wrote:
Am 17.07.2018 um 09:46 schrieb Michel Dänzer:
On 2018-07-17 09:33 AM, Christian König wrote:
Am 17.07.2018
On 2018-07-17 10:19 AM, Christian König wrote:
> Am 17.07.2018 um 10:03 schrieb Michel Dänzer:
>> On 2018-07-17 09:59 AM, Christian König wrote:
>>> Am 17.07.2018 um 09:46 schrieb Michel Dänzer:
On 2018-07-17 09:33 AM, Christian König wrote:
> Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
Am 16.07.2018 um 17:50 schrieb Michel Dänzer:
On 2018-07-13 05:19 PM, Christian König wrote:
We can get that from the ring.
Signed-off-by: Christian König
This change introduced the attached oops when running the piglit
max-texture-size test, after which the test process hangs.
Note that the
On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio codec
for HDMP/DP output. For some dGPU which is no output,
audio codec usually is disabled.
In currect HDA audio driver, it will set all codec as
VGA_SWITCHEROO_DIS, the audio which is binded to U
Am 17.07.2018 um 10:03 schrieb Michel Dänzer:
On 2018-07-17 09:59 AM, Christian König wrote:
Am 17.07.2018 um 09:46 schrieb Michel Dänzer:
On 2018-07-17 09:33 AM, Christian König wrote:
Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
[SNIP]
All that should be needed is one struct list_head per
On Mon 16-07-18 16:12:49, Andrew Morton wrote:
> On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > There are several blockable mmu notifiers which might sleep in
> > mmu_notifier_invalidate_range_start and that is a problem for the
> > oom_reaper because it
On 2018-07-17 09:59 AM, Christian König wrote:
> Am 17.07.2018 um 09:46 schrieb Michel Dänzer:
>> On 2018-07-17 09:33 AM, Christian König wrote:
>>> Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
On 2018-07-17 08:50 AM, Christian König wrote:
> Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
Am 17.07.2018 um 09:46 schrieb Michel Dänzer:
On 2018-07-17 09:33 AM, Christian König wrote:
Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
On 2018-07-17 08:50 AM, Christian König wrote:
Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
On 2018-07-13 08:47 PM, Marek Olšák wrote:
[SNIP]
Other opini
On 2018-07-17 09:33 AM, Christian König wrote:
> Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
>> On 2018-07-17 08:50 AM, Christian König wrote:
>>> Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
On 2018-07-13 08:47 PM, Marek Olšák wrote:
[SNIP]
Other opinions?
>>> I understand the re
On Wed, Jun 20, 2018 at 11:26 AM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> uses the maximum sane buffer size and removes copy/paste code.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
>
> Sign
On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
> From: Michal Hocko
>
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend
On Mon, Jul 16, 2018 at 04:12:49PM -0700, Andrew Morton wrote:
> On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > There are several blockable mmu notifiers which might sleep in
> > mmu_notifier_invalidate_range_start and that is a problem for the
> > oom_rea
Am 17.07.2018 um 09:26 schrieb Michel Dänzer:
On 2018-07-17 08:50 AM, Christian König wrote:
Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
On 2018-07-13 08:47 PM, Marek Olšák wrote:
[SNIP]
Other opinions?
I understand the reason why Marek wants to do this, but I agree that
this is a little bit
On 2018年07月17日 15:26, Christian König wrote:
Am 17.07.2018 um 09:16 schrieb Zhou, David(ChunMing):
Acked-by: Chunming Zhou , but I think it isn't a
nice evaluation although there is comment in code.
Yeah, I didn't thought about the possibility that we need to free the
job before it is submi
Am 17.07.2018 um 09:16 schrieb Zhou, David(ChunMing):
Acked-by: Chunming Zhou , but I think it isn't a nice
evaluation although there is comment in code.
Yeah, I didn't thought about the possibility that we need to free the
job before it is submitted (in other words before the scheduler is
d
On 2018-07-17 08:50 AM, Christian König wrote:
> Am 16.07.2018 um 18:05 schrieb Michel Dänzer:
>> On 2018-07-13 08:47 PM, Marek Olšák wrote:
>>> On Fri, Jul 13, 2018 at 4:28 AM, Michel Dänzer
>>> wrote:
On 2018-07-12 07:03 PM, Marek Olšák wrote:
> On Thu, Jul 12, 2018, 3:31 AM Michel Dänz
Acked-by: Chunming Zhou , but I think it isn't a nice
evaluation although there is comment in code.
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Tuesday, July 17, 2018 3:05 PM
To: amd-gfx@lists.freedesktop.org
Subject
Otherwise we can't clean up the job if we run into an error before it is
pushed to the scheduler.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amd
70 matches
Mail list logo
