[Public]
> -Original Message-
> From: Michel Dänzer
> Sent: Thursday, September 16, 2021 4:12 PM
> To: Christian König ; Quan, Evan
>
> Cc: Deucher, Alexander ; Koenig, Christian
> ; 'amd-gfx@lists.freedesktop.org' g...@lists.freedesktop.org>
> Subject: Re: DRM IOCTLS come
From: Philip Yang
[ Upstream commit d7eff46c214c036606dd3cd305bd5a128aecfe8c ]
Get process vm root BO ref in case process is exiting and root BO is
freed, to avoid NULL pointer dereference backtrace:
BUG: unable to handle kernel NULL pointer dereference at
Call Trace:
From: Anson Jacob
[ Upstream commit 03388a347fe7cf7c3bdf68b0823ba316d177d470 ]
Free memory allocated if any of the previous allocations failed.
>>> CID 1487129: Resource leaks (RESOURCE_LEAK)
>>> Variable "vpg" going out of scope leaks the storage it points to.
From: Luben Tuikov
[ Upstream commit a6a355a22f7a0efa6a11bc90b5161f394d51fe95 ]
1) Generalize the function--if the user didn't set
i2c_address, still return true/false to
indicate whether VBIOS contains the RAS EEPROM
address. This function shouldn't evaluate
whether the user set
For xnack off, restore work dma unmap previous system memory page, and
dma map the updated system memory page to update GPU mapping, this is
not dma mapping leaking, remove the WARN_ONCE for dma mapping leaking.
prange->dma_addr store the VRAM page pfn after the range migrated to
VRAM, should not
Before adding the PTE flags, explicitly mask out invalid address bits.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index
On 2021-09-16 5:11 p.m., Philip Yang wrote:
SVM range may includes multiple VMAs with different vm_flags, if prange
page index is the last page of the VMA offset + npages, update GPU
mapping to create GPU page table with same VMA access permission.
Signed-off-by: Philip Yang
---
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +++--
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_client_modeset.c | 5 +++--
drivers/gpu/drm/drm_crtc_helper.c| 18
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 12
1 file changed, 8 insertions(+), 4
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/gma500/psb_device.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/radeon/radeon_device.c | 13 +
drivers/gpu/drm/radeon/radeon_dp_mst.c | 7
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/omapdrm/omap_fb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
Hi all,
One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to
"use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this
patch series is about.
You will find two types of changes here:
- Replacing "drm_modeset_lock_all_ctx()" (and surrounding
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/i915/display/intel_display.c | 17 -
1 file changed,
The previous commits do exactly what this entry in the TODO file asks
for, thus we can remove it now as it is no longer applicable.
Signed-off-by: Fernando Ramos
---
Documentation/gpu/todo.rst| 17 -
Documentation/locking/ww-mutex-design.rst | 2 +-
2 files
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/tegra/dsi.c | 6 --
drivers/gpu/drm/tegra/hdmi.c | 5 +++--
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 +++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/drm_client_modeset.c | 9 +++--
1 file changed, 3 insertions(+),
As requested in Documentation/gpu/todo.rst, replace the boilerplate code
surrounding drm_modeset_lock_all_ctx() with DRM_MODESET_LOCK_ALL_BEGIN()
and DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 10 --
1 file changed, 4
As requested in Documentation/gpu/todo.rst, replace driver calls to
drm_modeset_lock_all() with DRM_MODESET_LOCK_ALL_BEGIN() and
DRM_MODESET_LOCK_ALL_END()
Signed-off-by: Fernando Ramos
---
drivers/gpu/drm/i915/display/intel_audio.c| 12 +++--
drivers/gpu/drm/i915/display/intel_display.c |
SVM range may includes multiple VMAs with different vm_flags, if prange
page index is the last page of the VMA offset + npages, update GPU
mapping to create GPU page table with same VMA access permission.
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 7 ++-
1 file
On 2021-09-13 4:11 p.m., Philip Yang wrote:
SVM range may includes multiple VMAs with different vm_flags, if prange
page index is the last page of the VMA offset + npages, update GPU
mapping to create GPU page table with same VMA access permission.
Signed-off-by: Philip Yang
---
For xnack off, restore work dma unmap previous system memory page, and
dma map the updated system memory page to update GPU mapping, this is
not dma mapping leaking, remove the WARN_ONCE for dma mapping leaking.
prange->dma_addr store the VRAM page pfn after the range migrated to
VRAM, should not
On Thu, Sep 16, 2021 at 2:48 PM Davut Demir wrote:
>
> Eyl 16 18:49:02 davut-laptop kernel: amdgpu :01:00.0: PCIE GART of 256M
> enabled (table at 0x00F4).
> Eyl 16 18:49:26 davut-laptop kernel: [drm:amdgpu_job_timedout [amdgpu]]
> *ERROR* ring gfx timeout, signaled seq=527,
On 9/16/21 8:02 AM, Borislav Petkov wrote:
On Wed, Sep 15, 2021 at 10:26:06AM -0700, Kuppuswamy, Sathyanarayanan wrote:
I have a Intel variant patch (please check following patch). But it includes
TDX changes as well. Shall I move TDX changes to different patch and just
create a separate
Eyl 16 18:49:02 davut-laptop kernel: amdgpu :01:00.0: PCIE GART of 256M
enabled (table at 0x00F4).
Eyl 16 18:49:26 davut-laptop kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR*
ring gfx timeout, signaled seq=527, emitted seq=528
[Public]
Ah.. didn't notice that. As I mentioned, it's mainly a cosmetic/semantic thing.
AFAIU, hw_fini() is expected to be called once when hw is removed/reset or
driver is removed. Suspend is temporary and may be called multiple times during
the lifetime. So calling hw_fini() from suspend()
On 2021-09-16 11:51 a.m., Lazar, Lijo wrote:
On 9/16/2021 9:15 PM, Andrey Grodzovsky wrote:
On 2021-09-16 4:20 a.m., Lazar, Lijo wrote:
A minor comment below.
On 9/16/2021 1:11 AM, Andrey Grodzovsky wrote:
Crash:
BUG: unable to handle page fault for address: 10e1
RIP:
On 9/16/2021 9:15 PM, Andrey Grodzovsky wrote:
On 2021-09-16 4:20 a.m., Lazar, Lijo wrote:
A minor comment below.
On 9/16/2021 1:11 AM, Andrey Grodzovsky wrote:
Crash:
BUG: unable to handle page fault for address: 10e1
RIP: 0010:vega10_power_gate_vce+0x26/0x50 [amdgpu]
Call
On Wed, Sep 15, 2021 at 10:26:06AM -0700, Kuppuswamy, Sathyanarayanan wrote:
> I have a Intel variant patch (please check following patch). But it includes
> TDX changes as well. Shall I move TDX changes to different patch and just
> create a separate patch for adding intel_cc_platform_has()?
On 2021-09-16 4:20 a.m., Lazar, Lijo wrote:
A minor comment below.
On 9/16/2021 1:11 AM, Andrey Grodzovsky wrote:
Crash:
BUG: unable to handle page fault for address: 10e1
RIP: 0010:vega10_power_gate_vce+0x26/0x50 [amdgpu]
Call Trace:
pp_set_powergating_by_smu+0x16a/0x2b0
On 2021-09-14 17:05, Harry Wentland wrote:
[Why & How]
With Werror enabled in the kernel we were failing the clang build since
dml21_ModeSupportAndSystemConfigurationFull's stack frame is 1064 when
building with clang, and exceeding the default 1024 stack frame limit.
The culprit seems to be
Hi Dave, Daniel,
Fixes for 5.15.
The following changes since commit 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f:
Linux 5.15-rc1 (2021-09-12 16:28:37 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.15-2021-09-16
for you to
On Thu, Sep 16, 2021 at 3:44 PM Oded Gabbay wrote:
>
> On Thu, Sep 16, 2021 at 3:31 PM Daniel Vetter wrote:
> >
> > Maybe I got the device security model all wrong, but I thought Guadi is
> > single user, and the only thing it protects is the system against the
> > Gaudi device trhough
On Thu, Sep 16, 2021 at 02:31:34PM +0200, Daniel Vetter wrote:
> On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote:
> > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
> > >
> > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> > > > On Sun, Sep 12, 2021 at
Christoph Hellwig writes:
> On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
>> Could you please provide more explicit explanation why inlining such an
>> helper is considered as bad practice and messy ?
>
> Because now we get architectures to all subly differ. Look at the mess
On Wed, Sep 15, 2021 at 07:18:34PM +0200, Christophe Leroy wrote:
> Could you please provide more explicit explanation why inlining such an
> helper is considered as bad practice and messy ?
Because now we get architectures to all subly differ. Look at the mess
for ioremap and the ioremap*
On Thu, Sep 16, 2021 at 3:31 PM Daniel Vetter wrote:
>
> On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote:
> > On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
> > >
> > > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> > > > On Sun, Sep 12, 2021 at 07:53:07PM
On Wed, Sep 15, 2021 at 10:45:36AM +0300, Oded Gabbay wrote:
> On Tue, Sep 14, 2021 at 7:12 PM Jason Gunthorpe wrote:
> >
> > On Tue, Sep 14, 2021 at 04:18:31PM +0200, Daniel Vetter wrote:
> > > On Sun, Sep 12, 2021 at 07:53:07PM +0300, Oded Gabbay wrote:
> > > > Hi,
> > > > Re-sending this
On Wed, Sep 15, 2021 at 12:05:30PM +0200, Christian König wrote:
> Am 14.09.21 um 15:50 schrieb Daniel Vetter:
> > On Thu, Sep 09, 2021 at 09:10:39AM +0200, Christian König wrote:
> > > Am 08.09.21 um 20:27 schrieb Daniel Vetter:
> > > > On Tue, Sep 07, 2021 at 11:28:23AM +0200, Christian König
On Tue, 3 Aug 2021 11:38:19 +0200
Werner Sembach wrote:
> Greetings,
>
> Original proposal:
> https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html
>
> Abstract: Add "preferred color format", "active color format", "active bpc",
> and "active Broadcast RGB" drm properties,
A minor comment below.
On 9/16/2021 1:11 AM, Andrey Grodzovsky wrote:
Crash:
BUG: unable to handle page fault for address: 10e1
RIP: 0010:vega10_power_gate_vce+0x26/0x50 [amdgpu]
Call Trace:
pp_set_powergating_by_smu+0x16a/0x2b0 [amdgpu]
amdgpu_dpm_set_powergating_by_smu+0x92/0xf0
On 2021-09-16 08:27, Christian König wrote:
> Good morning,
>
> for the background I advised to contact you Michel since we couldn't find an
> explanation.
>
> Alex explanation might be correct, but the CS seems to come from the X server
> and is always roughly 60 seconds after going into
[AMD Official Use Only]
Reviewed-by: xinhui pan
-Original Message-
From: amd-gfx On Behalf Of Andrey
Grodzovsky
Sent: 2021年9月16日 3:42
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan ; Pan, Xinhui ; Deucher,
Alexander ; Grodzovsky, Andrey
Subject: [PATCH] drm/amdgpu: Fix crash on
Am 16.09.21 um 08:19 schrieb xinhui pan:
Now we use same BO for create/destroy msg. So destroy will wait for the
fence returned from create to be signaled. The default timeout value in
destroy is 10ms which is too short.
Lets wait both fences with the specific timeout.
Signed-off-by: xinhui
Good morning,
for the background I advised to contact you Michel since we couldn't
find an explanation.
Alex explanation might be correct, but the CS seems to come from the X
server and is always roughly 60 seconds after going into power save.
Any idea what that could be?
Thanks,
Now we use same BO for create/destroy msg. So destroy will wait for the
fence returned from create to be signaled. The default timeout value in
destroy is 10ms which is too short.
Lets wait both fences with the specific timeout.
Signed-off-by: xinhui pan
---
50 matches
Mail list logo
