Hello! This is just a reminder that the CFP for XDC in 2022 is still open!
The 2022 X.Org Developers Conference is being held in conjunction with
the 2022 Wine Developers Conference. This is a meeting to bring
together developers working on all things open graphics (Linux kernel,
Mesa, DRM,
On Thu, Jun 02, 2022 at 12:45:47PM -0400, Alex Deucher wrote:
> Add comments to clarify code that is safe, but triggers and
> smatch warning.
>
> Link: https://lists.freedesktop.org/archives/amd-gfx/2022-June/079905.html
> Signed-off-by: Alex Deucher
> Cc: Dan Carpenter
> ---
Thanks!
Now that I'm finishing up my work to remove the legacy MST code from the
tree, I've come across a couple of various issues that I wrote up
patches for along the way. These are some of those patches for amdgpu.
Lyude Paul (3):
drm/amdgpu/dm/mst: Stop grabbing mst_mgr->lock in
This lock is only needed if you're iterating through the in-memory topology
(e.g. drm_dp_mst_branch->ports, drm_dp_mst_port->mstb, etc.). This doesn't
actually seem to be what's going on here though, so we can just drop this
lock.
Signed-off-by: Lyude Paul
---
A lot of code in amdgpu seems to sprinkle in
if (foo != NULL)
…
Checks pretty much all over the place, many times in locations where it's
clear foo (whatever foo may be) should never be NULL unless we've run into
a programming error. This is definitely one of those places, as
Noticed this while trying to update amdgpu for the non-atomic MST removal
changes - for some reason we appear to grab mst_mgr->lock before computing
mst DSC configs. This is wrong though - mst_mgr->lock is only needed while
traversing the actual MST topology state - which is not typically
Patches 1, 2, and 4 are
Reviewed-by: Harry Wentland
Harry
On 2022-06-02 14:03, sunpeng...@amd.com wrote:
> From: Leo Li
>
> The first two patches here add PSR SU Rate Control support to DC. Support in
> amdgpu_dm is still pending to enable this fully.
>
> The last two patches are some fixes
On 2022-06-02 14:03, sunpeng...@amd.com wrote:
> From: David Zhang
>
> [why]
> DMUB FW uses OTG instance to get eDP panel instance. But in case
> of MPO multiple pipe indexes are passed to updated the same panel.
> The other OTG instance passed would be ignored causing in DMUB not
>
From: Robin Chen
[Why]
To wrap the decision logic of sending dirty rect dmub command
for both frame update and cursor update path.
Signed-off-by: Robin Chen
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 ++-
.../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 24
From: David Zhang
[Why]
PSR-SU Rate Control - or PSR-SU-RC - enables PSR-SU panels to work with
variable refresh rate to allow for more power savings. Lowering the
refresh rate can increase PSR residency by expanding the eDP main link
shut down duration. It can also lower panel power
From: David Zhang
[why]
DMUB FW uses OTG instance to get eDP panel instance. But in case
of MPO multiple pipe indexes are passed to updated the same panel.
The other OTG instance passed would be ignored causing in DMUB not
acknowledging the messages.
[how]
Add panel instance to dirty rectangle
From: Leo Li
The first two patches here add PSR SU Rate Control support to DC. Support in
amdgpu_dm is still pending to enable this fully.
The last two patches are some fixes for PSR SU.
David Zhang (3):
drm/amd/display: expose AMD specific DPCD for PSR-SU-RC support
drm/amd/display: Add
From: David Zhang
[why & how]
Expose vendor specific DPCD registers for rate controlling the eDP sink
TCON's refresh rate during PSR active. When used in combination with
PSR-SU and Freesync, it is called PSR-SU Rate Contorol, or PSR-SU-RC for
short.
v2: Add all DPCD registers required
Am 2022-06-02 um 09:20 schrieb Philip Yang:
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but avoids unnecessary TLB flushes when new PDBs or PTBs are added to
the page table, which commonly happens when memory is mapped for the
first time.
Suggested-by: Christian König
The Null pointer against drm-next:
Jun 02 19:59:50 axion.fireburn.co.uk kernel: BUG: kernel NULL pointer
dereference, address: 00d8
Jun 02 19:59:50 axion.fireburn.co.uk kernel: #PF: supervisor read
access in kernel mode
Jun 02 19:59:50 axion.fireburn.co.uk kernel: #PF:
That's because drm-misc-next is currently broken and needs a backmerge.
Please try this patch on top of drm-next.
Regards,
Christian.
Am 02.06.22 um 20:08 schrieb Mike Lothian:
Hi
I'm still seeing Null pointers against Linus's tree and drm-misc with this patch
Jun 02 19:04:05
Am 02.06.22 um 16:21 schrieb Felix Kuehling:
[SNIP]
In other words the free is not waiting for the unmap to complete,
but causes command submissions through the kernel to depend on
the unmap.
I guess I don't understand that dependency. The next command
submission obviously cannot use the
Here's the output from drm-misc too:
Jun 02 19:05:32 axion.fireburn.co.uk kernel: BUG: kernel NULL pointer
dereference, address: 00d8
Jun 02 19:05:32 axion.fireburn.co.uk kernel: #PF: supervisor read
access in kernel mode
Jun 02 19:05:32 axion.fireburn.co.uk kernel: #PF:
Hi
I'm still seeing Null pointers against Linus's tree and drm-misc with this patch
Jun 02 19:04:05 axion.fireburn.co.uk kernel: BUG: kernel NULL pointer
dereference, address: 0008
Jun 02 19:04:05 axion.fireburn.co.uk kernel: #PF: supervisor write
access in kernel mode
Jun 02
I totally agree on the reasoning, but I have the strong feeling that
this will blow up in our face once more.
I've tried to raise this limit twice already and had to revert it both
times. And the reasons why I had to revert it haven't changed since them.
Christian.
Am 02.06.22 um 18:40
On Thu, Jun 2, 2022 at 12:12 PM Luben Tuikov wrote:
>
> From: Christian König
>
> Technically all of those can use GTT as well, no need to force things
> into VRAM.
>
> Signed-off-by: Christian König
> Acked-by: Luben Tuikov
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 7 +--
>
On Thu, Jun 2, 2022 at 11:47 AM Christian König
wrote:
>
> The resource must be on the LRU before ttm_lru_bulk_move_add() is called.
>
> Signed-off-by: Christian König
This should at least fix the null pointer in these bugs:
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1992
Bug:
Add comments to clarify code that is safe, but triggers and
smatch warning.
Link: https://lists.freedesktop.org/archives/amd-gfx/2022-June/079905.html
Signed-off-by: Alex Deucher
Cc: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 8
1 file changed, 8 insertions(+)
@Christian Koenig
Any objections to this? I realize that fixing the OOM killer is
ultimately the right approach, but I don't really see how this makes
things worse. The current scheme is biased towards dGPUs as they have
lots of on board memory so on dGPUs we can end up setting gtt size to
3/4
Acked-by: Luben Tuikov
Regards,
Luben
On 2022-06-02 11:47, Christian König wrote:
> The resource must be on the LRU before ttm_lru_bulk_move_add() is called.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_resource.c | 8 +---
> 1 file changed, 5 insertions(+), 3
From: Christian König
Rename vram_scratch into mem_scratch and allow allocating it into GTT as
well.
The only problem with that is that we won't have a default page for the
system aperture any more.
Signed-off-by: Christian König
Signed-off-by: Luben Tuikov
---
From: Christian König
Centralize the limit handling and validation in one place instead
of spreading that around in different hw generations.
Signed-off-by: Christian König
Acked-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
From: Christian König
Technically all of those can use GTT as well, no need to force things
into VRAM.
Signed-off-by: Christian König
Acked-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c | 7 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 20 +++
Some VRAM cleanups from Christian. Second patch needed some work to be able
to compile with most recent amd-staging-drm-next.
Tested on a couple of differing systems.
Christian König (3):
drm/amdgpu: use VRAM|GTT for a bunch of kernel allocations
drm/amdgpu: rename vram_scratch into
The resource must be on the LRU before ttm_lru_bulk_move_add() is called.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_resource.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c
b/drivers/gpu/drm/ttm/ttm_resource.c
On Thu, Jun 2, 2022 at 11:33 AM Dan Carpenter wrote:
>
> On Thu, Jun 02, 2022 at 10:24:58AM -0400, Alex Deucher wrote:
> > On Thu, Jun 2, 2022 at 7:51 AM Dan Carpenter
> > wrote:
> > >
> > > On Thu, Jun 02, 2022 at 08:26:03AM +0200, Ernst Sjöstrand wrote:
> > > > Dan: I also ran Smatch which
On Thu, Jun 02, 2022 at 10:24:58AM -0400, Alex Deucher wrote:
> On Thu, Jun 2, 2022 at 7:51 AM Dan Carpenter wrote:
> >
> > On Thu, Jun 02, 2022 at 08:26:03AM +0200, Ernst Sjöstrand wrote:
> > > Dan: I also ran Smatch which resulted in the following discussion:
> > >
> > >
On Thu, Jun 2, 2022 at 7:51 AM Dan Carpenter wrote:
>
> On Thu, Jun 02, 2022 at 08:26:03AM +0200, Ernst Sjöstrand wrote:
> > Dan: I also ran Smatch which resulted in the following discussion:
> >
> > https://lists.freedesktop.org/archives/amd-gfx/2022-May/079228.html
>
> Since the bounds check is
On Thu, Jun 02, 2022 at 09:58:22AM -0400, Alex Deucher wrote:
> On Fri, May 27, 2022 at 8:58 AM Michal Kubecek wrote:
> > On Fri, May 27, 2022 at 11:00:39AM +0200, Michal Kubecek wrote:
> > > Hello,
> > >
> > > while testing 5.19 merge window snapshots (commits babf0bb978e3 and
> > >
Am 2022-06-02 um 02:47 schrieb Christian König:
Am 01.06.22 um 19:39 schrieb Felix Kuehling:
Am 2022-06-01 um 13:22 schrieb Christian König:
Am 01.06.22 um 19:07 schrieb Felix Kuehling:
Am 2022-06-01 um 12:29 schrieb Christian König:
Am 01.06.22 um 17:05 schrieb Felix Kuehling:
Am
On Fri, May 27, 2022 at 8:58 AM Michal Kubecek wrote:
>
> On Fri, May 27, 2022 at 11:00:39AM +0200, Michal Kubecek wrote:
> > Hello,
> >
> > while testing 5.19 merge window snapshots (commits babf0bb978e3 and
> > 7e284070abe5), I keep getting errors like below. I have not seen them
> > with 5.18
Am 02.06.22 um 15:44 schrieb Lazar, Lijo:
On 6/2/2022 7:06 PM, Christian König wrote:
Am 02.06.22 um 15:26 schrieb Lazar, Lijo:
On 6/2/2022 6:54 PM, Lazar, Lijo wrote:
On 6/2/2022 6:50 PM, Philip Yang wrote:
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but
On 6/2/2022 7:06 PM, Christian König wrote:
Am 02.06.22 um 15:26 schrieb Lazar, Lijo:
On 6/2/2022 6:54 PM, Lazar, Lijo wrote:
On 6/2/2022 6:50 PM, Philip Yang wrote:
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but avoids unnecessary TLB flushes when new PDBs
On 2022-06-01 22:31, Alex Deucher wrote:
> Protect remove_hpo_dp_link_enc_from_ctx() and release_hpo_dp_link_enc()
> with CONFIG_DRM_AMD_DC_DCN as the functions are only called from code
> that is protected by CONFIG_DRM_AMD_DC_DCN. Fixes build fail with
> -Werror=unused-function.
>
> Fixes:
Am 02.06.22 um 15:26 schrieb Lazar, Lijo:
On 6/2/2022 6:54 PM, Lazar, Lijo wrote:
On 6/2/2022 6:50 PM, Philip Yang wrote:
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but avoids unnecessary TLB flushes when new PDBs or PTBs are added to
the page table, which
On 2022-06-02 08:02, Alan Liu wrote:
> Define ixAZALIA_F0_CODEC_PIN_CONTROL_ACP_DATA
> Define AZALIA_F0_CODEC_PIN_CONTROL_ACP_DATA__SUPPORTS_AI_MASK/SHIFT
>
> Signed-off-by: Alan Liu
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_0_d.h | 1 +
On 6/2/2022 6:54 PM, Lazar, Lijo wrote:
On 6/2/2022 6:50 PM, Philip Yang wrote:
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but avoids unnecessary TLB flushes when new PDBs or PTBs are added to
the page table, which commonly happens when memory is mapped for the
On 6/2/2022 6:50 PM, Philip Yang wrote:
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but avoids unnecessary TLB flushes when new PDBs or PTBs are added to
the page table, which commonly happens when memory is mapped for the
first time.
Suggested-by: Christian König
Am 02.06.22 um 15:20 schrieb Philip Yang:
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but avoids unnecessary TLB flushes when new PDBs or PTBs are added to
the page table, which commonly happens when memory is mapped for the
first time.
Suggested-by: Christian König
Flush TLBs when existing PDEs are updated because a PTB or PDB moved,
but avoids unnecessary TLB flushes when new PDBs or PTBs are added to
the page table, which commonly happens when memory is mapped for the
first time.
Suggested-by: Christian König
Signed-off-by: Philip Yang
---
Define ixAZALIA_F0_CODEC_PIN_CONTROL_ACP_DATA
Define AZALIA_F0_CODEC_PIN_CONTROL_ACP_DATA__SUPPORTS_AI_MASK/SHIFT
Signed-off-by: Alan Liu
---
drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_0_d.h | 1 +
drivers/gpu/drm/amd/include/asic_reg/dce/dce_11_0_sh_mask.h | 2 ++
2 files changed, 3
On Thu, Jun 02, 2022 at 08:26:03AM +0200, Ernst Sjöstrand wrote:
> Dan: I also ran Smatch which resulted in the following discussion:
>
> https://lists.freedesktop.org/archives/amd-gfx/2022-May/079228.html
Since the bounds check is dead code which does not make sense and is not
required,
Added device coredump information:
- Kernel version
- Module
- Time
- VRAM status
- Guilty process name and PID
- GPU register dumps
v1 -> v2: Variable name change
v1 -> v2: NULL check
v1 -> v2: Code alignment
v1 -> v2: Adding dummy amdgpu_devcoredump_free
v1 -> v2: memset reset_task_info to zero
Allocate memory for register value and use the same values for devcoredump.
v1 -> v2: Change krealloc_array() to kmalloc_array()
v2 -> v3: Fix alignment
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 7
[AMD Official Use Only - General]
Reviewed-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Wednesday, May 25, 2022 10:09 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: [PATCH] drm/amdgpu: fix up comment in
>
[AMD Official Use Only - General]
Acked-by: Evan Quan
> -Original Message-
> From: amd-gfx On Behalf Of Alex
> Deucher
> Sent: Friday, May 27, 2022 1:58 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander ; Huang, Tim
>
> Subject: [PATCH] drm/amdgpu/soc21: add mode2 asic
Am 02.06.22 um 01:19 schrieb Felix Kuehling:
Am 2022-06-01 um 19:12 schrieb Philip Yang:
Update PDEs, PTEs don't need flush TLB after updating mapping, this will
remove the unnecessary TLB flush to reduce map to GPUs time.
This description is unclear. I think what this change does is, flush
Am 01.06.22 um 19:47 schrieb Bas Nieuwenhuizen:
On Wed, Jun 1, 2022 at 2:40 PM Christian König wrote:
Hey guys,
so today Bas came up with a new requirement regarding the explicit
synchronization to VM updates and a bunch of prototype patches.
I've been thinking about that stuff for quite
Am 01.06.22 um 19:39 schrieb Felix Kuehling:
Am 2022-06-01 um 13:22 schrieb Christian König:
Am 01.06.22 um 19:07 schrieb Felix Kuehling:
Am 2022-06-01 um 12:29 schrieb Christian König:
Am 01.06.22 um 17:05 schrieb Felix Kuehling:
Am 2022-06-01 um 08:40 schrieb Christian König:
Hey
[AMD Official Use Only - General]
> -Original Message-
> From: Christian König
> Sent: Monday, May 30, 2022 3:12 PM
> To: Quan, Evan ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/amdgpu: suppress compile warnings
>
> Am 30.05.22 um 08:50 schrieb
Dan: I also ran Smatch which resulted in the following discussion:
https://lists.freedesktop.org/archives/amd-gfx/2022-May/079228.html
Regards
Den ons 1 juni 2022 kl 20:44 skrev Alex Deucher :
> On Fri, May 27, 2022 at 3:46 AM Dan Carpenter
> wrote:
> >
> > [ kbuild bot sent this warning on
56 matches
Mail list logo
