Some fixes to enum drm_sched_priority which I'd wanted to do
since last year.
For instance, renaming MAX to COUNT, as usually a maximum value
is a value which is part of the set of values, (e.g. a maxima of
a function), and thus assignable, whereby a count is the size of
a set (the enumeration in
Remove DRM_SCHED_PRIORITY_INVALID. We no longer
carry around an invalid priority and cut it off
at the source.
Backwards compatibility behaviour of AMDGPU CTX
IOCTL passing in garbage for context priority
from user space and then mapping that to
DRM_SCHED_PRIORITY_NORMAL is preserved.
v2: Revert
Remove DRM_SCHED_PRIORITY_LOW, as it was used
in only one place.
Rename and separate by a line
DRM_SCHED_PRIORITY_MAX to DRM_SCHED_PRIORITY_COUNT
as it represents a (total) count of said
priorities and it is used as such in loops
throughout the code. (0-based indexing is the
the count number.)
Get the amdgpu_device from the DRM device by use
of a macro, DRM_TO_ADEV(). The macro resolves
a pointer to struct drm_device to a pointer to
struct amdgpu_device.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
Embed struct drm_device into struct amdgpu_device.
Modify the macro DRM_TO_ADEV()
accordingly. Introduce a new macro to yield the
DRM device from amdgpu_device, ADEV_TO_DRM().
Eliminate the use of drm_device.dev_private,
in amdgpu.
Add a DRM driver relase function, which frees
the amdgpu_device
As per the comments in include/drm/drm_device.h, struct
drm_device::dev_private seems to be obsolete and it is
recommended that drivers embed struct drm_device into their
larger per-device structure.
This patch-set embeds struct drm_device into struct
amdgpu_device, adds accessor macros for both
[AMD Official Use Only - Internal Distribution Only]
I took a closer look at this and there seems to be an issue in the function.
Crtc being null is a valid case here. The sequence that leads to this is,
unplug -> disable crtc/release vcpi slots then hotplug. The issue is that
pos->port is not
On 2020-08-14 3:28 p.m., Alex Deucher wrote:
> + dri-devel
>
>
> On Fri, Aug 14, 2020 at 3:14 PM Luben Tuikov wrote:
>>
>> Remove DRM_SCHED_PRIORITY_INVALID. We no longer
>> carry around an invalid priority and cut it off
>> at the source.
>>
>> Backwards compatibility behaviour of AMDGPU CTX
On 2020-08-14 4:58 p.m., Alex Deucher wrote:
> On Fri, Aug 14, 2020 at 3:33 PM Alex Deucher wrote:
>>
>> + dri-devel
>>
>> On Fri, Aug 14, 2020 at 3:14 PM Luben Tuikov wrote:
>>>
>>> Remove DRM_SCHED_PRIORITY_LOW, as it was used
>>> in only one place.
>>>
>>> Rename and separate by a line
>>>
On Fri, Aug 14, 2020 at 3:33 PM Alex Deucher wrote:
>
> + dri-devel
>
> On Fri, Aug 14, 2020 at 3:14 PM Luben Tuikov wrote:
> >
> > Remove DRM_SCHED_PRIORITY_LOW, as it was used
> > in only one place.
> >
> > Rename and separate by a line
> > DRM_SCHED_PRIORITY_MAX to DRM_SCHED_PRIORITY_COUNT
>
On 2020-08-14 4:10 p.m., Alex Deucher wrote:
>> I see DRM as more of a unifying layer (perhaps long term), as opposed
>> to a *library* which LLDDs call into. Then LLDDs would provide an interface
>> to the hardware. This will help us avoid many of the deadlocks and
>> synchronization issues which
On Fri, Aug 14, 2020 at 3:52 PM Luben Tuikov wrote:
>
> On 2020-08-14 11:23 a.m., Nirmoy wrote:
> >
> > On 8/13/20 11:17 PM, Luben Tuikov wrote:
> >> I support having AER handling.
> >>
> >> However, I feel it should be offloaded to the DRM layer.
> >> The PCI driver gets the AER callback and
On 2020-08-14 11:23 a.m., Nirmoy wrote:
>
> On 8/13/20 11:17 PM, Luben Tuikov wrote:
>> I support having AER handling.
>>
>> However, I feel it should be offloaded to the DRM layer.
>> The PCI driver gets the AER callback and immediately
>> offloads into DRM, as "return drm_aer_recover(dev); }".
+ dri-devel
On Fri, Aug 14, 2020 at 3:14 PM Luben Tuikov wrote:
>
> Remove DRM_SCHED_PRIORITY_LOW, as it was used
> in only one place.
>
> Rename and separate by a line
> DRM_SCHED_PRIORITY_MAX to DRM_SCHED_PRIORITY_COUNT
> as it represents a (total) count of said
> priorities and it is used as
+ dri-devel
On Fri, Aug 14, 2020 at 3:14 PM Luben Tuikov wrote:
>
> Remove DRM_SCHED_PRIORITY_INVALID. We no longer
> carry around an invalid priority and cut it off
> at the source.
>
> Backwards compatibility behaviour of AMDGPU CTX
> IOCTL passing in garbage for context priority
> from user
+ dri-devel
On Fri, Aug 14, 2020 at 3:14 PM Luben Tuikov wrote:
>
> Some fixes to enum drm_sched_priority which I'd wanted to do
> since last year.
>
> For instance, renaming MAX to COUNT, as usually a maximum value
> is a value which is part of the set of values, (e.g. a maxima of
> a
[AMD Public Use]
No need to apologize, it was a good catch. Something to double check in the
future if something similar ends up getting applied again.
Thanks!
Alex
From: amd-gfx on behalf of Matt Coffin
Sent: Friday, August 14, 2020 3:13 PM
To:
Some fixes to enum drm_sched_priority which I'd wanted to do
since last year.
For instance, renaming MAX to COUNT, as usually a maximum value
is a value which is part of the set of values, (e.g. a maxima of
a function), and thus assignable, whereby a count is the size of
a set (the enumeration in
Hi all,
As of 026acaeac2d205f22c0f682cc1c7b1a85b9ccd00 ("drm/amdgpu: revert "fix
system hang issue during GPU reset""), this patch is no longer needed,
and won't apply, because the badly-behaving code was removed; I'll
withdraw this patch for now.
Sorry to those who wasted their time reviewing.
Remove DRM_SCHED_PRIORITY_INVALID. We no longer
carry around an invalid priority and cut it off
at the source.
Backwards compatibility behaviour of AMDGPU CTX
IOCTL passing in garbage for context priority
from user space and then mapping that to
DRM_SCHED_PRIORITY_NORMAL is preserved.
Remove DRM_SCHED_PRIORITY_LOW, as it was used
in only one place.
Rename and separate by a line
DRM_SCHED_PRIORITY_MAX to DRM_SCHED_PRIORITY_COUNT
as it represents a (total) count of said
priorities and it is used as such in loops
throughout the code. (0-based indexing is the
the count number.)
[AMD Official Use Only - Internal Distribution Only]
pos->port->connector?
This is checking the crtc not the connector. The crtc can be null if its
disabled.
Since it is happening after a unplug->hotplug, I guess we are missing something
in the disable sequence and the old connector is still
[Why]
DM atomic check was structured in a way that we required old DC state
in order to dynamically add and remove planes and streams from the
context to build the DC state context for validation.
DRM private objects were used to carry over the last DC state and
were added to the context on
Reviewed-by: Rodrigo Siqueira
On 08/14, Bhawanpreet Lakha wrote:
> This field is not defined for DCN3
>
> Signed-off-by: Bhawanpreet Lakha
> ---
> .../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h | 1 +
> .../include/asic_reg/dcn/dcn_3_0_0_sh_mask.h | 22 +++
> 2 files changed,
On Fri, Aug 14, 2020 at 12:21 PM Koenig, Christian
wrote:
>
>
>
> Am 14.08.2020 17:53 schrieb Alex Deucher :
>
> On Fri, Aug 14, 2020 at 11:22 AM Christian König
> wrote:
> >
> > Hey Thomas & Alex,
> >
> > well the TTM and Nouveau changes look good to me, but this completely
> > broke amdgpu.
>
>-Original Message-
>From: dri-devel On Behalf Of
>Bhawanpreet Lakha
>Sent: Friday, August 14, 2020 1:02 PM
>To: mikita.lip...@amd.com; nicholas.kazlaus...@amd.com;
>alexander.deuc...@amd.com
>Cc: Bhawanpreet Lakha ; dri-
>de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org
[Why]
In certain cases the crtc can be NULL and returning -EINVAL causes
atomic check to fail when it shouln't. This leads to valid
configurations failing because atomic check fails.
[How]
Don't early return if crtc is null
Signed-off-by: Bhawanpreet Lakha
---
This field is not defined for DCN3
Signed-off-by: Bhawanpreet Lakha
---
.../gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h | 1 +
.../include/asic_reg/dcn/dcn_3_0_0_sh_mask.h | 22 +++
2 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_dsc.h
Am 14.08.2020 17:53 schrieb Alex Deucher :
On Fri, Aug 14, 2020 at 11:22 AM Christian König
wrote:
>
> Hey Thomas & Alex,
>
> well the TTM and Nouveau changes look good to me, but this completely
> broke amdgpu.
>
> Alex any idea what is going on here?
What's broken in amdgpu? There shouldn't
On Fri, Aug 14, 2020 at 11:22 AM Christian König
wrote:
>
> Hey Thomas & Alex,
>
> well the TTM and Nouveau changes look good to me, but this completely
> broke amdgpu.
>
> Alex any idea what is going on here?
What's broken in amdgpu? There shouldn't be any ttm changes in amdgpu
for drm-next.
Acked-by: Nirmoy Das
On 8/14/20 5:14 PM, Leo Liu wrote:
Fix warning from kernel test robot
v2: remove the local variable as well
Signed-off-by: Leo Liu
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff
Hey Thomas & Alex,
well the TTM and Nouveau changes look good to me, but this completely
broke amdgpu.
Alex any idea what is going on here?
Regards,
Christian.
Am 12.08.20 um 21:10 schrieb Thomas Zimmermann:
Hi Christian and Ben,
I backmerged drm-next into drm-misc-next and had a conflict
On 8/13/20 11:17 PM, Luben Tuikov wrote:
I support having AER handling.
However, I feel it should be offloaded to the DRM layer.
The PCI driver gets the AER callback and immediately
offloads into DRM, as "return drm_aer_recover(dev); }".
The DRM layer does a top-down approach into the error
Fix warning from kernel test robot
v2: remove the local variable as well
Signed-off-by: Leo Liu
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
Reviewed-by: Nirmoy Das
Nirmoy
On 8/14/20 10:43 AM, Evan Quan wrote:
As these are already defined in amdgpu_atombios.h. Otherwise, we may
hit "redefined" compile warning.
Change-Id: Ia2a9e10b35173fedcbbd8e0abb8ad38dd231baf4
Signed-off-by: Evan Quan
---
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Feifei Xu
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Friday, August 14, 2020 4:44 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amd/pm: drop redundant
As these are already defined in amdgpu_atombios.h. Otherwise, we may
hit "redefined" compile warning.
Change-Id: Ia2a9e10b35173fedcbbd8e0abb8ad38dd231baf4
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/pm/powerplay/hwmgr/ppatomctrl.h | 9 -
1 file changed, 9 deletions(-)
diff --git
On 8/14/20 4:56 AM, Quan, Evan wrote:
[AMD Official Use Only - Internal Distribution Only]
Yes, I would like to make another patch to address Nirmoy's comments.
@Das, Nirmoy is that OK?
Yes.
Nirmoy
BR
Evan
-Original Message-
From: Alex Deucher
Sent: Thursday, August 13, 2020
Am 13.08.20 um 21:40 schrieb Leo Liu:
Fix warning from kernel test robot
Signed-off-by: Leo Liu
---
drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
b/drivers/gpu/drm/amd/amdgpu/jpeg_v3_0.c
index
39 matches
Mail list logo
