It's possible that what they really needed was the SDMA fix, so I don't
know if they need this flag anymore.
Marek
On Tue., Apr. 28, 2020, 01:12 Marek Olšák, wrote:
> No, Mesa won't use it. It's only necessary for the constant engine. My
> understanding from various discussions with the PAL
No, Mesa won't use it. It's only necessary for the constant engine. My
understanding from various discussions with the PAL team is that they need
it, but I don't know if they even understand what the MEM_SYNC flag does.
Marek
On Mon., Apr. 27, 2020, 10:53 Christian König, <
Hi Alex,
The pm_runtime_autosuspend_expiration() return 0 due to ->use_autosuspend and
autosuspend_delay are all zeros.
This seems not kernel specific. As I can see this on 5.6-drm-next kernel and
ubuntu original 5.3.46 kernel.
Any insights why that happened?
And maybe a compromise is: try the
Yes, same question.
In fact, PAL cmd stream has itself Relase/Acquire packets. That we use
the flag is per your request.
-David
在 2020/4/27 22:53, Christian König 写道:
Yeah, but is Mesa going to use it?
Christian.
Am 27.04.20 um 15:54 schrieb Marek Olšák:
PAL requested it and they are
Track GPU VRAM usage on a per process basis and report it through
sysfs.
v2:
- Handle AMDGPU BO-specific details in
amdgpu_amdkfd_gpuvm_free_memory_of_gpu().
- Return size of VRAM BO being freed from
amdgpu_amdkfd_gpuvm_free_memory_of_gpu().
- Do not consider imported memory
Ping..
-Original Message-
From: Quan, Evan
Sent: Sunday, April 26, 2020 11:19 AM
To: Dan Carpenter
Cc: amd-gfx@lists.freedesktop.org; Deucher, Alexander
Subject: RE: [PATCH] drm/amdgpu: address the static checker warnings
-Original Message-
From: Dan Carpenter
Sent:
Series s reviewed-by: Evan Quan
-Original Message-
From: amd-gfx On Behalf Of Tiecheng Zhou
Sent: Monday, April 27, 2020 11:30 AM
To: amd-gfx@lists.freedesktop.org
Cc: Zhou, Tiecheng
Subject: [PATCH 2/2] drm/amd/powerplay: avoid using pm_en before it is
initialized revised
On 2020-04-27 4:43 p.m., Andriy Gapon wrote:
> On 24/04/2020 20:22, Harry Wentland wrote:
>> On 2020-04-24 8:34 a.m., Andriy Gapon wrote:
>>>
>>> First, I understand that my platform is not directly supported and probably
>>> not
>>> very interesting, but I still hope to get some tips or
On 24/04/2020 20:22, Harry Wentland wrote:
> On 2020-04-24 8:34 a.m., Andriy Gapon wrote:
>>
>> First, I understand that my platform is not directly supported and probably
>> not
>> very interesting, but I still hope to get some tips or pointers.
>>
>
> Hi Andriy,
>
> yeah, limited insight here
Wait for tiles off after unpause to fix transcode timeout issue.
It is a work around.
Signed-off-by: James Zhu
---
drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v2_5.c
Applied. Thanks!
Alex
On Mon, Apr 27, 2020 at 4:03 AM Christian König
wrote:
>
> Am 27.04.20 um 08:37 schrieb Jason Yan:
> > The '>' expression itself is bool, no need to convert it to bool again.
> > This fixes the following coccicheck warning:
> >
> >
Applied. Thanks!
Alex
On Mon, Apr 27, 2020 at 4:03 AM Christian König
wrote:
>
> Am 27.04.20 um 08:37 schrieb Jason Yan:
> > The '==' expression itself is bool, no need to convert it to bool again.
> > This fixes the following coccicheck warning:
> >
> >
Applied. thanks!
Alex
On Mon, Apr 27, 2020 at 4:02 AM Christian König
wrote:
>
> Am 27.04.20 um 08:36 schrieb Jason Yan:
> > The '>' expression itself is bool, no need to convert it to bool again.
> > This fixes the following coccicheck warning:
> >
> >
Thanks Mukul.
One last thing I noticed. It seems the update the the vram_usage is
protected by the process->mutex. That means the variable will always be
coherent while that lock is held. However, the sysfs-show function
doesn't hold that lock. So if the compiler decides to break the update
into
On Mon, Apr 27, 2020 at 2:39 PM Takashi Iwai wrote:
>
> On Mon, 27 Apr 2020 20:28:12 +0200,
> Alex Deucher wrote:
> >
> > On Mon, Apr 27, 2020 at 2:07 PM Nicholas Johnson
> > wrote:
> > >
> > > On Mon, Apr 27, 2020 at 05:15:55PM +0200, Takashi Iwai wrote:
> > > > On Mon, 27 Apr 2020 16:22:21
On Mon, 27 Apr 2020 20:28:12 +0200,
Alex Deucher wrote:
>
> On Mon, Apr 27, 2020 at 2:07 PM Nicholas Johnson
> wrote:
> >
> > On Mon, Apr 27, 2020 at 05:15:55PM +0200, Takashi Iwai wrote:
> > > On Mon, 27 Apr 2020 16:22:21 +0200,
> > > Deucher, Alexander wrote:
> > > >
> > > > [AMD Public Use]
>
On Mon, Apr 27, 2020 at 2:07 PM Nicholas Johnson
wrote:
>
> On Mon, Apr 27, 2020 at 05:15:55PM +0200, Takashi Iwai wrote:
> > On Mon, 27 Apr 2020 16:22:21 +0200,
> > Deucher, Alexander wrote:
> > >
> > > [AMD Public Use]
> > >
> > > > -Original Message-
> > > > From: Nicholas Johnson
> >
On Mon, Apr 27, 2020 at 05:15:55PM +0200, Takashi Iwai wrote:
> On Mon, 27 Apr 2020 16:22:21 +0200,
> Deucher, Alexander wrote:
> >
> > [AMD Public Use]
> >
> > > -Original Message-
> > > From: Nicholas Johnson
> > > Sent: Sunday, April 26, 2020 12:02 PM
> > > To:
Add the ReadSerial definitions for Arcturus to the arcturus_ppsmc.h
header for use with unique_id
Signed-off-by: Kent Russell
Change-Id: I71849ec381730b1803e54cd6040aa3b245b53de8
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 2 ++
drivers/gpu/drm/amd/powerplay/inc/arcturus_ppsmc.h |
Add support for unique_id for Arcturus, since we only have the ppsmc
definitions for that added at the moment
Signed-off-by: Kent Russell
Change-Id: I66f8e9ff41521d6c13ff673587d6061c1f3f4b7a
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 10 ++
1 file changed, 10 insertions(+)
diff
On Mon, 27 Apr 2020 16:22:21 +0200,
Deucher, Alexander wrote:
>
> [AMD Public Use]
>
> > -Original Message-
> > From: Nicholas Johnson
> > Sent: Sunday, April 26, 2020 12:02 PM
> > To: linux-ker...@vger.kernel.org
> > Cc: Deucher, Alexander ; Koenig, Christian
> > ; Zhou,
Yeah, but is Mesa going to use it?
Christian.
Am 27.04.20 um 15:54 schrieb Marek Olšák:
PAL requested it and they are going to use it. (it looks like they
have to use it for correctness)
Marek
On Mon, Apr 27, 2020 at 9:02 AM Deucher, Alexander
mailto:alexander.deuc...@amd.com>> wrote:
[AMD Public Use]
> -Original Message-
> From: Nicholas Johnson
> Sent: Sunday, April 26, 2020 12:02 PM
> To: linux-ker...@vger.kernel.org
> Cc: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; Nicholas Johnson opensou...@outlook.com.au>
> Subject: [PATCH 0/1] Fiji
PAL requested it and they are going to use it. (it looks like they have to
use it for correctness)
Marek
On Mon, Apr 27, 2020 at 9:02 AM Deucher, Alexander <
alexander.deuc...@amd.com> wrote:
> [AMD Official Use Only - Internal Distribution Only]
>
> Do we have open source code UMD code which
I've already pushed the patch and marked it for stable.
I added a note into the commit message to discard the version bump for
stable.
The GCR packet is always supported in the ring regardless of firmware.
Marek
On Mon, Apr 27, 2020 at 9:01 AM Deucher, Alexander <
alexander.deuc...@amd.com>
[AMD Official Use Only - Internal Distribution Only]
Do we have open source code UMD code which uses this?
Alex
From: Christian König
Sent: Sunday, April 26, 2020 4:55 AM
To: Marek Olšák ; Koenig, Christian
Cc: Deucher, Alexander ; amd-gfx mailing list
[AMD Official Use Only - Internal Distribution Only]
Please split the patch into two, one to update the emit IB sequence, and one to
bump the minor version. That way we can make sure older kernels get the new
sequence. Also do we need an sdma fw version check for the new packet in the
emi IB
Am 27.04.20 um 08:37 schrieb Jason Yan:
The '>' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:602:28-33: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
Am 27.04.20 um 08:37 schrieb Jason Yan:
The '==' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c:455:70-75: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
Am 27.04.20 um 08:36 schrieb Jason Yan:
The '>' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3004:68-73: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
The '>' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3004:68-73: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
On Sun, 2020-04-26 at 15:18 +0200, Christian König wrote:
> Am 26.04.20 um 15:12 schrieb Bernard Zhao:
> > Maybe no need to check ws before kmalloc, kmalloc will check
> > itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
> > return
> >
> > Signed-off-by: Bernard Zhao
>
>
Maybe no need to check ws before kmalloc, kmalloc will check
itself, kmalloc`s logic is if ptr is NULL, kmalloc will just
return
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/radeon/atom.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c
btw: the debugging macros in atom.c are not good.
It could be something like the below as the output logging is
at best poorly formatted due to the many individual printks
without KERN_ that are emitted on separate lines.
#define ATOM_DEBUG
should probably be commented out.
The debugging
The '==' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_mpc.c:455:70-75: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
---
The '>' expression itself is bool, no need to convert it to bool again.
This fixes the following coccicheck warning:
drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c:602:28-33: WARNING:
conversion to bool not needed here
Signed-off-by: Jason Yan
---
On Mon, 2020-04-27 at 14:37 +0800, Jason Yan wrote:
> The '==' expression itself is bool, no need to convert it to bool again.
trivia:
These descriptions are not quite correct.
The operators return an int, either 0 or 1.
-
6.5.8 Relational operators
6 Each of the operators <
37 matches
Mail list logo
