From: Xiaogang Chen
During miration to vram prange->offset is valid after vram buffer is located,
either use old one or allocate a new one. Move svm_range_vram_node_new before
migrate
for each vma to get valid prange->offset.
Signed-off-by: Xiaogang Chen
---
drivers/gpu/drm/amd/amdkfd/kfd_mig
[Why]
Currently there aren't any methods to determine PSR state residency.
[How]
create a sysfs entry for reading residency and internally hook it up
to existing functionality of reading PSR residency from firmware.
Signed-off-by: Shirish S
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 19
Am 08.03.23 um 03:26 schrieb Steven Rostedt:
On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt wrote:
Looks like there was a lock possibly used after free. But as commit
9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
workers") changed a lot of this code, I figured it may
On Tue, 2023-02-28 at 09:34 +0100, Christian König wrote:
> VMWGFX is the only remaining user of this and should probably moved over
> to drm_exec when it starts using GEM as well.
Is this because vmwgfx piggybacks buffer-id relocations on top of ttm
validations or
did you just find it too hard t
Hi @Tuikov, Luben,
>> >> we have to force signal the non_sched bad job's fence during
>> >> pre_asic_reset or the clear is not complete.
>>Do you want to add a function which does just this (signals non-scheduler job
>>fences) in amdgpu_device_pre_asic_reset(), and resubmit your patch? (There
>
Align the SMU driver interface version with PMFW to
suppress the version mismatch message on driver loading.
Signed-off-by: Tim Huang
---
.../drm/amd/pm/swsmu/inc/pmfw_if/smu13_driver_if_v13_0_4.h| 4 ++--
drivers/gpu/drm/amd/pm/swsmu/inc/smu_v13_0.h | 2 +-
2 files changed,
Hi Luben,
I was comparing the bad jobs of failed ib test and the ones that causes the
TDR, and I think the main difference is whether it is submitted via drm_sched
or not. In simple test cases it doesn't seem to incorrectly signal the fences
that shouldn't be signaled. We indeed may need more h
[AMD Official Use Only - General]
Thanks Alex. I probably get the root cause of the issue. It should be related
with the BTC feature.
- On cold boot, BTC was triggered and GfxVfCurve was calibrated.
We got VfCurve settings (a).
- On resuming back, BTC will be triggered again and GfxVfCurve wil
Set *q to NULL on errors, otherwise pqm_create_queue would free it
again.
Signed-off-by: Chia-I Wu
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c
b/drivers/
On 3/7/23 15:53, David Tadokoro wrote:
The fields blends_with_above and blends_with_below of struct
dc_plane_cap (defined in dc/dc.h) are boolean and set to true by
default. All instances of a dc_plane_cap maintain the default values of
both. Also, there is only one if statement that checks th
On 2/28/23 12:54, Alex Deucher wrote:
This reverts commit fa458eb10dc7218146a84e6d2e072424e64d188a.
The issue is no longer present even with this commit present
as verified by the original reporter.
Signed-off-by: Alex Deucher
Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1849#note_
On 2023-03-07 15:36, Luben Tuikov wrote:
> + job = container_of(old, struct amdgpu_job, hw_fence);
> + if (!job->base.s_fence && !dma_fence_is_signaled(old))
> + dma_fence_signal(old);
Thinking about this more, is !job->base.s_fen
Hi,
Thanks for your patch!
On 2023-03-07 02:07, Christian König wrote:
> Am 07.03.23 um 08:02 schrieb YuBiao Wang:
>> [Why]
>> For engines not supporting soft reset, i.e. VCN, there will be a failed
>> ib test before mode 1 reset during asic reset. The fences in this case
>> are never signaled an
From: Bjorn Helgaas
pci_enable_pcie_error_reporting() enables the device to send ERR_*
Messages. Since f26e58bf6f54 ("PCI/AER: Enable error reporting when AER is
native"), the PCI core does this for all devices during enumeration, so the
driver doesn't need to do it itself.
Remove the redundant
Some amdgpu_dm_crtc.h functions didn't have names that indicated where
they were declared.
To better filter results in debug tools like ftrace, prefix these
functions with 'amdgpu_dm_crtc_'.
Signed-off-by: David Tadokoro
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +--
Applied. Thanks.
Alex
On Mon, Mar 6, 2023 at 11:17 AM Felix Kuehling wrote:
>
> Looks like this patch got lost over the holidays. Alex, are you OK with
> applying this patch? Or are people looking for a more general solution
> to not build HW drivers for UML? FWIW:
>
> Acked-by: Felix Kuehling
[AMD Official Use Only - General]
Thanks Felix for your feedback.
I will work on applying your suggested approach and uploaded a second version
when it is ready.
David B.
> -Original Message-
> From: Kuehling, Felix
> Sent: Monday, March 6, 2023 6:46 PM
> To: amd-gfx@lists.freedesktop.
Applied. Thanks!
On Sun, Mar 5, 2023 at 5:22 PM Husain Alshehhi wrote:
>
> Replace "isntance" with "instance".
>
> Signed-off-by: Husain Alshehhi
> ---
> .../gpu/drm/amd/display/dmub/inc/dmub_cmd.h| 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/d
On Mon, Mar 6, 2023 at 3:23 AM David Tadokoro wrote:
>
> From: David Tadokoro
>
> The amdgpu_dm_plane.h functions didn't have names that indicated where
> they were declared.
>
> To better filter results in debug tools like ftrace, prefix these
> functions with 'amdgpu_dm_plane_'.
>
> Note that w
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
v4: Drop unnecessary '&' from kerneldoc (emersion)
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
[AMD Official Use Only - General]
The test case is a python program that will load the driver, do some
operations, then unload the driver.
When the driver exists, there is still the python process space around holding
on the address space.
When the python process space exits, the mmu_notifier g
On Tue, Mar 7, 2023 at 3:23 AM Quan, Evan wrote:
>
> [AMD Official Use Only - General]
>
> Can you share more background about this? I cannot see how this can address
> incorrect OD voltage issue.
See https://gitlab.freedesktop.org/drm/amd/-/issues/1897
The OD settings don't seem to be restored
On Tuesday, March 7th, 2023 at 16:10, Harry Wentland
wrote:
> * This enum is used to indicate DP VSC SDP Colorimetry formats.
> * It is based on DP 1.4 spec [Table 2-117: VSC SDP Payload for DB16 through
> - * DB18] and a name of enum member follows DRM_MODE_COLORIMETRY definition.
> + * DB18] a
In order to IGT test colorspace we'll want to print
the currently enabled colorspace on a stream. We add
a new debugfs to do so, using the same scheme as
current bpc reporting.
This might also come in handy when debugging display
issues.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Seba
From: Joshua Ashton
Replace the messy two if-else chains here that were
on the same value with a switch on the enum.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.
We use this by default but if userspace passes this explicitly
we should respect it.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 43 ++-
1 file
From: Joshua Ashton
Userspace might not aware whether we're sending RGB or YCbCr
data to the display. If COLOR_SPACE_2020_RGB_FULLRANGE is
requested but the output encoding is YCbCr we should
send COLOR_SPACE_2020_YCBCR.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paal
We want compositors to be able to set the output
colorspace on DP and HDMI outputs, based on the
caps reported from the receiver via EDID.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: am
We need to signal mode_changed to make sure we update the output
colorspace.
v2: No need to call drm_hdmi_avi_infoframe_colorimetry as DC does its
own infoframe packing.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Vill
From: Joshua Ashton
Given that we always pass dm_state into here now, this won't ever
trigger anymore.
This is needed for we will always fail mode validation with invalid
clocks or link bandwidth errors.
Signed-off-by: Joshua Ashton
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebast
Look at connector->colorimetry to determine output colorspace.
We don't want to impact current SDR behavior, so
DRM_MODE_COLORIMETRY_DEFAULT preserves current behavior.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de.
From: Joshua Ashton
To match the other enums, and add more information about these values.
v2:
- Specify where an enum entry comes from
- Clarify DEFAULT and NO_DATA behavior
- BT.2020 CYCC is "constant luminance"
- correct type for BT.601
Signed-off-by: Joshua Ashton
Signed-off-by: Harry
v3: Fix kerneldocs (kernel test robot)
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua
Drivers might not support all colorspaces defined in
dp_colorspaces and hdmi_colorspaces. This results in
undefined behavior when userspace is setting an
unsupported colorspace.
Allow drivers to pass the list of supported colorspaces
when creating the colorspace property.
v2:
- Use 0 to indicate
We an use bitfields to track the support ones for HDMI
and DP. This allows us to print colorspaces in a consistent
manner without needing to know whether we're dealing with
DP or HDMI.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
We need the connector_state for colorspace and scaling information
and can get it from connector->state.
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Joshua Ashton
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Review
Signed-off-by: Harry Wentland
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: Jani Nikula
Cc: dri-de...@lists.freedesktop.org
Cc: amd-gfx@lists.freedesktop.org
Reviewed-By: Joshua Ashton
---
drivers/gpu/drm/drm_connec
This patchset is based on Joshua's previous patchset [1], as well
as my previous patchset [2].
It is
- enabling support for the colorspace property in amdgpu, as well as
- allowing drivers to specify the supported set of colorspaces, and
- deprecating the BT2020_YCC and BT2020_RGB properties in fa
From: Joshua Ashton
Userspace has no way of controlling or knowing the pixel encoding
currently, so there is no way for it to ever get the right values here.
When we do add pixel_encoding control from userspace,we can pick the
right value for the colorimetry packet based on the
pixel_encoding +
This allows us to use strongly typed arguments.
v2:
- Bring NO_DATA back
- Provide explicit enum values
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
Cc: Pekka Paalanen
Cc: Sebastian Wick
Cc: vitaly.pros...@amd.com
Cc: Uma Shankar
Cc: Ville Syrjälä
Cc: Joshua Ashton
Cc: dri-de...
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 709c6adf19dc558e44ab5c01659b09a16a2d3c82 Add linux-next specific
files for 20230307
Warning reports:
https://lore.kernel.org/oe-kbuild-all/202302111601.jty4lkra-...@intel.com
https
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, March 7, 2023 22:02
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: fix error checking in amdgpu_read_mm_registers for
nv
Properl
Properly skip non-existent registers as well.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/nv.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/nv.c b/drivers/gpu/drm/amd/amdgpu/nv.c
index d972025f0d20..855d390c41de 100644
--- a
[AMD Official Use Only - General]
Can you share more background about this? I cannot see how this can address
incorrect OD voltage issue.
BR
Evan
> -Original Message-
> From: amd-gfx On Behalf Of
> Blazej Szczygiel
> Sent: Sunday, March 5, 2023 7:45 AM
> To: amd-gfx@lists.freedesktop.or
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Monday, March 6, 2023 11:54 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH 1/2] drm/amdgpu: fix error checking in
> amdgp
46 matches
Mail list logo
