On 2/28/2024 12:30 PM, Yang Wang wrote:
> v1:
> enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM.
>
> v2:
> add onevf check for gfx 9.4.3
>
> v3:
> refine code check order to make function clearly.
>
> Signed-off-by: Yang Wang
Reviewed-by: Lijo Lazar
Thanks,
Lijo
> ---
>
v1:
enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM.
v2:
add onevf check for gfx 9.4.3
v3:
refine code check order to make function clearly.
Signed-off-by: Yang Wang
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 32 +-
1 file changed, 27 insertions(+), 5
Fix mask used for esm ctrl register to get pcie link
speed on smu_v11_0_3, smu_v13_0_2 & smu_v13_0_6
Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support")
Fixes: c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)")
Fixes: f1c378593153 ("drm/amd/powerplay: add Arcturus support
Am 28.02.24 um 02:44 schrieb Lu Yao:
uvd_ctx_rreg/uvd_ctx_wreg correct value requires function pointer.
Yeah, but that is completely irrelevant here. We usually don't use the &
for function pointers since that is unnecessary in C.
Regards,
Christian.
Signed-off-by: Lu Yao
---
On 2/28/2024 12:08 PM, Yang Wang wrote:
> v1:
> enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM.
>
> v2:
> add onevf check for gfx 9.4.3
>
> Signed-off-by: Yang Wang
> ---
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 35 +-
> 1 file changed, 30 insertions(+),
Am 28.02.24 um 06:04 schrieb Jesse.Zhang:
fix the issue when run clinfo:
"amdgpu: Failed to create process VM object".
when amdgpu initialized, seq64 do mampping and update bo mapping in vm page
table.
But when clifo run. It also initializes a vm for a process device through the
function
v1:
enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM.
v2:
add onevf check for gfx 9.4.3
Signed-off-by: Yang Wang
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 35 +-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
Am 27.02.24 um 19:48 schrieb Alex Deucher:
This reverts commit e94e787e37b99645e7c02d20d0a1ba0f8a18a82a.
This conflicts with how compositors want to handle VRR. Now
that compositors actually handle VRR, we probably don't need
freesync video.
Closes:
On 2/28/2024 11:28 AM, Yang Wang wrote:
> enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM.
>
> Signed-off-by: Yang Wang
> ---
> drivers/gpu/drm/amd/pm/amdgpu_pm.c | 29 -
> 1 file changed, 24 insertions(+), 5 deletions(-)
>
> diff --git
enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM.
Signed-off-by: Yang Wang
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
fix the issue when run clinfo:
"amdgpu: Failed to create process VM object".
when amdgpu initialized, seq64 do mampping and update bo mapping in vm page
table.
But when clifo run. It also initializes a vm for a process device through the
function kfd_process_device_init_vm
and ensure the root
On 2/28/2024 9:30 AM, Asad Kamal wrote:
> Skip reporting pcie link width/speed on vfs for
> smu_v13_0_6 & smu_v13_0_2
>
> Signed-off-by: Asad Kamal
> Reviewed-by: Yang Wang
Reviewed-by: Lijo Lazar
Thanks,
Lijo
> ---
> .../gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 10 ++
>
Skip reporting pcie link width/speed on vfs for
smu_v13_0_6 & smu_v13_0_2
Signed-off-by: Asad Kamal
Reviewed-by: Yang Wang
---
.../gpu/drm/amd/pm/swsmu/smu13/aldebaran_ppt.c | 10 ++
.../drm/amd/pm/swsmu/smu13/smu_v13_0_6_ppt.c | 18 ++
2 files changed, 16
On Tue, Feb 27, 2024 at 6:38 AM Thomas Zimmermann wrote:
>
> Dma-buf locking semantics require the caller of pin and unpin to hold
> the buffer's reservation lock. Fix DRM to adhere to the specs. This
> enables to fix the locking in DRM's console emulation. Similar changes
> for vmap and mmap
On Tue, Feb 27, 2024 at 6:39 AM Thomas Zimmermann wrote:
>
> Acquire the buffer object's reservation lock in drm_gem_pin() and
> remove locking the drivers' GEM callbacks where necessary. Same for
> unpin().
>
> DRM drivers and memory managers modified by this patch will now have
> correct
On Tue, Feb 27, 2024 at 6:39 AM Thomas Zimmermann wrote:
>
> Acquire the reservation lock directly in GEM pin callback. Same for
> unpin. Prepares for further changes.
>
> Dma-buf locking semantics require callers to hold the buffer's
> reservation lock when invoking the pin and unpin callbacks.
Hi Greg and Sasha,
Please apply upstream commit 5b750b22530f ("drm/amd/display: Increase
frame warning limit with KASAN or KCSAN in dml") to linux-6.1.y, as it
is needed to avoid instances of -Wframe-larger-than in allmodconfig,
which has -Werror enabled. It applies cleanly for me and it is
Hello,
We are currently looking at checking and/or possibly redesigning the
way the MSM DRM driver handles the HPD events and link training.
After a quick glance at the drivers implementing DP support, I noticed
following main approaches:
- Perform link training at the atomic_enable time, don't
On 2/27/24 13:48, Alex Deucher wrote:
This reverts commit e94e787e37b99645e7c02d20d0a1ba0f8a18a82a.
This conflicts with how compositors want to handle VRR. Now
that compositors actually handle VRR, we probably don't need
freesync video.
Closes:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6683
amdgpu_dm_connector_funcs_force()
warn: variable dereferenced before check 'dc_link' (see line 6663)
Fixes: 967176179215 ("drm/amd/display: fix null-pointer dereference on edid
reading")
Reported-by: Dan Carpenter
Signed-off-by:
This reverts commit 11b92df8a2f7f4605ccc764ce6ae4a72760674df.
This conflicts with how compositors want to handle VRR. Now
that compositors actually handle VRR, we probably don't need
freesync video.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2985
Signed-off-by: Alex Deucher
---
This reverts commit e94e787e37b99645e7c02d20d0a1ba0f8a18a82a.
This conflicts with how compositors want to handle VRR. Now
that compositors actually handle VRR, we probably don't need
freesync video.
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2985
Signed-off-by: Alex Deucher
---
Am 27.02.24 um 19:14 schrieb Dmitry Osipenko:
Hello,
Thank you for the patches!
On 2/27/24 13:14, Thomas Zimmermann wrote:
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in
From: Ivan Lipski
[WHY]
Some eDP panels's ext caps don't write initial value cause the value of
dpcd_addr(0x317) is random. It means that sometimes the eDP will
clarify it is OLED, miniLED...etc cause the backlight control interface
is incorrect.
[HOW]
Add a new panel patch to remove sink ext
Fixes snprintf function by writing more bytes into various buffers than
they can hold.
In several files - smu_v13_0.c, gfx_v11_0.c, gfx_v10_0.c, gfx_v9_0.c,
and amdgpu_mes.c. They were related to different directives, such as
'%s', '_pfp.bin', '_me.bin', '_rlc.bin', '_mec.bin', '_mec2', and
Also passing adev is misleading if BO is associated with different adev.
In this case BO is mapped to a different device
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 4 ++--
Increases the size of SMU_FW_NAME_LEN from 0x24 (36 in decimal) to 0x2A
(42 in decimal). This change prevents truncation when the snprintf
function writes into the fw_name buffer in the smu_v11_0_init_microcode
function.
Previously, snprintf could write between 12 and 41 bytes into fw_name,
which
Hi
Am 27.02.24 um 15:03 schrieb Christian König:
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Oh, wow. That was quick! Thanks a lot.
Best regards
Thomas
Regards,
Christian.
On 2024-02-27 07:14, Arthur Grillo wrote:
>
>
> On 26/02/24 18:10, Harry Wentland wrote:
>> Debugging LUT math is much easier when we can unit test
>> it. Add kunit functionality to VKMS and add tests for
>> - get_lut_index
>> - lerp_u16
>>
>> v4:
>> - Test the critical points of the lerp
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Regards,
Christian.
Am 27.02.24 um 11:14 schrieb Thomas Zimmermann:
Dma-buf locking semantics require the caller of pin and unpin to
On 2024-02-27 05:26, Joshua Ashton wrote:
>
>
> On 2/26/24 21:10, Harry Wentland wrote:
>> This is an RFC set for a color pipeline API, along with a sample
>> implementation in VKMS. All the key API bits are here. VKMS now
>> supports two named transfer function colorops and two matrix
>>
On 26/02/24 18:10, Harry Wentland wrote:
> Debugging LUT math is much easier when we can unit test
> it. Add kunit functionality to VKMS and add tests for
> - get_lut_index
> - lerp_u16
>
> v4:
> - Test the critical points of the lerp function (Pekka)
>
> v3:
> - Use include way of
The function drm_client_buffer_vmap() establishes a long-term mapping
of the client's buffer object into the kernel address space. Make sure
that buffer does not move by pinning it to its current location. Same
for vunmap with unpin.
The only caller of drm_client_buffer_vmap() is fbdev-dma, which
Pin and vmap are distinct operations. Do not perform a pin as part
of the vmap call. This used to be necessary to keep the fbdev buffer
in place while it is being updated. Fbdev emulation has meanwhile
been fixed to lock the buffer correctly. Same for vunmap.
Signed-off-by: Thomas Zimmermann
---
Pin and vmap are distinct operations. Do not perform a pin as part
of the vmap call. This used to be necessary to keep the fbdev buffer
in place while it is being updated. Fbdev emulation has meanwhile
been fixed to lock the buffer correctly. Same for vunmap.
For refactoring the code, remove the
Temporarily lock the fbdev buffer object during updates to prevent
memory managers from evicting/moving the buffer. Moving a buffer
object while update its content results in undefined behaviour.
Fbdev-generic updates its buffer object from a shadow buffer. Gem-shmem
and gem-dma helpers do not
Acquire the buffer object's reservation lock in drm_gem_pin() and
remove locking the drivers' GEM callbacks where necessary. Same for
unpin().
DRM drivers and memory managers modified by this patch will now have
correct dma-buf locking semantics: the caller is responsible for
holding the
Acquire the reservation lock directly in GEM pin callback. Same for
unpin. Prepares for further changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
qxl accordingly by pushing locking out of the implementation.
Rename __qxl_bo_pin() to qxl_bo_pin_locked() and update all callers.
The function will be helpful for implementing the GEM pin callback
with correct semantics. Same for __qxl_bo_unpin().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_object.c | 25 +
Acquire the reservation lock directly in GEM pin callback. Same for
unpin. Prepares for further changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
nouveau accordingly by pushing locking out of the
Implement pinning without locking in nouveau_bo_pin_locked(). Keep
nouveau_bo_pin() for acquiring the buffer object's reservation lock.
The new helper will be useful for implementing the GEM pin callback
with correct semantics. Same for unpin.
Signed-off-by: Thomas Zimmermann
---
Export msm_gem_pin_pages_locked() and acquire the reservation lock
directly in GEM pin callback. Same for unpin. Prepares for further
changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
msm accordingly by
Rename msm_gem_pin_pages_locked() to msm_gem_get_pages_locked(). The
function doesn't pin any pages, but only acquires them. Renaming the
function makes the old name available.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/msm/msm_gem.c | 8
1 file changed, 4 insertions(+), 4
Acquire the reservation lock directly in GEM pin callback. Same for
unpin. Prepares for further changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
gem-vram accordingly by pushing locking out of the
Export drm_gem_shmem_pin_locked() and acquire the reservation lock
directly in GEM pin callback. Same for unpin. Prepares for further
changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
gem-shmem accordingly
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in DRM's console emulation. Similar changes
for vmap and mmap have been posted at [1][2]
Most DRM drivers and memory managers
On 2/26/24 21:10, Harry Wentland wrote:
This is an RFC set for a color pipeline API, along with a sample
implementation in VKMS. All the key API bits are here. VKMS now
supports two named transfer function colorops and two matrix
colorops. We have IGT tests that check all four of these
Hello Melissa Wen,
This is a semi-automatic email about new static checker warnings.
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6683
amdgpu_dm_connector_funcs_force()
warn: variable dereferenced before check 'dc_link' (see line 6663)
48 matches
Mail list logo
