Kernel test robot throws below warning ->
>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c:125:5: warning:
>> no previous prototype for 'kgd_arcturus_hqd_sdma_load'
>> [-Wmissing-prototypes]
125 | int kgd_arcturus_hqd_sdma_load(struct kgd_dev *kgd, void
*mqd,
>> drivers/gpu/drm/amd/amd
On Sat, Apr 24, 2021 at 5:03 AM Felix Kuehling wrote:
>
> Am 2021-04-23 um 5:39 p.m. schrieb Souptick Joarder:
> > Kernel test robot throws below warning ->
> >
> >>> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c:125:5: warning:
> >>> no previous prototype for 'kgd_arcturus_hqd_sdma_load'
>
Merge the two loops, loosen the restriction for big allocations.
This reduces the CPU overhead in the good case, but increases
it a bit under memory pressure.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 58 +---
1 file changed, 27 insertions(
Acked-and-Tested-by: Nirmoy Das
On 4/26/21 10:54 AM, Christian König wrote:
Merge the two loops, loosen the restriction for big allocations.
This reduces the CPU overhead in the good case, but increases
it a bit under memory pressure.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/a
Reviewed-by: Nirmoy Das
On 4/26/21 2:13 PM, Colin King wrote:
From: Colin Ian King
There is a spelling mistake in a pr_debug message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers
When an amdgpu device fails to init, it makes another VGA device cause
kernel splat:
kernel: amdgpu :08:00.0: amdgpu: amdgpu_device_ip_init failed
kernel: amdgpu :08:00.0: amdgpu: Fatal error during GPU init
kernel: amdgpu: probe of :08:00.0 failed with error -110
...
kernel: amdgpu 000
From: Colin Ian King
There is a spelling mistake in a pr_debug message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
b/drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c
index 1f02e4ee2909..771e2f
Please add a patch description. With that fixed, the patch is
Reviewed-by: Felix Kuehling
Am 2021-04-26 um 9:44 a.m. schrieb Harish Kasiviswanathan:
> Signed-off-by: Harish Kasiviswanathan
> ---
> drivers/gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 5 +++--
> 1 file changed, 3 insertions(+),
[AMD Official Use Only - Internal Distribution Only]
From: amd-gfx on behalf of Roy Sun
Sent: Monday, April 26, 2021 2:27 PM
To: amd-gfx@lists.freedesktop.org
Cc: Sun, Roy ; Nieto, David M
Subject: [PATCH 1/2] drm/scheduler: Change scheduled fence track
Upd
Am 2021-04-26 um 4:54 a.m. schrieb Christian König:
> Merge the two loops, loosen the restriction for big allocations.
> This reduces the CPU overhead in the good case, but increases
> it a bit under memory pressure.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vr
Am 26.04.21 um 17:30 schrieb Wang, Kevin(Yang):
[AMD Official Use Only - Internal Distribution Only]
*From:* amd-gfx on behalf of
Roy Sun
*Sent:* Monday, April 26, 2021 2:27 PM
*To:* amd-gfx@lists.freedesktop.org
Am 26.04.21 um 18:02 schrieb Felix Kuehling:
Am 2021-04-26 um 4:54 a.m. schrieb Christian König:
Merge the two loops, loosen the restriction for big allocations.
This reduces the CPU overhead in the good case, but increases
it a bit under memory pressure.
Signed-off-by: Christian König
---
Am 2021-04-26 um 12:12 p.m. schrieb Christian König:
>
>
> Am 26.04.21 um 18:02 schrieb Felix Kuehling:
>> Am 2021-04-26 um 4:54 a.m. schrieb Christian König:
>>> Merge the two loops, loosen the restriction for big allocations.
>>> This reduces the CPU overhead in the good case, but increases
>>>
## Introduction
We are looking to enable HDR support for a couple of single-plane and
multi-plane scenarios. To do this effectively we recommend new interfaces to
drm_plane. Below I'll give a bit of background on HDR and why we propose these
interfaces.
## Defining a pixel's luminance
Curr
From: Bhawanpreet Lakha
Add the following color encodings
- RGB versions for BT601, BT709, BT2020
- DCI-P3: Used for digital movies
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_color_mgmt.c | 4
include/drm/drm_color_mgmt.h | 4
2 files
From: Bhawanpreet Lakha
Due to the way displays and human vision work it is most effective to
encode luminance information in a non-linear space.
For SDR this non-linear mapping is assumed to roughly use a gamma 2.2 curve.
This was due to the way CRTs worked and was fine for SDR content with a
l
From: Bhawanpreet Lakha
SDR is typically mastered at 200 nits and HDR is mastered at up to 10,000
nits. Due to this luminance range difference if we blend a SDR and
HDR plane together, we can run into problems where the HDR plane is too
bright or the SDR plane is too dim
A common solution to thi
mhhh, probably should do this a bit differently. Also adding Koba since
this involves using extended DPCD caps in the MST topology mgr.
On Fri, 2021-04-23 at 16:05 -0400, Nikola Cornij wrote:
> [why]
> Two conditions that were part of this fix did not go through:
>
> 1. DPCD revision has to b
On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
> From: Bhawanpreet Lakha
>
> Add the following color encodings
> - RGB versions for BT601, BT709, BT2020
> - DCI-P3: Used for digital movies
>
> Signed-off-by: Bhawanpreet Lakha
> Signed-off-by: Harry Wentland
> ---
> drivers/gp
Use devm_memunmap_pages instead of memunmap_pages to release pgmap
and remove pgmap from device action, to avoid double free pgmap when
unloading driver module.
Release device memory region if failed to create device memory pages
structure.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amd
Am 2021-04-26 um 2:41 p.m. schrieb Philip Yang:
> Use devm_memunmap_pages instead of memunmap_pages to release pgmap
> and remove pgmap from device action, to avoid double free pgmap when
> unloading driver module.
>
> Release device memory region if failed to create device memory pages
> structure
On 2021-04-26 8:15, Nirmoy wrote:
> Reviewed-by: Nirmoy Das
>
> On 4/26/21 2:13 PM, Colin King wrote:
>> From: Colin Ian King
>>
>> There is a spelling mistake in a pr_debug message. Fix it.
>>
>> Signed-off-by: Colin Ian King
Applied to amd-staging-drm-next.
Thanks,
Felix
>> ---
>> driv
On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
From: Bhawanpreet Lakha
Add the following color encodings
- RGB versions for BT601, BT709, BT2020
- DCI-P3: Used for digital movies
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Ha
On Mon, Apr 26, 2021 at 02:56:26PM -0400, Harry Wentland wrote:
> On 2021-04-26 2:07 p.m., Ville Syrjälä wrote:
> > On Mon, Apr 26, 2021 at 01:38:50PM -0400, Harry Wentland wrote:
> >> From: Bhawanpreet Lakha
> >>
> >> Add the following color encodings
> >> - RGB versions for BT601, BT709, BT2020
[AMD Official Use Only - Internal Distribution Only]
No objections from me.
Thanks!
Alex
From: Christian König
Sent: Monday, April 26, 2021 2:49 AM
To: Deucher, Alexander
Cc: Nieto, David M ; Sun, Roy ; amd-gfx
list
Subject: Re: [PATCH 1/2] drm/scheduler: Ch
[AMD Official Use Only - Internal Distribution Only]
That said, it would be easier for me to merge through the AMD tree since a
relatively big AMD feature depends on it. Not sure how much conflict potential
there is if this goes through the AMD tree.
Alex
From
The plural of 'process' should be 'processes'.
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c
b/drivers/gpu/drm/amd/amdkfd/kfd_packet_mana
My concern is more to get this tested from more people than just AMD.
Christian.
Am 26.04.21 um 21:40 schrieb Deucher, Alexander:
[AMD Official Use Only - Internal Distribution Only]
That said, it would be easier for me to merge through the AMD tree
since a relatively big AMD feature depend
[AMD Official Use Only - Internal Distribution Only]
Fair point. Either way works for me.
Alex
From: Christian König
Sent: Monday, April 26, 2021 3:48 PM
To: Deucher, Alexander
Cc: amd-gfx list ; Sun, Roy ;
Nieto, David M
Subject: Re: [PATCH 1/2] drm/schedule
Daniel, Harry and Nick - in latest drm-misc-next (5.12.rc3) I am testing
for device unplug patches a user testing with eGPU box reported a crash
on unplug. I debugged myself a bit and I see that
drm_mode_config_cleanup is called twice - once explicitly from display
shutdown code and once as a c
After draining the stale retry fault, or failed to validate the range
to recover, have to remove the fault address from fault filter ring, to
be able to handle subsequent retry interrupt on same address. Otherwise
the retry fault will not be processed to recover until timeout passed.
Signed-off-by
Add interface to remove address from fault filter ring by resetting
fault ring entry key, then future vm fault on the address will be
processed to recover.
Define fault key as atomic64_t type to use atomic read/set/cmpxchg key
to protect fault ring access by interrupt handler and interrupt deferre
As I understand it, when one GPU map another GPU's vram, this vram should also
be mapped in iommu page table. Also normal GTT memory (versus userptr) also
need to be mapped in iommu. But don't see this code below. I only see you map
userptr in iommu. Maybe you map them in iommu not during memory
Regards,
Oak
On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling"
wrote:
DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
with the BO and page tables reserved, so we can safely update the DMA
mapping.
DMA unmap when a BO is unmapped fr
On Sat, 24 Apr 2021 at 04:43, Lyude Paul wrote:
>
> Since it's been asked quite a few times on some of the various DP
> related patch series I've submitted to use the new DRM printk helpers,
> and it technically wasn't really trivial to do this before due to the
> lack of a consistent way to find
Regards,
Oak
On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling"
wrote:
Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 2 +
.../gpu/drm/amd/amdgpu/a
Am 2021-04-26 um 8:09 p.m. schrieb Zeng, Oak:
> As I understand it, when one GPU map another GPU's vram, this vram should
> also be mapped in iommu page table. Also normal GTT memory (versus userptr)
> also need to be mapped in iommu. But don't see this code below.
Right, I'm not solving all pro
Am 2021-04-26 um 8:23 p.m. schrieb Zeng, Oak:
> Regards,
> Oak
>
>
>
> On 2021-04-21, 9:31 PM, "dri-devel on behalf of Felix Kuehling"
>
> wrote:
>
> DMA map kfd_mem_attachments in update_gpuvm_pte. This function is called
> with the BO and page tables reserved, so we can safely upda
Am 2021-04-26 um 8:35 p.m. schrieb Zeng, Oak:
> Regards,
> Oak
>
>
>
> On 2021-04-21, 9:31 PM, "amd-gfx on behalf of Felix Kuehling"
>
> wrote:
>
> Use DMABufs with dynamic attachment to DMA-map GTT BOs on other GPUs.
>
> Signed-off-by: Felix Kuehling
> ---
> drivers/gpu/dr
Am 2021-04-26 um 3:44 p.m. schrieb Jonathan Kim:
> The plural of 'process' should be 'processes'.
>
> Signed-off-by: Jonathan Kim
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git
From: Pavan Kumar Ramayanam
The runtime resume PM op disregards the return value from
amdgpu_device_resume(), masking errors for failed resumes at the PM
layer.
Signed-off-by: Pavan Kumar Ramayanam
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
42 matches
Mail list logo
