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
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:
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
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
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
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 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 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 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 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 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 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 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: 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: 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: 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: 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: 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 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: "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: 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
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/
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
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
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
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
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
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 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:
>
> [
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
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 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/
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
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
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:
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
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 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 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 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
https://bugzilla.kernel.org/show_bug.cgi?id=211161
Benji Wiebe (benjiwieb...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
R
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
> 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
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 1/19/21 2:04 PM, 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 Grodzovsky wrote:
static struct pci_driver amdgpu
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 Grodzovsky wrote:
> > > > static struct pci_driver amdgpu_kms_pci_driver = {
> >
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/?url=https%3A%2F%2Flwn.net%2FArticles%2F76788
On Tue, Jan 19, 2021 at 5:08 PM Pillai, Aurabindo
wrote:
>
> [AMD Official Use Only - Internal Distribution Only]
>
>
> Hi Daniel,
>
> Could you please be more specific about the _unsafe API options you mentioned
> ?
module_param_named_unsafe()
Cheers, Daniel
>
> --
>
> Thanks & Regards,
> Aur
Am 19.01.21 um 18:47 schrieb Luben Tuikov:
On 2021-01-19 2:53 a.m., Christian König wrote:
Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
From: Luben Tuikov
This patch does not change current behaviour.
The driver's job timeout handler now returns
status indicating back to the DRM layer whe
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 Grodzovsky wrote:
> > > static struct pci_driver amdgpu_kms_pci_driver = {
> > > .name = DRIVER_NAME,
> > > .id_table
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/?url=https%3A%2F%2Flwn.net%2FArticles%2F767885%2F&data=04%7C01%7CAndrey.Grodzovsky%40amd.com%7
On 1/19/21 1:08 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky
wrote:
On 1/19/21 9:16 AM, Daniel Vetter wrote:
On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbol
On Tue, Jan 19, 2021 at 6:31 PM Andrey Grodzovsky
wrote:
>
>
> On 1/19/21 9:16 AM, Daniel Vetter wrote:
> > On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
> >> Until now extracting a card either by physical extraction (e.g. eGPU with
> >> thunderbolt connection or by emulation
On Tue, Jan 19, 2021 at 4:35 PM Andrey Grodzovsky
wrote:
>
> There is really no other way according to this article
> https://lwn.net/Articles/767885/
>
> "A perfect solution seems nearly impossible though; we cannot acquire a mutex
> on
> the user
> to prevent them from yanking a device and we c
On Tue, Jan 19, 2021 at 6:47 PM Fabio Estevam wrote:
>
> Calling the drm_atomic_helper_shutdown() on 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/0x
On Tue, Jan 19, 2021 at 6:36 PM Fabio Estevam wrote:
>
> Hi Rob,
>
> On Tue, Jan 19, 2021 at 1:40 PM Rob Clark wrote:
>
> > > I suppose we should do the drm_atomic_helper_shutdown() conditionally?
>
> This suggestion works, thanks. I will submit a patch shortly.
I think the cleanest way to do th
On 2021-01-19 2:53 a.m., Christian König wrote:
> Am 18.01.21 um 22:01 schrieb Andrey Grodzovsky:
>> From: Luben Tuikov
>>
>> This patch does not change current behaviour.
>>
>> The driver's job timeout handler now returns
>> status indicating back to the DRM layer whether
>> the task (job) was su
Calling the drm_atomic_helper_shutdown() on 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
Hi Rob,
On Tue, Jan 19, 2021 at 1:40 PM Rob Clark wrote:
> > I suppose we should do the drm_atomic_helper_shutdown() conditionally?
This suggestion works, thanks. I will submit a patch shortly.
Thanks
___
dri-devel mailing list
dri-devel@lists.freede
On 1/19/21 9:16 AM, Daniel Vetter wrote:
On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
Until now extracting a card either by physical extraction (e.g. eGPU with
thunderbolt connection or by emulation through syfs ->
/sys/bus/pci/devices/device_id/remove)
would cause rando
On Mon, Jan 18, 2021 at 1:39 PM Will Deacon wrote:
>
> On Mon, Jan 18, 2021 at 01:16:03PM -0800, Rob Clark wrote:
> > On Mon, Dec 21, 2020 at 4:44 PM Isaac J. Manjarres
> > wrote:
> > >
> > > The MSM DRM driver depends on the availability of the ARM LPAE io-pgtable
> > > format code to work prope
forgot to CC Krishna
On Tue, Jan 19, 2021 at 8:34 AM Rob Clark wrote:
>
> On Mon, Jan 18, 2021 at 11:00 PM Daniel Vetter wrote:
> >
> > On Mon, Jan 18, 2021 at 11:00 PM Fabio Estevam wrote:
> > >
> > > On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote:
> > > >
> > > > Adding some more folks
On 1/19/21 2:34 AM, Greg KH wrote:
On Mon, Jan 18, 2021 at 04:01:19PM -0500, Andrey Grodzovsky wrote:
static struct pci_driver amdgpu_kms_pci_driver = {
.name = DRIVER_NAME,
.id_table = pciidlist,
@@ -1595,6 +1607,7 @@ static struct pci_driver amdgpu_kms_pci_driver = {
On Mon, Jan 18, 2021 at 11:00 PM Daniel Vetter wrote:
>
> On Mon, Jan 18, 2021 at 11:00 PM Fabio Estevam wrote:
> >
> > On Mon, Jan 18, 2021 at 6:44 PM Fabio Estevam wrote:
> > >
> > > Adding some more folks in case anyone has any suggestions to fix this
> > > reboot hang.
> >
> > Not sure if th
Hi Phillip,
On Tue, Jan 19, 2021 at 11:08 AM Philipp Zabel wrote:
>
> Only planes that are displayed via the Display Processor (DP) path
> support color space conversion. Limit formats on planes that are
> shown via the direct Display Controller (DC) path to RGB.
>
> Reported-by: Fabio Estevam
>
[AMD Official Use Only - Internal Distribution Only]
Hi Daniel,
Could you please be more specific about the _unsafe API options you mentioned ?
--
Thanks & Regards,
Aurabindo Pillai
From: Daniel Vetter
Sent: Tuesday, January 19, 2021 8:11 AM
To: Pekka Paalanen
On Tue, Jan 19, 2021 at 4:20 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 27, 2020 at
On Tue, Jan 19, 2021 at 02:05:09PM +0100, Daniel Vetter wrote:
> > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> > index b9e9adec73e8..6eb117c0d0f3 100644
> > --- a/include/linux/lockdep.h
> > +++ b/include/linux/lockdep.h
> > @@ -310,6 +310,10 @@ extern void lock_unpin_lock(str
Gah, yes, good catch.
Reviewed-by: James Jones
On 1/18/21 5:54 PM, Lyude Paul wrote:
Nvidia hardware doesn't actually support using tiling formats with the
cursor plane, only linear is allowed. In the future, we should write a
testcase for this.
Fixes: c586f30bf74c ("drm/nouveau/kms: Add form
[Why]
While possible for userspace to create and add custom mode based off the
optimized mode for the connected display which differs only in front porch
timing, this patch set adds a list of common video modes in advance.
The list of common video refresh rates is small, well known and the optimiz
[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display with a
variable vtotal min/max.
Smooth video playback usecases can be enabled with this seamless transition by
switching to a new mode which has a r
On Mon, Jan 18, 2021 at 08:54:12PM -0500, Lyude Paul wrote:
> Nvidia hardware doesn't actually support using tiling formats with the
> cursor plane, only linear is allowed. In the future, we should write a
> testcase for this.
There are a couple of old modifier/format sanity tests here:
https://pa
[Why]
This option shall be opt-in by default since it is a temporary solution
until long term solution is agreed upon which may require userspace interface
changes. There has been precedent of manufacturing modes in the kernel. In
AMDGPU, the existing usage are for common modes and scaling modes. O
Changes in V5
=
* More info in commit messages on the rationale of changes being added
to the kernel.
* Minor fixes
Changes in V4
=
1) Add module parameter for freesync video mode
* Change module parameter name to freesync_video
2) Add freesync video modes based on pref
The is also the possibility to have the drm_dev_enter/exit much more
high level.
E.g. we should it have anyway on every IOCTL and what remains are work
items, scheduler threads and interrupts.
Christian.
Am 19.01.21 um 16:35 schrieb Andrey Grodzovsky:
There is really no other way according t
There is really no other way according to this article
https://lwn.net/Articles/767885/
"A perfect solution seems nearly impossible though; we cannot acquire a mutex on
the user
to prevent them from yanking a device and we cannot check for a presence change
after every
device access for perfo
On Tue, Jan 19, 2021 at 03:34:47PM +0100, Daniel Vetter wrote:
> On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
> wrote:
> >
> > On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > > wrote:
> > > >
> > > > Since 3234ac664a87
FYI patches 1 and 5 are now in drm-misc-next.
Am 18.01.21 um 14:14 schrieb Thomas Zimmermann:
I merged more patches into drm-misc-next. I'm mostly sending out v4 of
this patchset to split the final patch into the core changes and the
patch for moving pdev behind CONFIG_DRM_LEGACY. The former are
On Tue, Jan 19, 2021 at 3:32 PM Greg Kroah-Hartman
wrote:
>
> On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter
> > wrote:
> > >
> > > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > > the region") /dev/kmem z
On Tue, Jan 19, 2021 at 09:17:55AM +0100, Daniel Vetter wrote:
> On Fri, Nov 27, 2020 at 5:42 PM Daniel Vetter wrote:
> >
> > Since 3234ac664a87 ("/dev/mem: Revoke mappings when a driver claims
> > the region") /dev/kmem zaps ptes when the kernel requests exclusive
> > acccess to an iomem region.
On Mon, Jan 18, 2021 at 04:01:09PM -0500, Andrey Grodzovsky wrote:
> Until now extracting a card either by physical extraction (e.g. eGPU with
> thunderbolt connection or by emulation through syfs ->
> /sys/bus/pci/devices/device_id/remove)
> would cause random crashes in user apps. The random
On Tue, Jan 19, 2021 at 01:18:21PM +0100, Christian König wrote:
> Only initialize the DMA coherent pools if they are used.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 23 ---
> 1 file changed, 16 insertions(+), 7
Only planes that are displayed via the Display Processor (DP) path
support color space conversion. Limit formats on planes that are
shown via the direct Display Controller (DC) path to RGB.
Reported-by: Fabio Estevam
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/ipuv3-plane.c | 41 ++
On Tue, Jan 19, 2021 at 01:18:20PM +0100, Christian König wrote:
> Useful for testing.
>
> v2: add fs_reclaim_acquire()/_release()
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 53 ++
> 1 file changed, 35 insertions(+), 18 deletions(
On Tue, Jan 19, 2021 at 01:18:19PM +0100, Christian König wrote:
> Instead of printing this on the per device pool.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
btw I think ttm should also set up the per-bdev debugfs stuff, feels silly
having that boilerplate. Same for the per
On Mon, Jan 18, 2021 at 04:01:10PM -0500, Andrey Grodzovsky wrote:
> On device removal reroute all CPU mappings to dummy page.
>
> v3:
> Remove loop to find DRM file and instead access it
> by vma->vm_file->private_data. Move dummy page installation
> into a separate function.
>
> v4:
> Map the e
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/amdgpu/amdgpu.h
On Tue, Jan 19, 2021 at 04:11:27AM -0800, Pan Bian wrote:
> Put the state before returning error code.
>
> Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.")
>
> Signed-off-by: Pan Bian
Nice catch, patch merged to drm-misc-fixes with cc: stable.
-Daniel
> ---
> drivers/gp
On Tue, Jan 19, 2021 at 01:11:36PM +0100, Christian König wrote:
> Am 07.01.21 um 17:38 schrieb Daniel Vetter:
> > On Thu, Jan 07, 2021 at 01:49:45PM +0100, Christian König wrote:
> > > Am 22.12.20 um 14:51 schrieb Daniel Vetter:
> > > > On Fri, Dec 18, 2020 at 06:55:38PM +0100, Christian König wro
1 - 100 of 155 matches
Mail list logo
