On 1/20/2022 12:57 PM, Chai, Thomas wrote:
-Original Message-
From: Lazar, Lijo
Sent: Thursday, January 20, 2022 1:49 PM
To: Chai, Thomas ; amd-gfx@lists.freedesktop.org
Cc: Zhou1, Tao ; Zhang, Hawking ; Clements, John
; Chai, Thomas
Subject: Re: [PATCH V2 1/2] drm/amdgpu: Move
[Public]
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Evan Quan
Sent: Thursday, January 20, 2022 3:25 PM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander ; Quan, Evan
Subject: [PATCH] drm/amdgpu: suppress the warning about enum value
-Original Message-
From: Lazar, Lijo
Sent: Thursday, January 20, 2022 1:49 PM
To: Chai, Thomas ; amd-gfx@lists.freedesktop.org
Cc: Zhou1, Tao ; Zhang, Hawking ;
Clements, John ; Chai, Thomas
Subject: Re: [PATCH V2 1/2] drm/amdgpu: Move xgmi ras initialization from
.late_init to
Suppress the warning below on building htmldocs:
drivers/gpu/drm/amd/include/amd_shared.h:103: warning: Enum value
'AMD_IP_BLOCK_TYPE_NUM' not described in enum 'amd_ip_block_type'
Fixes: 6ee27ee27ba8 ("drm/amd/pm: avoid duplicate powergate/ungate setting")
Signed-off-by: Evan Quan
Change-Id:
On 1/19/2022 8:34 AM, Mario Limonciello wrote:
Yellow carp has been outputting versions like `1093.24.0`, but this
is supposed to be 69.24.0. That is the MSB is being interpreted
incorrectly.
The MSB is not part of the major version, but has generally been
treated that way thus far. It's
It doesn't work under IP discovery mode. Make it work!
Signed-off-by: Lang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
On Wed, 2022-01-19 at 17:56 -0500, Lyude Paul wrote:
> Hi! I'm writing this email because I'm currently finishing up removing
> pretty
> much all of the non-atomic MST code in drm_dp_mst_topology_mgr.c as it's
> really made it difficult to maintain MST over time. As well, once that's
> complete
On 1/20/2022 8:48 AM, yipechai wrote:
Move xgmi ras initialization from .late_init to .early_init, which let
xgmi ras can be initialized only once.
Signed-off-by: yipechai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 15 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 1 +
On Tuesday, 11 January 2022 9:31:52 AM AEDT Alex Sierra wrote:
> Device memory that is cache coherent from device and CPU point of view.
> This is used on platforms that have an advanced system bus (like CAPI
> or CXL). Any page of a process can be migrated to such memory. However,
> no one should
[AMD Official Use Only]
With the typo fixed, the patch is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: Yang, Stanley
> Sent: Thursday, January 20, 2022 11:25 AM
> To: Zhou1, Tao ; amd-gfx@lists.freedesktop.org
> Cc: Zhang, Hawking ; Clements, John
> ; Ziya, Mohammad zafar
>
>
[AMD Official Use Only]
The series is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: Chai, Thomas
> Sent: Thursday, January 20, 2022 11:19 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Clements,
> John ; Chai, Thomas
> Subject:
[AMD Official Use Only]
> -邮件原件-
> 发件人: Zhou1, Tao
> 发送时间: Thursday, January 20, 2022 11:09 AM
> 收件人: Yang, Stanley ; amd-
> g...@lists.freedesktop.org
> 抄送: Zhang, Hawking ; Clements, John
> ; Ziya, Mohammad zafar
> ; Yang, Stanley
> 主题: RE: [PATCH Review 1/1] drm/amdgpu: fix convert
This reverts commit 48e175f7476c6deb7ccf1f10d081322d52830a17.
Xgmi ras initialization had been moved from .late_init to early_init,
the defect of repeated calling amdgpu_ras_register_ras_block had been
fixed, so revert this patch.
Signed-off-by: yipechai
---
Move xgmi ras initialization from .late_init to .early_init, which let
xgmi ras can be initialized only once.
Signed-off-by: yipechai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 15 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.h | 1 +
drivers/gpu/drm/amd/amdgpu/gmc_v10_0.c | 5
[AMD Official Use Only]
> -Original Message-
> From: Stanley.Yang
> Sent: Thursday, January 20, 2022 12:29 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhang, Hawking ; Zhou1, Tao
> ; Clements, John ; Ziya,
> Mohammad zafar ; Yang, Stanley
>
> Subject: [PATCH Review 1/1] drm/amdgpu:
[Public]
[ 1.310551] trying to bind memory to uninitialized GART !
This is a warning only, it should not break suspend/resume. There is a fix on
drm-next for this "drm/amdgpu: remove gart.ready flag", pls have a try.
If you still observe suspend issue, I guess it's caused by other regression.
[Public]
Thank you all for the review. I've found a better solution here, so I will
retire this patch, and re-submit a different one.
Thanks,
Zhan
> -Original Message-
> From: Liu, Zhan
> Sent: 2022/January/19, Wednesday 5:24 PM
> To: Liu, Zhan ; amd-gfx@lists.freedesktop.org
> Cc:
[AMD Official Use Only]
-Original Message-
From: Liu, Zhan
Sent: Wednesday, January 19, 2022 5:17 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Charlene ; Cornij, Nikola
; Gutierrez, Agustin ;
Pierre-Loup Griffais ; Kotarac, Pavle
Subject: [PATCH] drm/amd/display: Correct MPC
[Public]
This should fix the issue by getting rid of the unneeded flag check during gart
bind:
https://patchwork.freedesktop.org/patch/469907/
Thanks,
Jon
> -Original Message-
> From: amd-gfx On Behalf Of Bert
> Karwatzki
> Sent: January 19, 2022 8:12 PM
> To: Alex Deucher
> Cc:
Yes, return is not necessary here.
I'll apply this patch on dkms-staging to fix the compile
error.
On 1/20/2022 1:10 AM, Deucher, Alexander wrote:
> [AMD Official Use Only]
>
>
> You can just drop the whole line.
>
> Alex
>
>
Hi Dave, Daniel,
Fixes for 5.17. This does not yet include the proper fix for the patch
Linux reverted when he pulled in the original drm merge windows PR. I
was waiting for rc1. At that point do you plan to merge rc1 into drm-fixes?
If so, I can just drop the fix on top.
The following
Unfortunately this does not work either:
[0.859998] [ cut here ]
[0.859998] trying to bind memory to uninitialized GART !
[0.860003] WARNING: CPU: 13 PID: 235 at
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:254 amdgpu_gart_bind+0x29/0x40
[amdgpu]
[0.860099]
On Wed, Jan 19, 2022 at 7:48 PM Bert Karwatzki wrote:
>
> Bisected the error and found the first bad commit to be
> d015e9861e55928a78137a2c95897bc50637fc47 is the first bad commit
> commit d015e9861e55928a78137a2c95897bc50637fc47
> Author: Jonathan Kim
> Date: Thu Dec 9 16:48:56 2021 -0500
>
Bisected the error and found the first bad commit to be
d015e9861e55928a78137a2c95897bc50637fc47 is the first bad commit
commit d015e9861e55928a78137a2c95897bc50637fc47
Author: Jonathan Kim
Date: Thu Dec 9 16:48:56 2021 -0500
drm/amdgpu: improve debug VRAM access performance using sdma
On Wed, Jan 19, 2022 at 06:24:22PM +0100, Daniel Vetter wrote:
> On Wed, Jan 19, 2022 at 08:53:56AM -0800, Ira Weiny wrote:
> > On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny' wrote:
> > > From: Ira Weiny
> > >
> > > This series starts by converting the last easy kmap() uses to
> > >
Reverting commit 72f686438de13f121c52f58d7445570a33dfdc61 does not
change the errors:
[1.310550] [ cut here ]
[1.310551] trying to bind memory to uninitialized GART !
[1.310556] WARNING: CPU: 9 PID: 252 at
drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c:254
Ping~
Seems this patch is missed.
Thanks,
Ray
On Mon, Dec 13, 2021 at 02:34:22PM +0800, Huang, Ray wrote:
> Use __string(), __assign_str() and __get_str() helpers in the TRACE_EVENT()
> instead of string definitions in gpu scheduler trace.
>
> [ 158.890890] [ cut here
Hi! I'm writing this email because I'm currently finishing up removing pretty
much all of the non-atomic MST code in drm_dp_mst_topology_mgr.c as it's
really made it difficult to maintain MST over time. As well, once that's
complete it's likely I'm going to start on the (extremely overdue) task of
The pointer reg is being assigned a value that is not read, the
exit path via label 'out' never accesses it. The assignment is
redundant and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/radeon/radeon_object.c:570:3: warning: Value
stored to 'reg' is never read
[Public]
-Original Message-
From: Liu, Zhan
Sent: Wednesday, January 19, 2022 5:22 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Charlene ; Cornij, Nikola
; Gutierrez, Agustin ;
Kotarac, Pavle ; Pierre-Loup Griffais
Subject: [PATCH] drm/amd/display: change FIFO reset condition to
> > except '"no\0\0yes" + v * 4' works a bit better.
>
> Is it a C code obfuscation contest?
That would be:
return &(v * 3)["no\0yes"];
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
On 1/19/2022 10:59 PM, Limonciello, Mario wrote:
[Public]
-Original Message-
From: Bert Karwatzki
Sent: Wednesday, January 19, 2022 15:52
To: amd-gfx@lists.freedesktop.org
Cc: Limonciello, Mario ; Kazlauskas, Nicholas
; Zhuo, Qingqing (Lillian)
; Scott Bruce ; Alex Deucher
; Chris
[Public]
Apologize for sending out the patch with the wrong sensitivity a few seconds
ago. I've updated sensitivity policy to "Public" here.
Thanks,
Zhan
> -Original Message-
> From: amd-gfx On Behalf Of Liu, Zhan
> Sent: 2022/January/19, Wednesday 5:19 PM
> To:
[Public]
Apologize for sending out the patch with the wrong email sensitivity policy a
few seconds ago. I've updated sensitivity policy to "Public".
Thanks,
Zhan
> -Original Message-
> From: amd-gfx On Behalf Of Liu, Zhan
> Sent: 2022/January/19, Wednesday 5:17 PM
> To:
[Public]
[Why]
FIFO reset is only necessary for fast boot sequence, where otg is disabled
and dig fe is enabled when changing dispclk. Fast boot is only enabled
on embedded displays.
[How]
Change FIFO reset condition to "embedded display only".
Signed-off-by: Zhan Liu
---
Acked-by: Alex Deucher
On Wed, Jan 19, 2022 at 5:19 PM Liu, Zhan wrote:
>
> [AMD Official Use Only]
>
> [Why]
> Current FIFO reset delay for dcn10 is 100us, which is too long
> and will fail atomic flip. As a result, there will be no display
> on boot.
>
> [How]
> Shorten delay time to 1us.
Acked-by: Alex Deucher
On Wed, Jan 19, 2022 at 5:17 PM Liu, Zhan wrote:
>
> [AMD Official Use Only]
>
> [Why]
> DCN301 has seamless boot enabled. With MPC split enabled
> at the same time, system will hang.
>
> [How]
> Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have
> ODM
[AMD Official Use Only]
[Why]
Current FIFO reset delay for dcn10 is 100us, which is too long
and will fail atomic flip. As a result, there will be no display
on boot.
[How]
Shorten delay time to 1us. This also aligns with FIFO reset delay
on other ASICs.
Signed-off-by: Zhan Liu
---
[AMD Official Use Only]
[Why]
DCN301 has seamless boot enabled. With MPC split enabled
at the same time, system will hang.
[How]
Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have
ODM combine enabled on DCN301, pipe split is not necessary here.
Signed-off-by: Zhan Liu
---
I just tested drm-staging-drm-next with HEAD
f1b2924ee6929cb431440e6f961f06eb65d52beb:
Going into suspend leads to a hang again:
This is probably caused by
[ 1.310551] trying to bind memory to uninitialized GART !
and/or
[ 3.976438] trying to bind memory to uninitialized GART !
Here's the
[Public]
> -Original Message-
> From: Bert Karwatzki
> Sent: Wednesday, January 19, 2022 15:52
> To: amd-gfx@lists.freedesktop.org
> Cc: Limonciello, Mario ; Kazlauskas, Nicholas
> ; Zhuo, Qingqing (Lillian)
> ; Scott Bruce ; Alex Deucher
> ; Chris Hixon
> Subject: amd-staging-drm-next
On Wed, Jan 19, 2022 at 04:00:17PM -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 21:25:08 +0200
> Andy Shevchenko wrote:
>
> > > I say keep it one line!
> > >
> > > Reviewed-by: Steven Rostedt (Google)
> >
> > I believe Sakari strongly follows the 80 rule, which means...
>
>
On Wed, Jan 19, 2022 at 12:53:43PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 19, 2022 at 05:15:02PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 19, 2022 at 04:16:12PM +0200, Jani Nikula wrote:
...
> > Yeah we can sed this anytime later we want to, but we need to get the foot
> > in the door.
On Wed, 19 Jan 2022 21:25:08 +0200
Andy Shevchenko wrote:
> > I say keep it one line!
> >
> > Reviewed-by: Steven Rostedt (Google)
>
> I believe Sakari strongly follows the 80 rule, which means...
Checkpatch says "100" I think we need to simply update the docs (the
documentation always
On Wed, 19 Jan 2022 21:22:57 +0200
Andy Shevchenko wrote:
> On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote:
> > > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no";
> > > > > > }
> > >
> > > return "yes\0no" + v * 4;
> > >
> > > :-)
> >
> > except
On Wed, Jan 19, 2022 at 05:15:02PM +0100, Daniel Vetter wrote:
On Wed, Jan 19, 2022 at 04:16:12PM +0200, Jani Nikula wrote:
On Wed, 19 Jan 2022, Petr Mladek wrote:
> On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote:
>> Add some helpers under lib/string_helpers.h so they can be used
>>
On Wed, Jan 19, 2022 at 10:06:35AM -0500, Steven Rostedt wrote:
On Wed, 19 Jan 2022 11:18:59 +0200
Sakari Ailus wrote:
On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote:
> @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct
tomoyo_io_buffer *head,
>case 3:
>
On Wed, Jan 19, 2022 at 11:35:22AM +0900, Esaki Tomohito wrote:
> On 2022/01/18 18:53, Andy Shevchenko wrote:
> > On Mon, Jan 17, 2022 at 02:15:48PM +0900, Esaki Tomohito wrote:
> > > On 2022/01/14 23:16, Andy Shevchenko wrote:
> > > > On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki
On Wed, Jan 19, 2022 at 04:38:26PM +, David Laight wrote:
> > > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
> >
> > return "yes\0no" + v * 4;
> >
> > :-)
>
> except '"no\0\0yes" + v * 4' works a bit better.
Is it a C code obfuscation contest?
--
With
On Tue, Jan 18, 2022 at 11:24:50PM -0800, Lucas De Marchi wrote:
> linux/string_helpers.h provides a helper to return "yes"/"no"
> strings. Replace the open coded versions with yesno(). The places were
> identified with the following semantic patch:
>
> @@
> expression b;
> @@
>
On Wed, Jan 19, 2022 at 10:06:35AM -0500, Steven Rostedt wrote:
> On Wed, 19 Jan 2022 11:18:59 +0200
> Sakari Ailus wrote:
> > On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote:
> > > @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct
> > > tomoyo_io_buffer *head,
> >
Fix incompatible pointer type passed as argument 1
of 'drm_crtc_vblank_count_and_time'. Wrapp the code that uses
drm_vblank_crtc->time under HAVE_DRM_VBLANK_CRTC_STRUCT and
access time field of drm_vblank_crtc structure depending on
the field type, defined by HAVE_DRM_VBLANK_USE_KTIME_T or
[AMD Official Use Only]
Please include a patch description even if it's similar to the subject.
Alex
From: amd-gfx on behalf of Stanley.Yang
Sent: Wednesday, January 19, 2022 6:30 AM
To: amd-gfx@lists.freedesktop.org ; Zhang,
Hawking ; Ziya, Mohammad zafar
On Wed, Jan 19, 2022 at 08:53:56AM -0800, Ira Weiny wrote:
> On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny' wrote:
> > From: Ira Weiny
> >
> > This series starts by converting the last easy kmap() uses to
> > kmap_local_page().
> >
> > There is one more call to kmap() wrapped in
[AMD Official Use Only]
You can just drop the whole line.
Alex
From: amd-gfx on behalf of majun
Sent: Wednesday, January 19, 2022 7:57 AM
To: amd-gfx@lists.freedesktop.org
Subject: [PATCH] amd/amdkfd:Fix the return value in kfd_process_queue_manager
Change
On Fri, Dec 10, 2021 at 03:23:57PM -0800, 'Ira Weiny' wrote:
> From: Ira Weiny
>
> This series starts by converting the last easy kmap() uses to
> kmap_local_page().
>
> There is one more call to kmap() wrapped in ttm_bo_kmap_ttm(). Unfortunately,
> ttm_bo_kmap_ttm() is called in a number of
> > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
return "yes\0no" + v * 4;
:-)
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
On Wed, 19 Jan 2022 11:15:08 +0200
Andy Shevchenko wrote:
> > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
>
>
> Perhaps keep it on 4 lines? Yes, yes/no is short, but if we add others
> (enable/disable) it will not be possible to keep on one line. And hence
>
On Wed, 19 Jan 2022 11:18:59 +0200
Sakari Ailus wrote:
> On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote:
> > @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct
> > tomoyo_io_buffer *head,
> > case 3:
> > if (cond->grant_log != TOMOYO_GRANTLOG_AUTO)
> > > > +static inline const char *yesno(bool v) { return v ? "yes" : "no"; }
>
> return "yes\0no" + v * 4;
>
> :-)
except '"no\0\0yes" + v * 4' works a bit better.
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Pmfw read ecc info registers and store values in
eccinfo_table in the following order
umc0 ch_inst 0, 1, 2 ... 7
umc1 ch_inst 0, 1, 2 ... 7
...
umc3 ch_inst 0, 1, 2 ... 7
Driver should convert eccinfo_table_idx into channel_index according
to channel_idx_tbe.
Change-Id:
kfd_process_notifier_release flush svm_range_restore_work
which calls svm_range_list_lock_and_flush_work to flush deferred_list
work, but if deferred_list work mmput release the last user, it will
call exit_mmap -> notifier_release, it is deadlock with below backtrace.
Move flush
After mm is removed from task->mm, deferred_list work should continue to
handle deferred_range_list which maybe split to child range to avoid
child range leak, and remove ranges mmu interval notifier to avoid mm
mm_count leak, but skip updating notifier and inserting new notifier.
Signed-off-by:
On Wed, Jan 19, 2022 at 04:16:12PM +0200, Jani Nikula wrote:
> On Wed, 19 Jan 2022, Petr Mladek wrote:
> > On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote:
> >> Add some helpers under lib/string_helpers.h so they can be used
> >> throughout the kernel. When I started doing this there were 2
Am 19.01.22 um 16:47 schrieb Jonathan Kim:
Debug VRAM access through SDMA has several broken parts resulting in
silent MMIO fallback.
BO kernel creation takes the location of the cpu addr pointer, not
the pointer itself for address kmap.
drm_dev_enter return true on success so change access
Debug VRAM access through SDMA has several broken parts resulting in
silent MMIO fallback.
BO kernel creation takes the location of the cpu addr pointer, not
the pointer itself for address kmap.
drm_dev_enter return true on success so change access check.
The source BO is reserved but not
[AMD Official Use Only]
> -Original Message-
> From: Huang, JinHuiEric
> Sent: Wednesday, January 19, 2022 10:01 AM
> To: Russell, Kent ; Kuehling, Felix
> ;
> amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdkfd: enable heavy-weight TLB flush on Arcturus
>
>
>
> On
On 2022-01-19 09:50, Russell, Kent wrote:
[AMD Official Use Only]
-Original Message-
From: Kuehling, Felix
Sent: Tuesday, January 18, 2022 7:16 PM
To: Russell, Kent ; Huang, JinHuiEric
; amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdkfd: enable heavy-weight TLB flush on
[AMD Official Use Only]
> -Original Message-
> From: Kuehling, Felix
> Sent: Tuesday, January 18, 2022 7:16 PM
> To: Russell, Kent ; Huang, JinHuiEric
> ; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/amdkfd: enable heavy-weight TLB flush on Arcturus
>
> Am 2022-01-18 um 7:08
Hi Guchun,
yes, just haven't found time to do this yet.
Regards,
Christian.
Am 19.01.22 um 15:24 schrieb Chen, Guchun:
[Public]
Hello Christian,
Do you plan to submit your code to drm-next branch?
Regards,
Guchun
-Original Message-
From: Chen, Guchun
Sent: Tuesday, January 18,
On Wednesday, January 19, 2022, Lucas De Marchi
wrote:
> There are a few implementations of yesno() in the tree. Consolidate them
> in include/linux/string_helpers.h. Quite a few users of open coded
> yesno() could later be converted to the new function:
>
> $ git grep '?\s*"yes"\s*' | wc -l
>
On Wednesday, January 19, 2022, Lucas De Marchi
wrote:
> Follow the yes/no logic and add helpers for enabled/disabled and
> enable/disable - those are not so common throughout the kernel,
> but they give a nice way to reuse the strings to log things as
> enabled/disabled or enable/disable.
>
>
On Wednesday, January 19, 2022, Lucas De Marchi
wrote:
> Add some helpers under lib/string_helpers.h so they can be used
> throughout the kernel. When I started doing this there were 2 other
> previous attempts I know of, not counting the iterations each of them
> had:
>
> 1)
Hi Lucas,
On Tue, Jan 18, 2022 at 11:24:48PM -0800, Lucas De Marchi wrote:
> @@ -1354,8 +1345,7 @@ static bool tomoyo_print_condition(struct
> tomoyo_io_buffer *head,
> case 3:
> if (cond->grant_log != TOMOYO_GRANTLOG_AUTO)
> tomoyo_io_printf(head, "
[Public]
Hello Christian,
Do you plan to submit your code to drm-next branch?
Regards,
Guchun
-Original Message-
From: Chen, Guchun
Sent: Tuesday, January 18, 2022 10:22 PM
To: 'Christian König' ; Kim, Jonathan
; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: remove
On Wed, 19 Jan 2022, Petr Mladek wrote:
> On Tue 2022-01-18 23:24:47, Lucas De Marchi wrote:
>> Add some helpers under lib/string_helpers.h so they can be used
>> throughout the kernel. When I started doing this there were 2 other
>> previous attempts I know of, not counting the iterations each
Change the return value of set_queue_properties_from_criu()
Signed-off-by: majun
Change-Id: I11362eb76eee84e64c5207c24a2b78141f62e63a
---
drivers/gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
[AMD Official Use Only]
Thanks Hawking, the fix in umc_v8_7.c is not included in Zafar's patch.
Regards,
Stanley
> -邮件原件-
> 发件人: Zhang, Hawking
> 发送时间: Wednesday, January 19, 2022 8:10 PM
> 收件人: Yang, Stanley ; amd-
> g...@lists.freedesktop.org; Ziya, Mohammad zafar
> ; Clements, John
>
[AMD Official Use Only]
The change made in drivers/gpu/drm/amd/amdgpu/umc_v8_7.c looks already covered
by Zafar's change. Other than that, the patch looks good to me.
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Stanley.Yang
Sent: Wednesday, January 19, 2022
- Remove drm_mm references and replace with drm buddy functionalities
- Add res cursor support for drm buddy
v2(Matthew Auld):
- replace spinlock with mutex as we call kmem_cache_zalloc
(..., GFP_KERNEL) in drm_buddy_alloc() function
- lock drm_buddy_block_trim() function as it calls
Move shared vram inline functions and structs
into a header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h | 51
1 file changed, 51 insertions(+)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.h
diff --git
On contiguous allocation, we round up the size
to the *next* power of 2, implement a function
to free the unused pages after the newly allocate block.
v2(Matthew Auld):
- replace function name 'drm_buddy_free_unused_pages' with
drm_buddy_block_trim
- replace input argument name
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a low specific
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915
Change-Id: Ic2a488ee253a913d806bd33ee9c90e31a71af320
Signed-off-by: Stanley.Yang
---
drivers/gpu/drm/amd/amdgpu/umc_v6_7.c | 23 ---
drivers/gpu/drm/amd/amdgpu/umc_v8_7.c | 6 --
2 files changed, 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/umc_v6_7.c
[AMD Official Use Only]
> -Original Message-
> From: Chai, Thomas
> Sent: Wednesday, January 19, 2022 5:25 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Chai, Thomas ; Zhang, Hawking
> ; Zhou1, Tao ; Clements,
> John ; Chai, Thomas
> Subject: [PATCH 1/2] drm/amdgpu: Move xgmi ras
On Wed, Jan 19, 2022 at 11:20:38AM +0200, Andy Shevchenko wrote:
On Wednesday, January 19, 2022, Lucas De Marchi
wrote:
Follow the yes/no logic and add helpers for enabled/disabled and
enable/disable - those are not so common throughout the kernel,
but they give a nice way to reuse the
This reverts commit 48e175f7476c6deb7ccf1f10d081322d52830a17.
Xgmi ras initialization had been moved from .late_init to early_init,
the defect of repeated calling amdgpu_ras_register_ras_block had been
fixed, so revert this patch.
Signed-off-by: yipechai
---
Move xgmi ras initialization from .late_init to early_init, which let
xgmi ras can be initialized only once.
Signed-off-by: yipechai
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c| 5 -
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c| 10
From: Wenjing Liu
[why]
There is a recent refactor that contains a typo to cause set throttled
vcp size skipped for dpia link. The change is to fix this typo so it won't cause
black screen
Reviewed-by: Jun Lei
Acked-by: Wayne Lin
Signed-off-by: Wenjing Liu
---
From: Wenjing Liu
[why]
This is internal to dc so we don't have to add a prefix to indicate it
is dc link_hwss instead someone else link_hwss.
Reviewed-by: Aric Cyr
Acked-by: Rodrigo Siqueira
Signed-off-by: Wenjing Liu
---
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 10 +-
[Why]
Currently, when we're tentatively detecting link configuration under mst
case, we will wrongly notify a none existing stream sink to drm layer.
It's due to we'll call amdgpu_dm_update_connector_after_detect() within
dm_helpers_read_local_edid() to update connector when we're still under
From: Wenjing Liu
[why]
as we add more link_hwss we are making a generic way to determine which type
of link_hwss we should use.
Later on we may think of introduce a link policy layer. it could be a thin layer
that decide the type of link_hwss we use. So instead of passing in link and
link_res
From: Wenjing Liu
[Why & How]
DCN guard is not necessary for DP2.x relevant logic.
Drop them.
Reviewed-by: Rodrigo Siqueira
Reviewed-by: Jerry Zuo
Acked-by: Rodrigo Siqueira
Signed-off-by: Wenjing Liu
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 6 +-
From: Wenjing Liu
[why]
Current we have hundreds of if/else or switch statement to check
encoder type in dc_link level. The reason is because depending
on the type of encoder dc_link needs to perform similar programming
task but with different encoder interfaces. The story is to abstract
these
From: Jimmy Kizito
[Why]
According to the USB4 specification, FEC and DSC should be disabled
when a USB4 DPIA operates in TBT3 compatibility mode.
[How]
Upon detecting that a USB4 DPIA is connected to a device that is known
to operate in TBT3 mode, disable FEC and DSC support if they have been
From: Wenjing Liu
[why]
dc_link_detect_helper has multiple purpose:
1. Detect link and local sink.
2. Verify link capability by performing detection link training.
3. Start mst topology discovery and if succeeded fails the current interface.
This is difficult to maintain as item 2 has become
This DC patchset brings improvements mainly on dc layer. In summary, we have:
* Refactor codes under dc_link
* Improve TBT3 compatibility
* Fix DP2.0 flow logic
---
Jimmy Kizito (1):
drm/amd/display: Add work around to enforce TBT3 compatibility.
Wayne Lin (1):
drm/amd/display: Don't
On Tue, 18 Jan 2022, Lucas De Marchi wrote:
> Add some helpers under lib/string_helpers.h so they can be used
> throughout the kernel. When I started doing this there were 2 other
> previous attempts I know of, not counting the iterations each of them
> had:
>
> 1)
99 matches
Mail list logo
