On Wed, Dec 18, 2024 at 10:36:00PM +0800, Huacai Chen wrote:
> Hi, Tiezhu,
>
> On Tue, Dec 17, 2024 at 9:50 AM Tiezhu Yang wrote:
> >
> > When compiling with Clang on LoongArch, there exists the following objtool
> > warning in drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.o:
> >
> > dc_fixp
Hello, sorry about the delay.
On Mon, Dec 16, 2024 at 04:34:00PM -0800, Matthew Brost wrote:
> > However, after further discussion, I think the warning is actually a
> > false positive. See this discussion:
> > https://lists.freedesktop.org/archives/amd-gfx/2024-November/117349.html
> >
> > From
Hi, Tiezhu,
On Tue, Dec 17, 2024 at 9:50 AM Tiezhu Yang wrote:
>
> When compiling with Clang on LoongArch, there exists the following objtool
> warning in drivers/gpu/drm/amd/display/dc/basics/fixpt31_32.o:
>
> dc_fixpt_recip() falls through to next function dc_fixpt_sinc()
>
> This is because
Applied. Thanks!
Alex
On Wed, Dec 18, 2024 at 3:03 AM Lazar, Lijo wrote:
>
>
>
> On 12/18/2024 4:28 AM, Mirsad Todorovac wrote:
> > The static analyser tool gave the following advice:
> >
> > ./drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:1266:7-14: WARNING opportunity
> > for kmemdup
> >
> > → 1
Applied. Thanks!
On Wed, Dec 18, 2024 at 3:59 AM Michel Dänzer wrote:
>
> On 2024-12-18 09:32, Christian König wrote:
> > Am 17.12.24 um 18:22 schrieb Michel Dänzer:
> >> From: Michel Dänzer
> >>
> >> Third time's the charm, I hope?
> >
> > More like the twenties.
>
> The reference is to it bei
Hi,
Dealing here with xorg setups, i have set onto my outputclass section this;
Option "PrimaryGPU" "autoload"
Former means after matchdriver case yes, do output/input from respective
module by video-xorg-xserver grab its modeset first ...
Thx
Luiz
There's a fix for this already in the for-next branch:
https://github.com/btrfs/linux/commit/1a287050962c6847fa4918d6b2a0f4cee35c6943
On 17/12/24 22:58, Mirsad Todorovac wrote:
> >
> The static analyser tool gave the following advice:
>
> ./fs/btrfs/ioctl.c:4987:9-16: WARNING opportunity for kme
This partially reverts commit b7a1a0ef12b81957584fef7b61e2d5ec049c7209.
A user reported stuttering under heavy gfx load with this commit.
I suspect it's due to the fact that the gfx contexts are shared
between the pipes so if there is alot of load on one pipe, we could
end up stalling waiting for
On Tue, Dec 17, 2024 at 11:58:12PM +0100, Mirsad Todorovac wrote:
> The source static analysis tool gave the following advice:
>
> ./fs/xfs/libxfs/xfs_dir2.c:382:15-22: WARNING opportunity for kmemdup
>
> → 382 args->value = kmalloc(len,
>383 GFP_KERNEL | __G
[Public]
Hi Tobais,
-Original Message-
From: Li, Yunxiang (Teddy)
Sent: Thursday, December 19, 2024 12:46 AM
To: Deucher, Alexander ; Tobias Klausmann
; amd-gfx@lists.freedesktop.org
Cc: Zhang, Jesse(Jie) ; Kuehling, Felix
Subject: RE: [Bug report] Regression with kernel v6.13-rc2
[Pu
On Wed, Dec 18, 2024 at 2:18 PM Josh Poimboeuf wrote:
>
> On Wed, Dec 18, 2024 at 10:36:00PM +0800, Huacai Chen wrote:
> > Hi, Tiezhu,
> >
> > On Tue, Dec 17, 2024 at 9:50 AM Tiezhu Yang wrote:
> > >
> > > When compiling with Clang on LoongArch, there exists the following objtool
> > > warning in
Hi Dave, Simona,
New stuff for 6.14.
The following changes since commit 438b39ac74e2a9dc0a5c9d653b7d8066877e86b1:
drm/amdkfd: pause autosuspend when creating pdd (2024-12-10 10:26:18 -0500)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm
[Public]
+Felix
> From: Tobias Klausmann
> Sent: Wednesday, December 18, 2024 10:54
>
> I have been hitting kernel messages from AMDGPU since v6.13-rc2, for
> example:
>
> [Wed Dec 18 15:56:24 2024] gmc_v11_0_process_interrupt: 10 callbacks
> suppressed [Wed Dec 18 15:56:24 2024] amdgpu :03:
[Public]
> From: Tobias Klausmann
> Sent: Wednesday, December 18, 2024 10:54
> Hi!
>
> I have been hitting kernel messages from AMDGPU since v6.13-rc2, for
> example:
>
> [Wed Dec 18 15:56:24 2024] gmc_v11_0_process_interrupt: 10 callbacks
> suppressed [Wed Dec 18 15:56:24 2024] amdgpu :03:00
On 2024-12-18 09:32, Christian König wrote:
> Am 17.12.24 um 18:22 schrieb Michel Dänzer:
>> From: Michel Dänzer
>>
>> Third time's the charm, I hope?
>
> More like the twenties.
The reference is to it being the third time in amdgpu_vm_bo_update.
>> Fixes: d3116756a710 ("drm/ttm: rename bo->me
[AMD Official Use Only - AMD Internal Distribution Only]
> From: Lazar, Lijo
> Sent: Wednesday, December 18, 2024 4:36 PM
> To: Liang, Prike ; amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander
> Subject: Re: [PATCH] drm/amdgpu: Driver needn't request RLC safe mode for gfx
> MGCG
>
>
>
> On
On 12/17/24 15:43, Christian Heusel wrote:
On 24/12/17 06:05PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.12.6 release.
There are 172 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, p
A user-space program, such as rasdaemon, can capture tracepoint information
to decode MCA errors, similar to AMD SMCA error.
Signed-off-by: Ruidong Tian
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c | 3 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 31 +++
2 files changed
The static analyser tool gave the following advice:
./drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:1266:7-14: WARNING opportunity for
kmemdup
→ 1266 tmp = kmalloc(used_size, GFP_KERNEL);
1267 if (!tmp)
1268 return -ENOMEM;
1269
→ 1270 memcpy(tmp, &h
The source static analysis tool gave the following advice:
./fs/xfs/libxfs/xfs_dir2.c:382:15-22: WARNING opportunity for kmemdup
→ 382 args->value = kmalloc(len,
383 GFP_KERNEL | __GFP_NOLOCKDEP |
__GFP_RETRY_MAYFAIL);
384 if (!args->value)
385
The static analyser tool gave the following advice:
./fs/btrfs/ioctl.c:4987:9-16: WARNING opportunity for kmemdup
4986 if (!iov) {
→ 4987 iov = kmalloc(sizeof(struct iovec) *
args.iovcnt, GFP_NOFS);
4988 if (!iov) {
4989
On 24/12/17 06:05PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.12.6 release.
> There are 172 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses shou
On 2024-12-17 12:03, Brian Starkey wrote:
> On Tue, Dec 17, 2024 at 11:13:05AM +, Michel Dänzer wrote:
>> On 2024-12-17 10:14, Brian Starkey wrote:
>>
>>> Modifiers are meant to describe framebuffers, and this pitch alignment
>>> requirement isn't really a framebuffer property - it's a device
>
On 12/18/2024 4:28 AM, Mirsad Todorovac wrote:
> The static analyser tool gave the following advice:
>
> ./drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:1266:7-14: WARNING opportunity for
> kmemdup
>
> → 1266 tmp = kmalloc(used_size, GFP_KERNEL);
>1267 if (!tmp)
>1268
On Mon, Dec 16, 2024 at 04:58:20PM -0500, Marek Olšák wrote:
> On Mon, Dec 16, 2024 at 9:53 AM Simona Vetter
> wrote:
>
> > On Mon, Dec 16, 2024 at 11:46:13AM +0100, Lucas Stach wrote:
> > > Am Montag, dem 16.12.2024 um 10:27 +0100 schrieb Michel Dänzer:
> > > > On 2024-12-15 21:53, Marek Olšák w
On Wed, Dec 18, 2024 at 10:44:17AM +0100, Michel Dänzer wrote:
> On 2024-12-17 12:03, Brian Starkey wrote:
> > On Tue, Dec 17, 2024 at 11:13:05AM +, Michel Dänzer wrote:
> >> On 2024-12-17 10:14, Brian Starkey wrote:
> >>
> >>> Modifiers are meant to describe framebuffers, and this pitch alignm
Initialize the process context address before setting the shader debugger.
[ 260.781212] amdgpu :03:00.0: amdgpu: [gfxhub] page fault (src_id:0
ring:32 vmid:0 pasid:0)
[ 260.781236] amdgpu :03:00.0: amdgpu: in page starting at address
0x from client 10
[ 260.781255]
On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
>
> For that reason I think linear modifiers with explicit pitch/size
> alignment constraints is a sound concept and fits into how modifiers work
> overall.
> -Sima
Could we make it (more) clear that pitch alignment is a "special"
con
Am 17.12.24 um 18:22 schrieb Michel Dänzer:
From: Michel Dänzer
Third time's the charm, I hope?
More like the twenties. It's astonishing how many use cases for BOs
without a backing store we have.
Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
Please double check
On 12/18/2024 1:01 PM, Prike Liang wrote:
> In accordance with the MGCG HW sequence, there is no need for
> the driver to request safe mode before enabling GFX MGCG. For
> GFX10 and later versions, maintaining safe mode is acceptable
> for GFX MGCG; otherwise, there will be an increased overhead
On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> >
> > For that reason I think linear modifiers with explicit pitch/size
> > alignment constraints is a sound concept and fits into how modifiers work
> > overall.
> > -Sima
>
>
> From: Michel Dänzer
>
> Third time's the charm, I hope?
>
> Fixes: d3116756a710 ("drm/ttm: rename bo->mem and make it a pointer")
> Issue: https://gitlab.freedesktop.org/drm/amd/-/issues/3837
> Signed-off-by: Michel Dänzer
> ---
>
> Or should amdgpu_vm_bo_evicted be called in the !bo->tbo.re
Hi Dave, Simona,
Fixes for 6.13.
The following changes since commit d172ea67dbeec5c90f72752c91d202d5718e3754:
Merge tag 'amd-drm-fixes-6.13-2024-12-11' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2024-12-13 09:43:20
+1000)
are available in the Git repository at:
https:/
On 2024-10-04 07:43, Louis Chauvet wrote:
> On 03/10/24 - 16:01, Harry Wentland wrote:
>> Certain operations require us to preserve values below 0.0 and
>> above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
>> such operation is a BT709 encoding operation followed by its
>> decoding ope
34 matches
Mail list logo
