[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 |
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
---
[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
>
[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:
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
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]
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
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
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
---
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
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
---
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
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
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
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:
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:
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 +
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
[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:
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
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
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
[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
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
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
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
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:
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:
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:
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
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
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
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:
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:
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
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:
[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
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
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
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
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
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:
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
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
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
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
46 matches
Mail list logo
