On 1/19/21 1:59 PM, Christian König wrote:
Am 19.01.21 um 19:22 schrieb Andrey Grodzovsky:
On 1/19/21 1:05 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
There is really no other way according to this article
https://nam11.safelinks.protection.outlook.com/
> On Jan 19, 2021, at 03:29, Lee Jones wrote:
>
> On Mon, 18 Jan 2021, Daniel Vetter wrote:
>
>> On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote:
>>> On Mon, 18 Jan 2021, Daniel Vetter wrote:
>>>
On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
>
>> On Jan
We were not correctly unpinning no longer needed buffers. In particular
vmw_buffer_object, which is internally often pinned on creation wasn't
unpinned on destruction and none of the internal MOB buffers were
unpinned before being put back. Technically this existed for a
long time but 57fcd550eb15b
https://bugzilla.kernel.org/show_bug.cgi?id=211161
Benji Wiebe (benjiwieb...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
R
On Tue, Jan 19, 2021 at 8:31 PM Zack Rusin wrote:
>
> We were not correctly unpinning no longer needed buffers. In particular
> vmw_buffer_object, which is internally often pinned on creation wasn't
> unpinned on destruction and none of the internal MOB buffers were
> unpinned before being put bac
On Tue, Jan 19, 2021 at 8:35 PM Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 8:31 PM Zack Rusin wrote:
> >
> > We were not correctly unpinning no longer needed buffers. In particular
> > vmw_buffer_object, which is internally often pinned on creation wasn't
> > unpinned on destruction and non
On Tue, Jan 19, 2021 at 02:04:48PM -0500, Alex Deucher wrote:
> On Tue, Jan 19, 2021 at 1:26 PM Greg KH wrote:
> >
> > On Tue, Jan 19, 2021 at 11:36:01AM -0500, Andrey Grodzovsky wrote:
> > >
> > > On 1/19/21 2:34 AM, Greg KH wrote:
> > > > On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovs
On Fri, Jan 15, 2021 at 4:31 PM Veera Sundaram Sankaran
wrote:
>
> Some drivers have hardware capability to get the precise HW timestamp
> of certain events based on which the fences are triggered. The delta
> between the event HW timestamp & current HW reference timestamp can
> be used to calcula
On Fri, Jan 15, 2021 at 4:31 PM Veera Sundaram Sankaran
wrote:
>
> The explicit out-fences in crtc are signaled as part of vblank event,
> indicating all framebuffers present on the Atomic Commit request are
> scanned out on the screen. Though the fence signal and the vblank event
> notification h
If we abort from the allocation due to a fatal_signal_pending(),
be sure we report an error so any return code paths don't trip
over the fact that the allocation didn't succeed.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc:
Every heap needs to create a dmabuf and then export it to a fd
via dma_buf_fd(), so to consolidate things a bit, have the heaps
just return a struct dmabuf * and let the top level
dma_heap_buffer_alloc() call handle creating the fd via
dma_buf_fd().
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbot
We shouldn't vunmap more then we vmap, but if we do, make
sure we complain loudly.
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Laura Abbott
Cc: Brian Starkey
Cc: Hridya Valsaraju
Cc: Suren Baghdasaryan
Cc: Sandeep Patil
Cc: Daniel Mentz
Cc: Chris Goldsworthy
Cc: Ørjan Eide
Cc: Robin Murphy
Cc: E
On 1/19/21 8:45 AM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/
Hi Daniel,
On Tue, Jan 19, 2021 at 3:01 PM Daniel Vetter wrote:
> Don't we need the same treatment for suspend/resume too? Also if you
Yes, you are right. I have just tested suspend/resume and the problem
is there too:
[ 69.708552] 8<--- cut here ---
[ 69.711970] Unable to handle kernel NU
On Tue, Jan 19, 2021 at 10:22 PM Andrey Grodzovsky
wrote:
>
>
> On 1/19/21 8:45 AM, Daniel Vetter wrote:
>
> On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
>
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
>
> Handle all DMA IOMMU gropup related dependencies before the
> group
On Tue, Jan 19, 2021 at 10:49 PM Fabio Estevam wrote:
>
> Hi Daniel,
>
> On Tue, Jan 19, 2021 at 3:01 PM Daniel Vetter wrote:
>
> > Don't we need the same treatment for suspend/resume too? Also if you
>
> Yes, you are right. I have just tested suspend/resume and the problem
> is there too:
>
> [
https://bugzilla.kernel.org/show_bug.cgi?id=210321
--- Comment #3 from Florian Evers (florian-ev...@gmx.de) ---
Hi,
new info: this "crash" can be reproduced very easily here on my system. It is
enough to switch the screen off and on again to find the dump in the dmesg log.
I did not test yet whet
On 1/15/21 2:21 AM, Chen, Xiaogang wrote:
On 1/14/2021 1:24 AM, Grodzovsky, Andrey wrote:
On 1/14/21 12:11 AM, Chen, Xiaogang wrote:
On 1/12/2021 10:54 PM, Grodzovsky, Andrey wrote:
On 1/4/21 1:01 AM, Xiaogang.Chen wrote:
From: Xiaogang Chen
amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT int
Issuing a 'reboot' command in i.MX5 leads to the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disabl
Issuing a 'reboot' command in i.MX5 leads to the following flow:
[ 24.557742] [] (msm_atomic_commit_tail) from []
(commit_tail+0xa4/0x1b0)
[ 24.566349] [] (commit_tail) from []
(drm_atomic_helper_commit+0x154/0x188)
[ 24.575193] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disabl
When putting iMX5 into suspend, the following flow is
observed:
[ 70.023427] [] (msm_atomic_commit_tail) from []
(commit_tail+0x9c/0x18c)
[ 70.031890] [] (commit_tail) from []
(drm_atomic_helper_commit+0x1a0/0x1d4)
[ 70.040627] [] (drm_atomic_helper_commit) from
[] (drm_atomic_helper_disable
Chun-Kuang Hu 於 2021年1月7日 週四 上午7:17寫道：
>
> mtk mutex is a driver used by DRM and MDP [1], so this series move
> mtk mutex driver from DRM folder to soc folder, so it could be used
> by DRM and MDP.
Applied [1/5] ~ [4/5] to mediatek-drm-next [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/g
Hi all,
After merging the drm-intel tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/gpu/drm/msm/dp/dp_ctrl.c: In function 'dp_ctrl_use_fixed_nvid':
drivers/gpu/drm/msm/dp/dp_ctrl.c:1425:16: error: implicit declaration of
function 'drm_dp_get_edid_quirks'; did yo
On Fri, 15 Jan 2021 at 03:43, Mikhail Gavrilov
wrote:
>
In rc4, the number of warnings has dropped dramatically.
No more errors "kasan slab-out-of-bounds" and no "DMA-API device
driver failed to check map error".
But still not fixed "sleeping function called from invalid context at
include/linux/
From: Victor Zhao
[ Upstream commit f14a5c34d143f6627f0be70c0de1d962f3a6ff1c ]
psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux,
according to psp, linux cmds are not correct.
v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD.
Signed-off-by: Victor Zhao
Reviewed-by: Emily.Deng
Signe
From: "Li, Roman"
[ Upstream commit 9d03bb102028b4a3f4a64d6069b219e2e1c1f306 ]
[Why]
The initial purpose of dcn10 pipe split is to support some high
bandwidth mode which requires dispclk greater than max dispclk. By
initial bring up power measurement data, it showed power consumption is
less wit
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed o
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
From: Wayne Lin
[ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ]
[Why]
Find out when we try to disable CRC calculation,
crc generation is still enabled. Main reason is
that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.
[How]
Add c
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/m
From: Ben Skeggs
[ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ]
Whatever it is that we were doing before doesn't work on Ampere.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++---
drivers/gpu/drm/nouveau/nv
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
From: Victor Zhao
[ Upstream commit f14a5c34d143f6627f0be70c0de1d962f3a6ff1c ]
psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux,
according to psp, linux cmds are not correct.
v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD.
Signed-off-by: Victor Zhao
Reviewed-by: Emily.Deng
Signe
From: Wayne Lin
[ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ]
[Why]
Find out when we try to disable CRC calculation,
crc generation is still enabled. Main reason is
that dc_stream_configure_crc() will never get
called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE.
[How]
Add c
From: Ben Skeggs
[ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ]
Whatever it is that we were doing before doesn't work on Ampere.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++---
drivers/gpu/drm/nouveau/nv
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed o
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/m
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed o
From: Ben Skeggs
[ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ]
Whatever it is that we were doing before doesn't work on Ampere.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++---
drivers/gpu/drm/nouveau/nv
From: Ben Skeggs
[ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ]
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/m
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
From: Ben Skeggs
[ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ]
VRAM offset 0 is a valid address, triggered on GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 ++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed o
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
From: Ben Skeggs
[ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ]
Whatever it is that we were doing before doesn't work on Ampere.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/ibus/gf100.c | 10 +++---
drivers/gpu/drm/nouveau/nv
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed o
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm200.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
From: Ben Skeggs
[ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ]
This issue has generally been covered up by the presence of additional
expansion ROMs after the ones we're interested in, with header fetches
of subsequent images loading enough of the ROM to hide the issue.
Noticed o
From: Ben Skeggs
[ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ]
Noticed while debugging GA102.
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/nvkm/subdev/i2c/auxgm204.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a
On 1/19/21 5:01 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 10:22 PM Andrey Grodzovsky
wrote:
On 1/19/21 8:45 AM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 09:48:03AM +0100, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related d
On 1/19/21 3:48 AM, Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
Handle all DMA IOMMU gropup related dependencies before the
group is removed.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 5
drivers/gpu/drm/amd/amdgpu/amd
Hi Dave, Daniel,
More new stuff for 5.12. Now with non-x86 fixed.
The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075:
drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 210921)
(2021-01-08 15:18:57 -0500)
are available in the Git repository at:
As commit d0e628cd817f ("kbuild: doc: clarify the difference between
extra-y and always-y") explained, extra-y should be used for listing
the prerequsites of vmlinux. always-y is a better fix here.
Signed-off-by: Masahiro Yamada
---
Documentation/devicetree/bindings/Makefile | 8
driv
101 - 155 of 155 matches
Mail list logo
