Am 01.03.22 um 07:26 schrieb Qiang Yu:
Regression has been reported that suspend/resume may hang with
the previous vm ready check commit:
https://gitlab.freedesktop.org/drm/amd/-/issues/1915#note_1278198
So bring back the evicted list check as a temp fix.
Fixes: cc8dd2cc1a97 ("drm/amdgpu:
[Why]
As PSP needs to verify the signature, CAP firmware must be loaded first when
PSP loads firmwares.
Otherwise, when DFC feature is enabled, CP firmwares would be loaded failed.
[ 1149.160480] [drm] MM table gpu addr = 0x800022f000, cpu addr =
a62afcea.
[ 1149.209874] [drm] failed to
Am 28.02.22 um 22:13 schrieb James Bottomley:
On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote:
Am 28.02.22 um 21:42 schrieb James Bottomley:
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
Am 28.02.22 um 20:56 schrieb Linus Torvalds:
On Mon, Feb 28, 2022 at 4:19 AM
On Mon, 28 Feb 2022 16:41:04 -0800 Linus Torvalds wrote:
> So yes, initially my idea had been to just move the iterator entirely
> inside the macro. But specifying the type got so ugly that I think
> that
>
> typeof (pos) pos
>
> trick inside the macro really ends up giving us the best
Regression has been reported that suspend/resume may hang with
the previous vm ready check commit:
https://gitlab.freedesktop.org/drm/amd/-/issues/1915#note_1278198
So bring back the evicted list check as a temp fix.
Fixes: cc8dd2cc1a97 ("drm/amdgpu: check vm ready by amdgpu_vm->evicting flag")
On Tue, 1 Mar 2022 at 03:11, Alex Deucher wrote:
>
> On Mon, Feb 28, 2022 at 1:55 AM Dave Airlie wrote:
> >
> > On Sat, 26 Feb 2022 at 04:35, Alex Deucher
> > wrote:
> > >
> > > Hi Dave, Daniel,
> > >
> > > New stuff for 5.18.
> > >
> > > The following changes since commit
> > >
On Mon, Feb 28, 2022 at 10:20:28AM -0800, Joe Perches wrote:
> On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:
>
> > a multi-line indent gets curly braces for readability even though
> > it's not required by C. And then both sides would get curly braces.
>
> That's more your personal
Enable gfx cg gate/ungate control for GC 10.3.7.
Signed-off-by: Prike Liang
---
drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
index 90158289cd30..fd7ded7799e2 100644
---
Reviewed-by: Guchun Chen
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Tuesday, March 1, 2022 6:16 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: Use IP versions in
convert_tiling_flags_to_modifier()
Rather
On 2022-02-28 15:34, Alex Sierra wrote:
DEVICE_COHERENT pages introduce a subtle distinction in the way
"normal" pages can be used by various callers throughout the kernel.
They behave like normal pages for purposes of mapping in CPU page
tables, and for COW. But they do not support LRU lists,
[AMD Official Use Only]
> -Original Message-
> From: Lukas Wunner
> Sent: Monday, February 28, 2022 16:33
> To: Bjorn Helgaas
> Cc: Limonciello, Mario ; Mika Westerberg
> ; Michael Jamet
> ; open list:PCI SUBSYSTEM p...@vger.kernel.org>; open list:THUNDERBOLT DRIVER
On Mon, Feb 28, 2022 at 04:13:44PM -0600, Bjorn Helgaas wrote:
> On Mon, Feb 28, 2022 at 03:33:13PM +, Limonciello, Mario wrote:
> > > On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote:
> > > > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external-
> > > facing"
> > > >
On Mon, 2022-02-28 at 23:59 +0200, Mike Rapoport wrote:
>
> On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
[...]
> > > > I do wish we could actually poison the 'pos' value
Applied. Thanks!
Alex
On Mon, Feb 28, 2022 at 5:55 AM Christian König
wrote:
>
> Am 27.02.22 um 16:33 schrieb t...@redhat.com:
> > From: Tom Rix
> >
> > Clang static analysis reports this error
> > amdgpu_debugfs.c:1690:9: warning: 1st function call
> >argument is an uninitialized value
>
Rather than checking the asic_type.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index
On Mon, Feb 28, 2022 at 03:33:13PM +, Limonciello, Mario wrote:
> [AMD Official Use Only]
>
> >
> > On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote:
> > > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external-
> > facing"
> > > assumption above. Not having a
> On 28. Feb 2022, at 21:56, Christian König wrote:
>
>
>
> Am 28.02.22 um 21:42 schrieb James Bottomley:
>> On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
>>> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
On Mon, Feb 28, 2022 at 4:19 AM Christian König
wrote:
On Mon, Feb 28, 2022 at 12:14:44PM -0800, Linus Torvalds wrote:
> On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds
> wrote:
> >
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_
On February 28, 2022 10:42:53 PM GMT+02:00, James Bottomley
wrote:
>On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
>> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
>> > On Mon, Feb 28, 2022 at 4:19 AM Christian König
>> > wrote:
>> > > I don't think that using the extra variable
> On 28. Feb 2022, at 21:10, Linus Torvalds
> wrote:
>
> On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds
> wrote:
>>
>> Side note: we do need *some* way to do it.
>
> Ooh.
>
> This patch is a work of art.
>
> And I mean that in the worst possible way.
>
> We can do
>
>
On Mon, Feb 28, 2022 at 3:45 PM James Bottomley
wrote:
> ...
> > Just from skimming over the patches to change this and experience
> > with the drivers/subsystems I help to maintain I think the primary
> > pattern looks something like this:
> >
> > list_for_each_entry(entry, head, member) {
> >
On Mon, Feb 28, 2022 at 12:29 PM Johannes Berg
wrote:
>
> If we're willing to change the API for the macro, we could do
>
> list_for_each_entry(type, pos, head, member)
>
> and then actually take advantage of -Wshadow?
See my reply to Willy. There is no way -Wshadow will ever happen.
I
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > On Mon, Feb 28, 2022 at 4:19 AM Christian König
> > wrote:
> > > I don't think that using the extra variable makes the code in any
> > > way
> > > more reliable or easier to read.
> > So I
On Mon, 2022-02-28 at 21:56 +0100, Christian König wrote:
>
> Am 28.02.22 um 21:42 schrieb James Bottomley:
> > On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
> > > Am 28.02.22 um 20:56 schrieb Linus Torvalds:
> > > > On Mon, Feb 28, 2022 at 4:19 AM Christian König
> > > > wrote:
> >
FPU operations in dcn10 was already moved to dml folder via calcs code.
However, dcn1_0_ip and dcn_1_0_soc with FPU componentd remains on dcn10.
Following previous changes to isolate FPU, this patch creates dcn10_fpu
files to isolate FPU-specific code and moves those structs to it.
Signed-off-by:
dml/dcn20_fpu file centralizes all DCN2x functions that require FPU access.
Therefore, this patch moves FPU-related code from dcn21 to dcn20_fpu. These
include:
- dcn21_populate_dml_pipes_from_context()
- dcn21_validate_bandwidth_fp() and related:
- dcn21_calculate_wm(),
-
Continuing the work of isolating FPU code from DCN drivers, this
patchset moves FPU-specific operations from dcn10 and dcn21 to dml
folder. I move FPU code from dcn21 to dml/dcn20_fpu since there is a
documentation in dcn20_fpu.c that states dcn20_fpu centralizes:
`all DCN20 and DCN2.1 (DCN2x)
Am 28.02.22 um 21:42 schrieb James Bottomley:
On Mon, 2022-02-28 at 21:07 +0100, Christian König wrote:
Am 28.02.22 um 20:56 schrieb Linus Torvalds:
On Mon, Feb 28, 2022 at 4:19 AM Christian König
wrote:
[SNIP]
Anybody have any ideas?
I think we should look at the use cases why code is
On Mon, Feb 28, 2022 at 12:16 PM Matthew Wilcox wrote:
>
> Then we can never use -Wshadow ;-( I'd love to be able to turn it on;
> it catches real bugs.
Oh, we already can never use -Wshadow regardless of things like this.
That bridge hasn't just been burned, it never existed in the first
On Mon, 2022-02-28 at 20:16 +, Matthew Wilcox wrote:
> On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> > We can do
> >
> > typeof(pos) pos
> >
> > in the 'for ()' loop, and never use __iter at all.
> >
> > That means that inside the for-loop, we use a _different_
DEVICE_COHERENT pages introduce a subtle distinction in the way
"normal" pages can be used by various callers throughout the kernel.
They behave like normal pages for purposes of mapping in CPU page
tables, and for COW. But they do not support LRU lists, NUMA
migration or THP. Therefore we split
On Mon, Feb 28, 2022 at 12:10:24PM -0800, Linus Torvalds wrote:
> We can do
>
> typeof(pos) pos
>
> in the 'for ()' loop, and never use __iter at all.
>
> That means that inside the for-loop, we use a _different_ 'pos' than outside.
Then we can never use -Wshadow ;-( I'd love to be
On Mon, Feb 28, 2022 at 12:10 PM Linus Torvalds
wrote:
>
> We can do
>
> typeof(pos) pos
>
> in the 'for ()' loop, and never use __iter at all.
>
> That means that inside the for-loop, we use a _different_ 'pos' than outside.
The thing that makes me throw up in my mouth a bit is that in
On Mon, Feb 28, 2022 at 11:56 AM Linus Torvalds
wrote:
>
> I do wish we could actually poison the 'pos' value after the loop
> somehow - but clearly the "might be uninitialized" I was hoping for
> isn't the way to do it.
Side note: we do need *some* way to do it.
Because if we make that change,
On Mon, Feb 28, 2022 at 12:03 PM Linus Torvalds
wrote:
>
> Side note: we do need *some* way to do it.
Ooh.
This patch is a work of art.
And I mean that in the worst possible way.
We can do
typeof(pos) pos
in the 'for ()' loop, and never use __iter at all.
That means that inside the
Am 28.02.22 um 20:56 schrieb Linus Torvalds:
On Mon, Feb 28, 2022 at 4:19 AM Christian König
wrote:
I don't think that using the extra variable makes the code in any way
more reliable or easier to read.
So I think the next step is to do the attached patch (which requires
that "-std=gnu11"
On Mon, Feb 28, 2022 at 4:19 AM Christian König
wrote:
>
> I don't think that using the extra variable makes the code in any way
> more reliable or easier to read.
So I think the next step is to do the attached patch (which requires
that "-std=gnu11" that was discussed in the original thread).
On Mon, 2022-02-28 at 14:24 +0300, Dan Carpenter wrote:
> a multi-line indent gets curly braces for readability even though
> it's not required by C. And then both sides would get curly braces.
That's more your personal preference than a coding style guideline.
https://gitlab.freedesktop.org/drm/amd/-/issues/1922
2022-03-01 1:26 GMT+08:00, youling257 :
> this patch cause suspend to disk resume amdgpu hang,
> [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled
> seq=8330, emitted seq=8332
>
>
this patch cause suspend to disk resume amdgpu hang, [drm:amdgpu_job_timedout
[amdgpu]] *ERROR* ring gfx timeout, signaled seq=8330, emitted seq=8332
https://gitlab.freedesktop.org/drm/amd/-/issues/1915
Aldebaran has 48-bit physical address support
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c
index
On Mon, Feb 28, 2022 at 1:55 AM Dave Airlie wrote:
>
> On Sat, 26 Feb 2022 at 04:35, Alex Deucher wrote:
> >
> > Hi Dave, Daniel,
> >
> > New stuff for 5.18.
> >
> > The following changes since commit b63c54d978236dd6014cf2ffba96d626e97c915c:
> >
> > drm/amdkfd: Use proper enum in
[AMD Official Use Only]
>
> On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote:
> > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external-
> facing"
> > assumption above. Not having a Thunderbolt spec, I have no idea how
> > you deal with that.
>
> You can download the
[AMD Official Use Only]
Hi Christian,
I will check
Thanks,
Arun
-Original Message-
From: Koenig, Christian
Sent: Monday, February 28, 2022 4:29 PM
To: kernel test robot ; Paneer Selvam, Arunpravin
Cc: 0day robot ; Matthew Auld ; LKML
; l...@lists.01.org;
i dont have currently a setup with non as module compiled
but when i do, im sure it tries to load em right, they were just not in the
initrd ...
ill check when i be on it, somewhen not now
cheers
On Mon, Feb 28, 2022 at 12:50 PM Christian König <
ckoenig.leichtzumer...@gmail.com> wrote:
> Am
[Public]
Hi all,
This week this patchset was tested on the following systems:
Lenovo Thinkpad T14s Gen2 with AMD Ryzen 5 5650U, with the following display
types: eDP 1080p 60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C
to DP/HDMI), 1680*1050 60hz (via USB-C to DP and then DP
> On 28. Feb 2022, at 12:20, Greg KH wrote:
>
> On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
>> If the list does not contain the expected element, the value of
>> list_for_each_entry() iterator will not point to a valid structure.
>> To avoid type confusion in such case, the
> On 28. Feb 2022, at 12:24, Dan Carpenter wrote:
>
> On Mon, Feb 28, 2022 at 12:08:17PM +0100, Jakob Koschel wrote:
>> diff --git a/drivers/usb/gadget/udc/at91_udc.c
>> b/drivers/usb/gadget/udc/at91_udc.c
>> index 9040a0561466..0fd0307bc07b 100644
>> --- a/drivers/usb/gadget/udc/at91_udc.c
On Mon, Feb 28, 2022 at 01:03:36PM +0100, Jakob Koschel wrote:
> >> @@ -954,7 +957,6 @@ net2272_dequeue(struct usb_ep *_ep, struct usb_request
> >> *_req)
> >>dev_dbg(ep->dev->dev, "unlink (%s) pio\n", _ep->name);
> >>net2272_done(ep, req, -ECONNRESET);
> >>}
> >> -
On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
> diff --git a/drivers/scsi/scsi_transport_sas.c
> b/drivers/scsi/scsi_transport_sas.c
> index 4ee578b181da..a8cbd90db9d2 100644
> --- a/drivers/scsi/scsi_transport_sas.c
> +++ b/drivers/scsi/scsi_transport_sas.c
> @@ -1060,26
On Mon, Feb 28, 2022 at 12:08:22PM +0100, Jakob Koschel wrote:
> diff --git a/drivers/infiniband/hw/hfi1/tid_rdma.c
> b/drivers/infiniband/hw/hfi1/tid_rdma.c
> index 2a7abf7a1f7f..a069847b56aa 100644
> --- a/drivers/infiniband/hw/hfi1/tid_rdma.c
> +++ b/drivers/infiniband/hw/hfi1/tid_rdma.c
> @@
Am 28.02.22 um 12:08 schrieb Jakob Koschel:
If the list does not contain the expected element, the value of
list_for_each_entry() iterator will not point to a valid structure.
To avoid type confusion in such case, the list iterator
scope will be limited to list_for_each_entry() loop.
We
Am 28.02.22 um 07:43 schrieb Alex fxmbsw7 Ratchev:
On Mon, Feb 28, 2022 at 12:22 AM Mike Lothian wrote:
On Sat, 26 Feb 2022 at 10:01, Alex fxmbsw7 Ratchev
wrote:
>
> i have observed at least two major problems of using amdgpu
>
> 1. cant be built-in instead of
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will *always* be a bogus
pointer computed based on the head element.
To avoid type confusion use the actual list head directly instead of last
iterator value.
Signed-off-by: Jakob
If the list does not contain the expected element, the value of
list_for_each_entry() iterator will not point to a valid structure.
To avoid type confusion in such case, the list iterator
scope will be limited to list_for_each_entry() loop.
In preparation to limiting scope of a list iterator to
This is the first patch removing several categories of use cases of
the list iterator variable past the loop.
This is follow up to the discussion in:
https://lore.kernel.org/all/20220217184829.1991035-1-jakobkosc...@gmail.com/
As concluded in:
If the list representing the request queue does not contain the expected
request, the value of list_for_each_entry() iterator will not point to a
valid structure. To avoid type confusion in such case, the list iterator
scope will be limited to list_for_each_entry() loop.
In preparation to
The list iterator variable will be a bogus pointer if no break was hit.
Dereferencing it could load *any* out-of-bounds/undefined value
making it unsafe to use that in the comparision to determine if the
specific element was found.
This is fixed by using a separate list iterator variable for the
When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.
While it is safe to use the pointer to determine if it was computed
based on the head element, either with
From: Tom Rix
Clang static analysis reports this error
amdgpu_debugfs.c:1690:9: warning: 1st function call
argument is an uninitialized value
tmp = krealloc_array(tmp, i + 1,
^~~
realloc uses tmp, so tmp can not be garbage.
And the return needs to be checked.
This is a bit more work (and a lot more noise), but I'd prefer if
this were split into as many patches as there are components.
I'm not going to review the parts of the patches that don't concern me,
and if something turns out to be a problem later one (it shouldn't but
one never knows) it'll be
On Mon, Feb 28, 2022 at 12:08:18PM +0100, Jakob Koschel wrote:
> If the list does not contain the expected element, the value of
> list_for_each_entry() iterator will not point to a valid structure.
> To avoid type confusion in such case, the list iterator
> scope will be limited to
The list iterator value will *always* be set by list_for_each_entry().
It is incorrect to assume that the iterator value will be NULL if the
list is empty.
Instead of checking the pointer it should be checked if
the list is empty.
In acpi_get_pmu_hw_inf() instead of setting the pointer to NULL
on
From: t...@redhat.com
> Sent: 26 February 2022 15:59
>
> From: Tom Rix
>
> Clang static analysis reports this error
> amdgpu_debugfs.c:1690:9: warning: 1st function call
> argument is an uninitialized value
> tmp = krealloc_array(tmp, i + 1,
> ^~~
>
>
From: Tom Rix
Clang static analysis reports this error
amdgpu_debugfs.c:1690:9: warning: 1st function call
argument is an uninitialized value
tmp = krealloc_array(tmp, i + 1,
^~~
realloc will free tmp, so tmp can not be garbage.
And the return needs to be
Hi Bjorn,
On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote:
> That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external-facing"
> assumption above. Not having a Thunderbolt spec, I have no idea how
> you deal with that.
You can download the spec here:
Hi,
I've Gigabyte Radeon RX Vega 64 and sometimes when booting it doesn't
give any signal to monitor over DisplayPort. Rebooting usually helps
and it works fine after. Not sure if it's hardware or software issue.
In dmesg only suspicious thing I see is many
[drm]
On 2/26/22 2:21 PM, David Laight wrote:
From: t...@redhat.com
Sent: 26 February 2022 15:59
From: Tom Rix
Clang static analysis reports this error
amdgpu_debugfs.c:1690:9: warning: 1st function call
argument is an uninitialized value
tmp = krealloc_array(tmp, i + 1,
On Mon, Feb 28, 2022 at 12:22 AM Mike Lothian wrote:
> On Sat, 26 Feb 2022 at 10:01, Alex fxmbsw7 Ratchev
> wrote:
> >
> > i have observed at least two major problems of using amdgpu
> >
> > 1. cant be built-in instead of module, display stays blank
>
> Are you remembering to add in the
On Mon, Feb 28, 2022 at 12:08:19PM +0100, Jakob Koschel wrote:
> The list iterator value will *always* be set by list_for_each_entry().
> It is incorrect to assume that the iterator value will be NULL if the
> list is empty.
>
> Instead of checking the pointer it should be checked if
> the list
On Mon, Feb 28, 2022 at 12:08:17PM +0100, Jakob Koschel wrote:
> diff --git a/drivers/usb/gadget/udc/at91_udc.c
> b/drivers/usb/gadget/udc/at91_udc.c
> index 9040a0561466..0fd0307bc07b 100644
> --- a/drivers/usb/gadget/udc/at91_udc.c
> +++ b/drivers/usb/gadget/udc/at91_udc.c
> @@ -150,13 +150,14
Arun can you take a look at that one here?
It looks like a real problem to me and not just a potential false
negative like the other issue.
Thanks,
Christian.
Am 27.02.22 um 16:18 schrieb kernel test robot:
Greeting,
FYI, we noticed the following commit (built with gcc-9):
commit:
Am 27.02.22 um 16:33 schrieb t...@redhat.com:
From: Tom Rix
Clang static analysis reports this error
amdgpu_debugfs.c:1690:9: warning: 1st function call
argument is an uninitialized value
tmp = krealloc_array(tmp, i + 1,
^~~
realloc uses tmp, so tmp can
Use IP version and refactor reset logic to apply to a list of devices.
Signed-off-by: Lijo Lazar
Reviewed-by: Hawking Zhang
---
drivers/gpu/drm/amd/amdgpu/aldebaran.c| 66 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 8 +--
2 files changed, 54 insertions(+), 20
74 matches
Mail list logo
