Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.

On Mon, Sep 07, 2020 at 03:53:02PM +0200, Daniel Vetter wrote: > On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote: > > > > Add drm_device argument to drm_prime_pages_to_sg(), so we can > > call dma_max_mapping_size() to figure the segment size limit > > and call into

Re: [PATCH v2] drm/kfd: fix a system crash issue during GPU recovery

Am 2020-09-02 um 1:02 a.m. schrieb Dennis Li: > The crash log as the below: > > [Thu Aug 20 23:18:14 2020] general protection fault: [#1] SMP NOPTI > [Thu Aug 20 23:18:14 2020] CPU: 152 PID: 1837 Comm: kworker/152:1 Tainted: G > OE 5.4.0-42-generic #46~18.04.1-Ubuntu > [Thu Aug

Re: [PATCH] drm/amdkfd: fix a memory leak issue

Am 2020-09-02 um 5:32 a.m. schrieb Dennis Li: > In the resume stage of GPU recovery, start_cpsch will call pm_init > which set pm->allocated as false, cause the next pm_release_ib has > no chance to release ib memory. > > Add pm_release_ib in stop_cpsch which will be called in the suspend > stage

Re: [PATCH] drm/amdgpu: enable ih1 ih2 for Arcturus only

Am 2020-09-07 um 1:00 a.m. schrieb Matt Coffin: > Hello all, > > > > Thought I'd chime in here. While I can't speak to the issue the GitLab > reporter was experiencing, I can say that I get some performance hit > (expected) from this when using multiple monitors with DRI_PRIME. When > the second

[PATCH AUTOSEL 4.19 24/26] drm/amdgpu: Fix bug in reporting voltage for CIK

From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine

[PATCH AUTOSEL 5.4 41/43] drm/amdgpu: Fix bug in reporting voltage for CIK

From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine

[PATCH AUTOSEL 5.8 50/53] drm/amdgpu: Fix bug in reporting voltage for CIK

From: Sandeep Raghuraman [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine

Re: [PATCH v2 03/11] drm/amd/display: Honor the offset for plane 0.

Hi [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has tested the following trees: v5.8.7, v5.4.63, v4.19.143, v4.14.196, v4.9.235, v4.4.235. v5.8.7: Build OK!

Power-saving/performance toggles for amdgpu

Hey, I'm currently working on a daemon that allows a UI that will eventually look like the power mode section in this mockup: https://gitlab.gnome.org/Teams/Design/settings-mockups/-/blob/master/power/power.png The daemon: https://gitlab.freedesktop.org/hadess/power-profiles-daemon The UI:

Re: [PATCH v4 1/1] drm: allow limiting the scatter list size.

On Mon, Sep 7, 2020 at 1:24 PM Gerd Hoffmann wrote: > > Add drm_device argument to drm_prime_pages_to_sg(), so we can > call dma_max_mapping_size() to figure the segment size limit > and call into __sg_alloc_table_from_pages() with the correct > limit. > > This fixes virtio-gpu with sev.

[PATCH v4 1/1] drm: allow limiting the scatter list size.

Add drm_device argument to drm_prime_pages_to_sg(), so we can call dma_max_mapping_size() to figure the segment size limit and call into __sg_alloc_table_from_pages() with the correct limit. This fixes virtio-gpu with sev. Possibly it'll fix other bugs too given that drm seems to totaly ignore

Re: [PATCH v2 04/11] drm/fourcc: Add AMD DRM modifiers.

Thanks, fixed both locally. On Mon, Sep 7, 2020 at 10:44 AM Pierre-Eric Pelloux-Prayer wrote: > > Hi Bas, > > 2 small typos you may want to fix: > > On 04/09/2020 18:07, Bas Nieuwenhuizen wrote: > > This adds modifiers for GFX9+ AMD GPUs. > > > > As the modifiers need a lot of parameters I split

Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.

On Mon, Sep 7, 2020 at 10:51 AM Ernst Sjöstrand wrote: > > > > Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen > : >> >> This adds modifier support to radeonsi. > > > Wouldn't it be more correct to say that this adds modifier support to amdgpu > (and enables it to work with radeonsi

RE: [PATCH] SWDEV-220451 - Query guest's information by VF2PF message - part 2

[AMD Official Use Only - Internal Distribution Only] Please split the patches to 3~4 patches and each with only one purpose Please follow the open source kernel rules when you prepare a patch: don't squash two (or more) things together Thanks _ Monk Liu|GPU

[PATCH 4/4] drm/amd/pm: add Raven2 watermak WmType setting

Which tells it's a nomral pstate change or memory retraining. Change-Id: If55d6c3f1dfc28005c6d767154664feddcda6f5b Signed-off-by: Evan Quan Tested-by: Changfeng Zhu --- drivers/gpu/drm/amd/pm/inc/smu10_driver_if.h | 3 ++- drivers/gpu/drm/amd/pm/powerplay/hwmgr/smu10_hwmgr.c | 11

[PATCH 3/4] drm/amd/pm: add Renoir watermak WmType setting

Which tells it's a nomral pstate change or memory retraining. Change-Id: I8619115486021537b52c067c4d0b9bfc1417fc35 Signed-off-by: Evan Quan Tested-by: Changfeng Zhu --- drivers/gpu/drm/amd/pm/swsmu/smu12/renoir_ppt.c | 4 1 file changed, 4 insertions(+) diff --git

[PATCH 1/4] drm/amd/pm: drop dead code

Raven never goes to swsmu path. So "adev->smu.ppt_funcs" will be always false. Change-Id: Ia55ad97bcf9ecf135a9bd795f36a5b521d718b20 Signed-off-by: Evan Quan Tested-by: Changfeng Zhu --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH 2/4] drm/amd/pm: drop unnecessary wrappers around watermark setting

The convertion to "struct dm_pp_clock_range_for_mcif_wm_set_soc15" is totally unnecessary and can be dropped. Change-Id: Ieaa1d1f1cc12b29a8ec26d330fd209662940417d Signed-off-by: Evan Quan Tested-by: Changfeng Zhu --- .../amd/display/amdgpu_dm/amdgpu_dm_pp_smu.c | 97 +--

Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.

Den fre 4 sep. 2020 kl 18:07 skrev Bas Nieuwenhuizen < b...@basnieuwenhuizen.nl>: > This adds modifier support to radeonsi. > Wouldn't it be more correct to say that this adds modifier support to amdgpu (and enables it to work with radeonsi OpenGL) or something like that? //E > It has been

Re: [PATCH v2 04/11] drm/fourcc: Add AMD DRM modifiers.

Hi Bas, 2 small typos you may want to fix: On 04/09/2020 18:07, Bas Nieuwenhuizen wrote: > This adds modifiers for GFX9+ AMD GPUs. > > As the modifiers need a lot of parameters I split things out in > getters and setters. > - Advantage: simplifies the code a lot > - Disadvantage: Makes it

Re: [PATCH v2 00/11] amd/display: Add GFX9+ modifier support.

On Fri, Sep 04, 2020 at 06:06:58PM +0200, Bas Nieuwenhuizen wrote: > This adds modifier support to radeonsi. > It has been tested on > > - VEGA10, RAVEN, NAVI14 > - weston, sway, X with xf86-video-amdgpu (i.e. legacy path still works) > > and includes some basic testing of the layout code. > >

Re: [PATCH] radeon: Use only a single work queue thread for crt

Am 06.09.20 um 18:02 schrieb Jan Vesely: On Sun, Sep 6, 2020 at 4:54 AM Christian König > wrote: Am 03.08.19 um 02:09 schrieb Andi Kleen: > From: Andi Kleen mailto:a...@linux.intel.com>> > > I got tired of seeing a lot of radeon-crt

Re: [PATCH] radeon: Use only a single work queue thread for crt

Am 07.09.20 um 01:47 schrieb Dave Airlie: On Sun, 6 Sep 2020 at 18:54, Christian König wrote: Am 03.08.19 um 02:09 schrieb Andi Kleen: From: Andi Kleen I got tired of seeing a lot of radeon-crt kernel threads in ps on my workstation, one for each CPU and one for each display, which never

Re: [PATCH 1/1] drm/amdgpu: Convert to using devm_drm_dev_alloc()

On Mon, Sep 07, 2020 at 10:06:08AM +0200, Daniel Vetter wrote: > On Sat, Sep 05, 2020 at 11:50:05AM -0400, Alex Deucher wrote: > > On Thu, Sep 3, 2020 at 9:22 PM Luben Tuikov wrote: > > > > > > Convert to using devm_drm_dev_alloc(), > > > as drm_dev_init() is going away. > > > > > >

Re: [PATCH 1/1] drm/amdgpu: Convert to using devm_drm_dev_alloc()

On Sat, Sep 05, 2020 at 11:50:05AM -0400, Alex Deucher wrote: > On Thu, Sep 3, 2020 at 9:22 PM Luben Tuikov wrote: > > > > Convert to using devm_drm_dev_alloc(), > > as drm_dev_init() is going away. > > > > Signed-off-by: Luben Tuikov > > I think we can drop the final drm_put in the error case?

Re: [PATCH v2] drm/amdgpu/dc: Require primary plane to be enabled whenever the CRTC is

On Fri, Sep 04, 2020 at 12:43:04PM +0200, Michel Dänzer wrote: > From: Michel Dänzer > > Don't check drm_crtc_state::active for this either, per its > documentation in include/drm/drm_crtc.h: > > * Hence drivers must not consult @active in their various > * _mode_config_funcs.atomic_check

Re: [PATCH v3 6/7] drm: Validate encoder->possible_crtcs

On Sun, Sep 6, 2020 at 1:19 PM Jan Kiszka wrote: > > On 11.02.20 18:04, Daniel Vetter wrote: > > On Tue, Feb 11, 2020 at 06:22:07PM +0200, Ville Syrjala wrote: > >> From: Ville Syrjälä > >> > >> WARN if the encoder possible_crtcs is effectively empty or contains > >> bits for non-existing crtcs.

Re: [PATCH v2 1/2] drm: allow limiting the scatter list size.

On Mon, Sep 7, 2020 at 8:39 AM Gerd Hoffmann wrote: > > > > + /** > > > +* @max_segment: > > > +* > > > +* Max size for scatter list segments. When unset the default > > > +* (SCATTERLIST_MAX_SEGMENT) is used. > > > +*/ > > > + size_t max_segment; > > > > Is there no

Re: [PATCH v2 1/2] drm: allow limiting the scatter list size.

> > + /** > > +* @max_segment: > > +* > > +* Max size for scatter list segments. When unset the default > > +* (SCATTERLIST_MAX_SEGMENT) is used. > > +*/ > > + size_t max_segment; > > Is there no better place for this then "at the bottom"? drm_device is a > huge

[PATCH v3 1/2] drm: allow limiting the scatter list size.

Add max_segment argument to drm_prime_pages_to_sg(). When set pass it through to the __sg_alloc_table_from_pages() call, otherwise use SCATTERLIST_MAX_SEGMENT. Also add max_segment field to drm driver and pass it to drm_prime_pages_to_sg() calls in drivers and helpers. v2: place max_segment in