[AMD Official Use Only]
Hi Alex
The function amdgpu_restore_msix is used for reset the msix during board
reset(sriov reset or asic reset), it moves from host to guest, so I think a
flag to indicate if msix enabled is not needed.
-
[Why]
If flr_work takes read_lock, then other threads who takes
read_lock can access hardware when host is doing vf flr.
[How]
flr_work should take write_lock to avoid this case.
Signed-off-by: Jingwen Chen
---
drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/mxgpu_nv.
On Wed, Jun 30, 2021 at 8:35 AM Ketsui wrote:
>
> >I could be wrong. I can't remember what marketing names map to what
> >asics. I can tell if you can get your dmesg output.
> Here it is.
Thanks. It is a picasso system.
Alex
> ___
> amd-gfx mailing l
It is based on reverting two patches back.
drm/amdkfd: Make TLB flush conditional on mapping
drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/d
On Wed, Jun 30, 2021 at 10:34 PM Zhou, Peng Ju wrote:
>
> [AMD Official Use Only]
>
> Hi Alex
> The function amdgpu_restore_msix is used for reset the msix during board
> reset(sriov reset or asic reset), it moves from host to guest, so I think a
> flag to indicate if msix enabled is not needed.
On 2021-06-30 6:03 p.m., Eric Huang wrote:
It is based on reverting two patches back.
drm/amdkfd: Make TLB flush conditional on mapping
drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update
Signed-off-by: Eric Huang
I'd prefer to put HW-specific workarounds in
amdgpu_amdkfd_gpuv
It is based on reverting two patches back.
drm/amdkfd: Make TLB flush conditional on mapping
drm/amdgpu: Add table_freed parameter to amdgpu_vm_bo_update
Signed-off-by: Eric Huang
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/g
On 2021-06-29 11:19 a.m., Nirmoy Das wrote:
Use new helper function amdgpu_vm_set_pasid() to
assign vm pasid value. This also ensures that we don't free
a pasid from vm code as pasids are allocated somewhere else.
Signed-off-by: Nirmoy Das
Christian's comments notwithstanding, the series is
On 2021-06-30 6:10 a.m., YuBiao Wang wrote:
> [Why]
> GPU timing counters are read via KIQ under sriov, which will introduce
> a delay.
>
> [How]
> It could be directly read by MMIO.
>
> v2: Add additional check to prevent carryover issue.
> v3: Only check for carryover for once to prevent performa
Reviewed-by: Luben Tuikov
On 2021-06-30 11:25 a.m., Alex Deucher wrote:
> pos is 64 bits.
>
> Fixes: 5e98eafa90ca19 ("drm/amdgpu: RAS EEPROM table is now in debugfs")
> Cc: luben.tui...@amd.com
> Reported-by: kernel test robot
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/am
pos is 64 bits.
Fixes: 5e98eafa90ca19 ("drm/amdgpu: RAS EEPROM table is now in debugfs")
Cc: luben.tui...@amd.com
Reported-by: kernel test robot
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
d
On 2021-06-30 10:07 a.m., Nicholas Kazlauskas wrote:
> [Why & How]
> Extend existing support for DCN2.1 DMUB diagnostic logging to
> DCN3.1 so we can collect useful information if the DMUB hangs.
>
> Signed-off-by: Nicholas Kazlauskas
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd
[Why & How]
Extend existing support for DCN2.1 DMUB diagnostic logging to
DCN3.1 so we can collect useful information if the DMUB hangs.
Signed-off-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/display/dmub/src/dmub_dcn31.c | 60 +++
.../gpu/drm/amd/display/dmub/src/dmub_dcn31.h |
Am 30.06.21 um 13:17 schrieb Liu, Monk:
[AMD Official Use Only]
And a preempt_enable(); here. This way the critical section is also not
interrupted by a task switch.
Do you mean put a "preempt_disable()" here ?
No? We need to disable preemption before the critical section and enable
it aga
[AMD Official Use Only]
>> And a preempt_enable(); here. This way the critical section is also not
>> interrupted by a task switch.
Do you mean put a "preempt_disable()" here ?
Thanks
--
Monk Liu | Cloud-GPU Core team
--
[AMD Official Use Only]
reviewed-by: Monk Liu
Thanks
--
Monk Liu | Cloud-GPU Core team
--
-Original Message-
From: YuBiao Wang
Sent: Wednesday, June 30, 2021 6:10 PM
To: amd-gfx@lists.freedesktop.org
Cc:
Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.
Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detect
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.
This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i91
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4
2 files changed, 15 insertions(+), 3 deletions(-
This commit implements the "active color format" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 31 insertions(+), 2 deletions(-
This commit implements the "active color range" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 37 insertions(+)
diff --git a/d
This commit implements the "preferred color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++
3 f
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr4
This commit implements the "preferred color format" drm property for the
AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 28 insertions(+), 6 deletion
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monito
This commit implements the "active color range" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/g
Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.
There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor a
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports d
Add a new general drm property "active bpc" which can be used by graphic
drivers to report the applied bit depth per pixel color back to userspace.
While "max bpc" can be used to change the color depth, there was no way to
check which one actually got used. While in theory the driver chooses the
b
This commit implements the "active color format" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c |
This commit implements the "active bpc" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 19 +++
drivers/gpu/drm/i915/display/intel_dp.c | 7 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to
an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11
missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/dri
Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete
albeit not fully tested.
I have now corrected the DSC behavior, but still no wait to test it.
Exact dithering behavior remains a mistery so in case dithering is active it's
not 100% clear what "active bpc" means, or where
This commit implements the "active bpc" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 27 insertions(+), 1 deletion(-)
diff -
Hello,
Running the gst-plugins-base testsuite makes my Lenovo T459 entirely hang, to
the point where even SSH doesn't works.
I also get quite random glitches while using mpv, specially HTTP streams (NFS
is fine)
and browsing the web (webkit-gtk, firefox, chromium, …) but in this case
the driver
On Wed, Jun 30, 2021, at 05:10, YuBiao Wang wrote:
> [Why]
> GPU timing counters are read via KIQ under sriov, which will introduce
> a delay.
>
> [How]
> It could be directly read by MMIO.
>
> v2: Add additional check to prevent carryover issue.
> v3: Only check for carryover for once to prevent
[Why]
GPU timing counters are read via KIQ under sriov, which will introduce
a delay.
[How]
It could be directly read by MMIO.
v2: Add additional check to prevent carryover issue.
v3: Only check for carryover for once to prevent performance issue.
v4: Add comments of the rough frequency where car
Am 24.06.21 um 06:51 schrieb Mikel Rychliski:
radeon_ttm_bo_destroy() is attempting to access the resource object to
update memory counters. However, the resource object is already freed when
ttm calls this function via the destroy callback. This causes an oops when
a bo is freed:
BUG: k
>I could be wrong. I can't remember what marketing names map to what
>asics. I can tell if you can get your dmesg output.
Here it is.
dmesg
Description: Binary data
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mai
On Wed, 30 Jun 2021 04:28:39 -0700
Joe Perches wrote:
> On Sat, 2021-06-12 at 08:42 -0700, Joe Perches wrote:
> > The __assign_str macro has an unusual ending semicolon but the vast
> > majority of uses of the macro already have semicolon termination.
>
> ping?
>
I wasn't sure I was the one
On Sat, 2021-06-12 at 08:42 -0700, Joe Perches wrote:
> The __assign_str macro has an unusual ending semicolon but the vast
> majority of uses of the macro already have semicolon termination.
ping?
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
On 6/29/2021 7:40 PM, Christian König wrote:
Am 29.06.21 um 17:19 schrieb Nirmoy Das:
Replace idr with xarray as we actually need hash functionality.
Cleanup code related to vm pasid by adding helper function.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 149
Am 30.06.21 um 12:10 schrieb YuBiao Wang:
[Why]
GPU timing counters are read via KIQ under sriov, which will introduce
a delay.
[How]
It could be directly read by MMIO.
v2: Add additional check to prevent carryover issue.
v3: Only check for carryover for once to prevent performance issue.
v4: A
On 2021-06-11 9:05 a.m., Hawking Zhang wrote:
> PSP will dump various boot up information into a
> portion of local frame buffer, called runtime database.
> The helper function is used for driver to query those
> shared information.
>
> v2: init ret and check !ret to exit loop as soon as
> found t
[AMD Official Use Only]
Reviewed-by: Huang Rui
-Original Message-
From: Liu, Aaron
Sent: Wednesday, June 30, 2021 1:57 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Huang, Ray
; Gong, Curry ; Kuehling, Felix
; Liu, Aaron ; Huang, Ray
Subject: [PATCH] drm/amdgpu: Mak
From: chen gong
Performing kfd page fault tests on the yellow carp platform will fail.
>From the scan data after the failure, it can be found that a
nack=0x1(retry fault) is returned. but we did not enable the interrupts
for retry faults in the code.
So we need to set noretry = 1 like the above
Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
Am 28.06.21 um 19:03 schrieb Werner Sembach:
Am 18.06.21 um 11:11 schrieb Werner Sembach:
Add a new general drm property "active bpc" which can be used by graphic
drivers to report the app
On 6/30/2021 10:01 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Wednesday, June 30, 2021 11:52 AM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 1/2] drm/amd/pm: update the gpu metrics data
ret
Am 29.06.21 um 12:01 schrieb YuBiao Wang:
[Why]
GPU timing counters are read via KIQ under sriov, which will introduce
a delay.
[How]
It could be directly read by MMIO.
v2: Add additional check to prevent carryover issue.
v3: Only check for carryover for once to prevent performance issue.
Sign
Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach wrote:
Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
On Tue, 29 Jun 2021 08:12:54 +
Simon Ser wrote:
On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
wrote:
yes, I think this make
On Tue, 29 Jun 2021 13:39:18 +0200
Werner Sembach wrote:
> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 08:12:54 +
> > Simon Ser wrote:
> >
> >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
> >> wrote:
> >>
> >>> yes, I think this makes sense, even if it
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Wednesday, June 30, 2021 11:52 AM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 1/2] drm/amd/pm: update the gpu metrics data
> retrieving for Sienna Cichlid
>
>
On Tue, 29 Jun 2021 13:02:05 +0200
Werner Sembach wrote:
> Am 28.06.21 um 19:03 schrieb Werner Sembach:
> > Am 18.06.21 um 11:11 schrieb Werner Sembach:
> >> Add a new general drm property "active bpc" which can be used by graphic
> >> drivers to report the applied bit depth per pixel back to u
Other than the updated patch description for patch 1, the series
(patches 1-10) is
Reviewed-by: Felix Kuehling
Patch 11 was already reviewed and revised separately.
Thanks,
Felix
Am 2021-06-30 um 12:00 a.m. schrieb Felix Kuehling:
> Am 2021-06-29 um 2:01 p.m. schrieb Alex Sierra:
>> pgmap o
Am 2021-06-29 um 2:01 p.m. schrieb Alex Sierra:
> pgmap owner member at the svm migrate init could be referenced
> to either adev or hive, depending on device topology.
Please update the commit description before submitting the change:
GPUs in the same XGMI hive have direct access to all members'
On 6/30/2021 8:56 AM, Quan, Evan wrote:
[AMD Official Use Only]
-Original Message-
From: Lazar, Lijo
Sent: Tuesday, June 29, 2021 9:38 PM
To: Quan, Evan ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 1/2] drm/amd/pm: update the gpu metrics data
retriev
Add the MODE register into the per-wave debug information.
This register holds state such as FP rounding and denorm
modes, which exceptions are enabled, and active clamping
modes.
Signed-off-by: Joseph Greathouse
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v6
[AMD Official Use Only]
> -Original Message-
> From: Lazar, Lijo
> Sent: Tuesday, June 29, 2021 9:38 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH 1/2] drm/amd/pm: update the gpu metrics data
> retrieving for Sienna Cichlid
>
>
>
58 matches
Mail list logo