On Mon, Apr 8, 2024 at 9:45 PM Kees Cook wrote:
>
>
>
> On April 8, 2024 5:45:29 PM PDT, Jeff Johnson
> wrote:
> >On 10/1/23 17:12, Justin Piszcz wrote:
>
> [Sun Oct 1 15:59:04 2023] UBSAN: array-index-ou
[AMD Official Use Only - General]
> -Original Message-
> From: Chai, Thomas
> Sent: Wednesday, April 3, 2024 3:07 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Li, Candice
> ; Wang, Yang(Kevin) ; Yang,
> Stanley ; Chai, Thomas
> Subject: [PAT
On April 8, 2024 5:45:29 PM PDT, Jeff Johnson wrote:
>On 10/1/23 17:12, Justin Piszcz wrote:
[Sun Oct 1 15:59:04 2023] UBSAN: array-index-out-of-bounds in
drivers/gpu/drm/radeon/radeon_atombios.c:26
Applied. Thanks!
Alex
On Sat, Apr 6, 2024 at 11:52 AM Simon Horman wrote:
>
> The path to GPU documentation is Documentation/gpu
> rather than Documentation/GPU
>
> This appears to have been introduced by commit ba162ae749a5
> ("Documentation/gpu: Introduce a simple contribution list for displa
Acked-by: Alex Deucher
Applied.
Thanks,
Alex
On Mon, Apr 8, 2024 at 3:45 AM Xiang Yang wrote:
>
> the dram_clock_change_latency_us in dcn3_51_soc is initialized twice, so
> delete one of them.
>
> Signed-off-by: Xiang Yang
> ---
> drivers/gpu/drm/amd/display/dc/dml/dcn351/dcn351_fpu.c | 1 -
On Mon, Apr 1, 2024 at 8:35 AM Christian König wrote:
>
> Am 30.03.24 um 17:34 schrieb Erick Archer:
> > This is an effort to get rid of all multiplications from allocation
> > functions in order to prevent integer overflows [1] [2].
> >
> > In this case, the memory allocated to store RADEONFB_CON
From: Ville Syrjälä
Replace the open coded drm_crtc_vblank_crtc() with the real
thing.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "Pan, Xinhui"
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vkms.c | 8 ++--
drivers/gpu/drm/
On Tue, Apr 2, 2024 at 7:56 AM Christian König wrote:
>
> Am 02.04.24 um 12:05 schrieb Ma Jun:
> > Waiting for system ready to fix the discovery initialization
> > failure issue. This failure usually occurs when dGPU is removed
> > and then rescanned via command line.
> > It's caused by following
Makes it easier to review the logs when there are MES
errors.
v2: use dbg for emitted, add helpers for fetching strings
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/mes_v11_0.c | 78 --
1 file changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/
On Fri, Apr 5, 2024 at 3:57 AM Christian König
wrote:
>
> When we removed the hacky start code check we actually didn't took into
> account that *all* VRAM pages needs to be CPU accessible.
>
> Clean up the code and unify the handling into a single helper which
> checks if the whole resource is CP
On 08/04/2024 16:16, Arunpravin Paneer Selvam wrote:
Add a new test case for the drm buddy clear and dirty
allocation.
v2:(Matthew)
- make size as u32
- rename PAGE_SIZE with SZ_4K
- dont fragment the address space for all the order allocation
iterations. we can do it once and just
Otherwise the nid is always passed as 0 during memory reclaim so
make TTM shrinkers NUMA aware.
Signed-off-by: Rajneesh Bhardwaj
---
drivers/gpu/drm/ttm/ttm_pool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
Convert a variable sized array from [1] to [].
v2: fix up a few more.
Acked-by: Christian König (v1)
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/pptable.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/pptable.h b/drivers/gpu/drm/rad
Need to take the srbm_mutex and while we are here, use the
helper function soc21_grbm_select();
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
b/dr
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 11cb68ad52ac78c81e33b806b531f097e68edfa2 Add linux-next specific
files for 20240408
Error/Warning: (recently discovered and may have been fixed)
drivers/gpu/drm/drm_mm.c:152:1: error: unused
Hi Matthew,
Could you please review these changes as few clients are waiting for
these patches.
Thanks,
Arun.
On 4/8/2024 8:46 PM, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in th
Add a new test case for the drm buddy clear and dirty
allocation.
v2:(Matthew)
- make size as u32
- rename PAGE_SIZE with SZ_4K
- dont fragment the address space for all the order allocation
iterations. we can do it once and just increment and allocate
the size.
- create new mm wit
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each block as cleared.
- Track the available cleared pages size
- If driver requests cleared memory we prefer cleared
Add clear page support in vram memory region.
v1(Christian):
- Dont handle clear page as TTM flag since when moving the BO back
in from GTT again we don't need that.
- Make a specialized version of amdgpu_fill_buffer() which only
clears the VRAM areas which are not already cleared
-
On 03/28, Jani Nikula wrote:
> On Wed, 27 Mar 2024, Melissa Wen wrote:
> > 2. Most of the edid data handled by `dm_helpers_parse_edid_caps()` are
> >in drm_edid halpers, but there are still a few that are not managed by
> >them yet. For example:
> >```
> > edid_caps->serial_number
On 03/28, Jani Nikula wrote:
> On Wed, 27 Mar 2024, Melissa Wen wrote:
> > Replace raw edid handling (struct edid) with the opaque EDID type
> > (struct drm_edid) on amdgpu_dm_connector for consistency. It may also
> > prevent mismatch of approaches in different parts of the driver code.
> > Worki
After updating GPU page table via CPU on large bar system, no fence
callback, call amdgpu_vm_tlb_seq_cb directly after command committed
to free tlb_cb.
memory leaking backtrace from kmemleakd:
unreferenced object 0xa036816b00c0 (size 32):
backtrace:
__kmem_cache_alloc_node+0x3fe/0x4d
On Thu, Apr 04, 2024 at 12:18:06PM -0700, Easwar Hariharan wrote:
> On 4/2/2024 2:00 AM, Martin Habets wrote:
> > On Fri, Mar 29, 2024 at 05:00:34PM +, Easwar Hariharan wrote:
> >> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> >> with more appropriate terms. Inspired
[AMD Official Use Only - General]
-
Best Regards,
Thomas
-Original Message-
From: Zhou1, Tao
Sent: Monday, April 8, 2024 4:41 PM
To: Chai, Thomas ; amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Li, Candice ;
Wang, Yang(Kevin) ; Yang, Stanley
Subject: RE: [PATCH] dr
[AMD Official Use Only - General]
> -Original Message-
> From: Chai, Thomas
> Sent: Sunday, April 7, 2024 10:21 AM
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org
> Cc: Zhang, Hawking ; Li, Candice
> ; Wang, Yang(Kevin) ; Yang,
> Stanley
> Subject: RE: [PATCH] drm/amdgpu: Fix incorrect
[AMD Official Use Only - General]
>-Original Message-
>From: Koenig, Christian
>Sent: Monday, April 8, 2024 3:55 PM
>To: Yu, Lang ; amd-gfx@lists.freedesktop.org
>Cc: Kuehling, Felix
>Subject: Re: [PATCH] drm/amdkfd: make sure VM is ready for updating
>operations
>
>Am 07.04.24 um 06:52
Am 07.04.24 um 06:52 schrieb Lang Yu:
When VM is in evicting state, amdgpu_vm_update_range would return -EBUSY.
Then restore_process_worker runs into a dead loop.
Fixes: 2fdba514ad5a ("drm/amdgpu: Auto-validate DMABuf imports in compute VMs")
Mhm, while it would be good to have this case handl
On 05/04/2024 12:18, Wolfram Sang wrote:
> Hello Easwar,
>
> On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix driver
Hi Easwar,
> Sorry, got excited. :) There were drivers I'd been part of that I specifically
> wanted to fixup, but then the scope grew to other users of algobit.
Well, you got some positive feedback, so that is good.
> > It is true that I changed quite some controller drivers within the i2c
> >
Hello Alvin Lee,
Commit 285a7054bf81 ("drm/amd/display: Remove plane and stream
pointers from dc scratch") from Mar 15, 2024 (linux-next), leads to
the following Smatch static checker warning:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1112
dcn20_set_input_transfer_func()
the dram_clock_change_latency_us in dcn3_51_soc is initialized twice, so
delete one of them.
Signed-off-by: Xiang Yang
---
drivers/gpu/drm/amd/display/dc/dml/dcn351/dcn351_fpu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn351/dcn351_fpu.c
b/drivers/g
Hello Christian.
On čtvrtek 21. března 2024 15:37:27, CEST Christian König wrote:
> Am 21.03.24 um 15:12 schrieb Tvrtko Ursulin:
> >
> > On 21/03/2024 12:43, Christian König wrote:
> >> This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move
> >> on same heap. The basic problem here i
Hello Bhawanpreet Lakha,
This is a semi-automatic email about new static checker warnings.
Commit e9a09a198bfe ("drm/amd/display: Allow Z8 when stutter
threshold is not met") from Mar 13, 2024, leads to the following
Smatch complaint:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn20/dcn20_
Hi Wolfram,
On 4/5/2024 3:18 AM, Wolfram Sang wrote:
> Hello Easwar,
>
> On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series
the dram_clock_change_latency_us in dcn3_51_soc is initialized twice, so
delete one of them.
Signed-off-by: Xiang Yang
---
drivers/gpu/drm/amd/display/dc/dml/dcn351/dcn351_fpu.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn351/dcn351_fpu.c
b/drivers/g
On 4/5/2024 9:15 AM, Danilo Krummrich wrote:
> Hi Easwar,
>
> On 3/29/24 18:00, Easwar Hariharan wrote:
>> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
>> with more appropriate terms. Inspired by and following on to Wolfram's
>> series to fix drivers/i2c/[1], fix the term
Hello Easwar,
On Fri, Mar 29, 2024 at 05:00:24PM +, Easwar Hariharan wrote:
> I2C v7, SMBus 3.2, and I3C specifications have replaced "master/slave"
> with more appropriate terms. Inspired by and following on to Wolfram's
> series to fix drivers/i2c/[1], fix the terminology for users of the
>
On Fri, Apr 5, 2024 at 8:37 AM kernel test robot wrote:
>
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc Add linux-next
> specific files for 20240405
>
> Error/Warning reports:
>
> https://lore.
38 matches
Mail list logo
