[AMD Official Use Only - Internal Distribution Only]
Ping
-Original Message-
From: Roy Sun
Sent: Tuesday, April 6, 2021 8:21 PM
To: amd-gfx@lists.freedesktop.org
Cc: Sun, Roy
Subject: [PATCH] drm/amd/amdgpu: Cancel the hrtimer in sw_fini
Move the process of cancelling hrtimer to
Hello,
On Fri, May 07, 2021 at 06:30:56PM -0400, Alex Deucher wrote:
> Maybe we are speaking past each other. I'm not following. We got
> here because a device specific cgroup didn't make sense. With my
> Linux user hat on, that makes sense. I don't want to write code to a
> bunch of device
On Fri, May 7, 2021 at 4:59 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, May 07, 2021 at 03:55:39PM -0400, Alex Deucher wrote:
> > The problem is temporal partitioning on GPUs is much harder to enforce
> > unless you have a special case like SR-IOV. Spatial partitioning, on
> > AMD GPUs at least,
Hello,
On Fri, May 07, 2021 at 03:55:39PM -0400, Alex Deucher wrote:
> The problem is temporal partitioning on GPUs is much harder to enforce
> unless you have a special case like SR-IOV. Spatial partitioning, on
> AMD GPUs at least, is widely available and easily enforced. What is
> the point
Ping?
Alex
On Fri, Apr 23, 2021 at 4:49 PM Alex Deucher wrote:
>
> Add missing structure elements.
>
> Fixes: 1ace37b873c2 ("drm/amdgpu/display: Implement functions to let DC
> allocate GPU memory")
> Signed-off-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 4
The DCN3 guards were dropped a while ago, this one must have
snuck in in a merge or something.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
Fixes:
At top level:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:633:13: warning:
‘dm_dmub_outbox1_low_irq’ defined but not used [-Wunused-function]
633 | static void dm_dmub_outbox1_low_irq(void *interrupt_params)
| ^~~
Fixes: 77a49c458931
Fixes:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
‘amdgpu_dm_initialize_drm_device’:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:3726:7: error:
implicit declaration of function ‘register_outbox_irq_handlers’; did you mean
‘register_hpd_handlers’?
On Fri, May 7, 2021 at 3:33 PM Tejun Heo wrote:
>
> Hello,
>
> On Fri, May 07, 2021 at 06:54:13PM +0200, Daniel Vetter wrote:
> > All I meant is that for the container/cgroups world starting out with
> > time-sharing feels like the best fit, least because your SRIOV designers
> > also seem to
xrandr --prop and other userspace info tools have currently no way of
telling which color configuration is used on HDMI and DP ports.
The ongoing transsition from HDMI 1.4 to 2.0 and the different bandwidth
requirements of YCbCr 4:2:0 and RGB color format raise different
incompatibilities. Having
Hello,
On Fri, May 07, 2021 at 06:54:13PM +0200, Daniel Vetter wrote:
> All I meant is that for the container/cgroups world starting out with
> time-sharing feels like the best fit, least because your SRIOV designers
> also seem to think that's the best first cut for cloud-y computing.
> Whether
Thank you Hawking for reviewing this. I made a mistake when I pushed this in. I
forgot to add " Reviewed-by: Hawking Zhang ".
Regards,
Oak
On 2021-05-07, 9:05 AM, "Zhang, Hawking" wrote:
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original
On Fri, May 7, 2021 at 2:57 PM Thomas Zimmermann wrote:
>
> This patch moves the DRM core's AGP code behind CONFIG_DRM_LEGACY. The
> only use besides legacy, UMS drivers is radeon, which can implement the
> required functionality by itself.
>
> This patchset has no impact on the AGP support of
New range is created to recover retry vm fault, set all GPUs have access
to the range. The new range preferred_loc is default value
KFD_IOCTL_SVM_LOCATION_UNDEFINED.
Correct one typo.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 7 +++
1 file changed, 3
Acked-by: Christian König
Am 07.05.21 um 20:57 schrieb Thomas Zimmermann:
This patch moves the DRM core's AGP code behind CONFIG_DRM_LEGACY. The
only use besides legacy, UMS drivers is radeon, which can implement the
required functionality by itself.
This patchset has no impact on the AGP
With the AGP code already duplicated, move over the AGP structures
from the legacy code base in to radeon. The AGP data structures that
are required by radeon are now declared within the driver. The AGP
instance is stored in struct radeon_device.agp.
Signed-off-by: Thomas Zimmermann
---
Radeon calls DRMs core AGP helpers. These helpers are only required
by legacy drivers. Reimplement the code in radeon to uncouple radeon
from the legacy code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon.h | 8 +++
drivers/gpu/drm/radeon/radeon_agp.c | 102
This patch moves the DRM core's AGP code behind CONFIG_DRM_LEGACY. The
only use besides legacy, UMS drivers is radeon, which can implement the
required functionality by itself.
This patchset has no impact on the AGP support of existing drivers.
Patches 1 and 2 move some AGP code from DRM core
DRM's AGP helpers for PCI are only required by legacy drivers. Put them
behind CONFIG_DRM_LEGACY and add the _legacy_ infix.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_drv.c | 4 +---
drivers/gpu/drm/drm_internal.h | 5 -
drivers/gpu/drm/drm_legacy.h | 6 ++
Only UMs drivers use DRM's core AGP code and ioctls. Mark the icotls
as legacy. Add the _legacy_ infix to all AGP functions. Move the
declarations to the public and internal legacy header files. The agp
field in struct drm_device is now located in the structure's legacy
section. Adapt drivers to
[AMD Public Use]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, on the following display types: eDP 1080p
60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to DP/HDMI),
1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
On 2021-05-07 12:24 p.m., Daniel Vetter wrote:
On Fri, May 07, 2021 at 11:39:49AM -0400, Andrey Grodzovsky wrote:
On 2021-05-07 5:11 a.m., Daniel Vetter wrote:
On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
On Fri, Apr
On Fri, May 7, 2021 at 12:54 PM Daniel Vetter wrote:
>
> SRIOV is kinda by design vendor specific. You set up the VF endpoint, it
> shows up, it's all hw+fw magic. Nothing for cgroups to manage here at all.
Right, so in theory you just use the device cgroup with the VF endpoints.
> All I meant
On Fri, May 07, 2021 at 12:50:07PM -0400, Alex Deucher wrote:
> On Fri, May 7, 2021 at 12:31 PM Alex Deucher wrote:
> >
> > On Fri, May 7, 2021 at 12:26 PM Daniel Vetter wrote:
> > >
> > > On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> > > > On Fri, May 7, 2021 at 12:13 PM
On Fri, May 7, 2021 at 12:31 PM Alex Deucher wrote:
>
> On Fri, May 7, 2021 at 12:26 PM Daniel Vetter wrote:
> >
> > On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> > > On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
> > > >
> > > > On Fri, May 07, 2021 at 11:33:46AM -0400,
On 2021-05-07 12:29 p.m., Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 12:10:57PM -0400, Andrey Grodzovsky wrote:
On 2021-04-30 2:47 a.m., Christian König wrote:
Am 29.04.21 um 19:06 schrieb Andrey Grodzovsky:
On 2021-04-29 3:18 a.m., Christian König wrote:
I need to take another
On Fri, May 7, 2021 at 12:26 PM Daniel Vetter wrote:
>
> On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> > On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
> > >
> > > On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> > > > On Fri, May 7, 2021 at 4:59 AM Daniel
On Fri, Apr 30, 2021 at 12:10:57PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-04-30 2:47 a.m., Christian König wrote:
> >
> >
> > Am 29.04.21 um 19:06 schrieb Andrey Grodzovsky:
> > >
> > >
> > > On 2021-04-29 3:18 a.m., Christian König wrote:
> > > > I need to take another look at this
On Fri, May 07, 2021 at 12:19:13PM -0400, Alex Deucher wrote:
> On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
> >
> > On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> > > On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
> > > >
> > > > Hm I missed that. I feel like
On Fri, May 07, 2021 at 11:39:49AM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-05-07 5:11 a.m., Daniel Vetter wrote:
> > On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
> > >
> > >
> > > On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
> > > > On Fri, Apr 30, 2021 at
On Fri, May 7, 2021 at 12:13 PM Daniel Vetter wrote:
>
> On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> > On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
> > >
> > > Hm I missed that. I feel like time-sliced-of-a-whole gpu is the easier gpu
> > > cgroups controler to get
On Fri, May 07, 2021 at 11:33:46AM -0400, Kenny Ho wrote:
> On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
> >
> > Hm I missed that. I feel like time-sliced-of-a-whole gpu is the easier gpu
> > cgroups controler to get started, since it's much closer to other cgroups
> > that control
Hi!
Dne petek, 30. april 2021 ob 11:44:50 CEST je Maxime Ripard napisal(a):
> The intel driver uses the same logic to attach the Colorspace property
> in multiple places and we'll need it in vc4 too. Let's move that common
> code in a helper.
>
> Signed-off-by: Maxime Ripard
> ---
>
> Changes
Hi!
Dne petek, 30. april 2021 ob 11:44:51 CEST je Maxime Ripard napisal(a):
> Our driver while supporting HDR didn't send the proper colorimetry info
> in the AVI infoframe.
>
> Let's add the property needed so that the userspace can let us know what
> the colorspace is supposed to be.
>
>
On 2021-05-07 5:11 a.m., Daniel Vetter wrote:
On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
On Fri, Apr 30, 2021 at 01:27:37PM -0400, Andrey Grodzovsky wrote:
On 2021-04-30 6:25 a.m., Daniel Vetter wrote:
On Thu, Apr
On Fri, May 7, 2021 at 4:59 AM Daniel Vetter wrote:
>
> Hm I missed that. I feel like time-sliced-of-a-whole gpu is the easier gpu
> cgroups controler to get started, since it's much closer to other cgroups
> that control bandwidth of some kind. Whether it's i/o bandwidth or compute
> bandwidht
Hi Takashi,
Am 07.05.21 um 17:08 schrieb Takashi Iwai:
Hi,
we've received a regression report showing NULL dereference Oops with
radeon driver on 5.12 kernel:
https://bugzilla.opensuse.org/show_bug.cgi?id=1185516
It turned out that the recent TTM cleanup / refactoring via commit
Hi,
we've received a regression report showing NULL dereference Oops with
radeon driver on 5.12 kernel:
https://bugzilla.opensuse.org/show_bug.cgi?id=1185516
It turned out that the recent TTM cleanup / refactoring via commit
0575ff3d33cd ("drm/radeon: stop using pages with
On 2021-05-07 10:39 a.m., Rodrigo Siqueira wrote:
The amdgpu_dm file contains most of the code that works as an interface
between DRM API and Display Core. We maintain all the plane operations
inside amdgpu_dm; this commit extracts the plane code to its specific
file named amdgpu_dm_plane. This
From: Aric Cyr
- adding missed FW promotion
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
Acked-by: Stylon Wang
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
From: Anthony Koo
- Implement INBOX0 messaging for HW lock
Signed-off-by: Anthony Koo
Reviewed-by: Anthony Koo
Acked-by: Stylon Wang
---
.../gpu/drm/amd/display/dmub/inc/dmub_cmd.h | 123 +-
1 file changed, 116 insertions(+), 7 deletions(-)
diff --git
From: Aric Cyr
Signed-off-by: Aric Cyr
Reviewed-by: Aric Cyr
Acked-by: Stylon Wang
---
drivers/gpu/drm/amd/display/dc/dc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc.h
b/drivers/gpu/drm/amd/display/dc/dc.h
index
From: Dmytro Laktyushkin
Right now the flag simply selects memory config 0 when flag is true
however 420 modes benefit more from memory config 3.
Signed-off-by: Dmytro Laktyushkin
Reviewed-by: Aric Cyr
Acked-by: Stylon Wang
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_dpp_dscl.c | 9
From: Anthony Wang
[Why]
In some pipe harvesting configs, we will select the incorrect
dpp_inst when programming DTO. This is because when any intermediate
pipe is fused, resource instances are no longer in 1:1
correspondence with pipe index.
[How]
When looping through pipes to program DTO, get
From: Ilya Bakoulin
[Why]
Some DSC tests fail because stream pixel encoding does not change
its value according to the type requested in the DPCD test params.
[How]
Set stream pixel encoding before updating DSC config and configuring
the test pattern.
Signed-off-by: Ilya Bakoulin
Reviewed-by:
On 2021-05-07 10:37 a.m., Rodrigo Siqueira wrote:
Currently, we reject all conditions where the underlay plane goes
outside the overlay plane limits, which is not entirely correct since we
reject some valid cases like the ones illustrated below:
++ ++
From: Ilya Bakoulin
[Why]
Currently, the code that fills the clock table can miss filling
information about some of the higher voltage states advertised
by the SMU. This, in turn, may cause some of the higher pixel clock
modes (e.g. 8k60) to fail validation.
[How]
Fill the table with one entry
From: Wenjing Liu
[how]
The change includes some dp link training refactors:
1. break down is_ch_eq_done to checking individual conditions in
its own function.
2. update dpcd_set_training_pattern to take in dc_dp_training_pattern
as input.
3. moving lttpr mode struct definition into
From: Chaitanya Dhere
[Why]
DETBufferSizeInKByte is not expected to be sub-dividable, hence
unsigned int is a better suited data-type. Change it to an array
as well to satisfy current requirements.
[How]
Change the data-type of DETBufferSizeInKByte to an unsigned int
array. Modify the all the
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
Reviewed-by: Mikita Lipski
Acked-by: Stylon Wang
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
From: Jimmy Kizito
[Why & How]
Add functionality useful for DP link training to public interface.
Signed-off-by: Jimmy Kizito
Reviewed-by: Jun Lei
Acked-by: Stylon Wang
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 10 +-
drivers/gpu/drm/amd/display/dc/inc/dc_link_dp.h |
From: Jimmy Kizito
[Why]
When enabling a DisplayPort stream:
- Optionally reducing link bandwidth between failed link training
attempts should progressively relax training requirements.
- Abandoning link training altogether if a sink is unplugged should
avoid unnecessary training attempts.
From: Jimmy Kizito
[Why]
Some links are dynamically assigned link encoders on stream enablement.
[How]
Update DisplayPort training parameter determination stage that assumes
link encoder statically assigned to link.
Signed-off-by: Jimmy Kizito
Reviewed-by: Jun Lei
Acked-by: Stylon Wang
---
From: Jimmy Kizito
[Why]
Some extra provisions are required during DPRX detection for links which
lack physical HPD and AUX/DDC pins.
[How]
Avoid attempting to access nonexistent physical pins during DPRX
detection.
Signed-off-by: Jimmy Kizito
Reviewed-by: Jun Lei
Acked-by: Stylon Wang
---
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
* DC v3.2.135.1
* Improvements across DP, DPP, clock management, pixel formats
Anthony Koo (1):
drm/amd/display: [FW Promotion] Release 0.0.65
Anthony Wang (1):
drm/amd/display: Handle potential dpp_inst
[AMD Official Use Only - Internal Distribution Only]
Patch is:
Reviewed-by: John Clements
From: Tuikov, Luben
Sent: Thursday, May 6, 2021 8:10 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Clements, John ; Zhang,
Hawking
[AMD Official Use Only - Internal Distribution Only]
Series is:
Reviewed-by: John Clements
From: Tuikov, Luben
Sent: Wednesday, May 5, 2021 5:47 AM
To: amd-gfx@lists.freedesktop.org
Cc: Tuikov, Luben ; Deucher, Alexander
; Clements, John ; Zhang,
Hawking
The amdgpu_dm file contains most of the code that works as an interface
between DRM API and Display Core. We maintain all the plane operations
inside amdgpu_dm; this commit extracts the plane code to its specific
file named amdgpu_dm_plane. This commit does not introduce any
functional change to
Currently, we reject all conditions where the underlay plane goes
outside the overlay plane limits, which is not entirely correct since we
reject some valid cases like the ones illustrated below:
++ ++
| Overlay plane| | Overlay plane|
|
[AMD Official Use Only - Internal Distribution Only]
For libdrm tests, please open a gitlab merge request:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests
Alex
From: amd-gfx on behalf of Yu, Lang
Sent: Friday, May 7, 2021 3:10 AM
To: Chen, Guchun ;
[AMD Public Use]
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Zeng, Oak
Sent: Friday, May 7, 2021 09:15
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Lazar, Lijo ;
Clements, John ; Joshi, Mukul ;
Zeng, Oak
Subject: [PATCH] drm/amdgpu: Quit RAS
On Thu, May 06, 2021 at 12:10:15PM -0400, Felix Kuehling wrote:
> Am 2021-05-04 um 9:00 a.m. schrieb Daniel Vetter:
> > On Fri, Apr 30, 2021 at 09:57:45PM -0400, Felix Kuehling wrote:
> >> We have been working on a prototype supporting CRIU (Checkpoint/Restore
> >> In Userspace) for accelerated
On Thu, May 06, 2021 at 12:25:06PM -0400, Andrey Grodzovsky wrote:
>
>
> On 2021-05-06 5:40 a.m., Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 01:27:37PM -0400, Andrey Grodzovsky wrote:
> > >
> > >
> > > On 2021-04-30 6:25 a.m., Daniel Vetter wrote:
> > > > On Thu, Apr 29, 2021 at
On Thu, May 06, 2021 at 10:06:32PM -0400, Kenny Ho wrote:
> Sorry for the late reply (I have been working on other stuff.)
>
> On Fri, Feb 5, 2021 at 8:49 AM Daniel Vetter wrote:
> >
> > So I agree that on one side CU mask can be used for low-level quality
> > of service guarantees (like the
Am 07.05.21 um 00:37 schrieb David M Nieto:
The proper metric for fence utilization over several
contexts is an harmonic mean, but such calculation is
prohibitive in kernel space, so the code approximates it.
Because the approximation diverges when one context has a
very small ratio compared
[AMD Official Use Only - Internal Distribution Only]
Reviewed-by: Lang Yu
Regards，
Lang
-Original Message-
From: Chen, Guchun
Sent: Thursday, May 6, 2021 5:55 PM
To: amd-gfx@lists.freedesktop.org; Yu, Lang ; Huang, Ray
; Song, Asher
Cc: Chen, Guchun
Subject: [PATCH libdrm]
66 matches
Mail list logo
