On 07/03/2024 14:22, Jocelyn Falempe wrote:
> [...]
>
> For drm_panic, I changed the way the debugfs is calling the drm_panic
> functions in the last version:
> https://patchwork.freedesktop.org/patch/581845/?series=122244&rev=9
>
> It doesn't use the panic notifier list, but create a file for e
On 05/03/2024 13:52, Jocelyn Falempe wrote:
> [...]
> Or maybe have two lists of panic notifiers, the safe and the destructive
> list. So in case of fake panic, we can only call the safe notifiers.
>
I tried something like that:
https://lore.kernel.org/lkml/20220427224924.592546-1-gpicc...@igali
On 04/03/2024 18:12, John Ogness wrote:
> [...]
>> The second question is how to simulate a panic context in a
>> non-destructive way, so we can test the panic notifiers in CI, without
>> crashing the machine.
>
> I'm wondering if a "fake panic" can be implemented that quiesces all the
> other CPU
u works fine on Deck with that - great =)
Feel free to add my:
Tested-by: Guilherme G. Piccoli #Steam Deck
Oh, a fixes tag would also makes sense, I guess.
BTW, if possible to submit the 3 patches in a proper series to get it
merged on 6.5-rc cycle (the sooner the better), I'd really appreciate!
Cheers,
Guilherme
On 11/07/2023 15:22, Aurabindo Pillai wrote:
> [...]
> Hi,
>
> Sorry for the delayed response, this patch went unnoticed. This revert would
> break asics. Could you try the attached patch without reverting this one ?
Hi Aurabindo, thanks for your response!
I've tried kernel 6.5-rc1, and it seem
bisecting
amd-staging-drm-next, we narrowed it down to this commit. Seems it
makes sense to revert it to have the tree bootable until a proper
solution is worked.
Cc: Aurabindo Pillai
Cc: André Almeida
Cc: Melissa Wen
Cc: Rodrigo Siqueira
Signed-off-by: Guilherme G. Piccoli
---
Hi Alex / Aur
c: James Zhu
Cc: Leo Liu
Signed-off-by: Guilherme G. Piccoli
---
Hi folks, based on the feedback from the gitlab issue, here is the upstream
attempt to quirk the Steam Deck's BIOSes having known issues with the
indirect SRAM mode. I've tested it on both the quirked BIOSes, and also
wi
On 02/02/2023 13:12, Luben Tuikov wrote:
> Hi Guilherme,
>
> Thanks for redoing to a v3. This patch is:
>
> Reviewed-by: Luben Tuikov
>
> Regards,
> Luben
>
Thank you for the reviews Luben, much appreciated!
On 02/02/2023 08:58, Christian König wrote:
> [...]
>> +if (!ring->no_scheduler && ring->sched.ops)
>> drm_sched_fini(&ring->sched);
>
> I think we should drop the check for no_scheduler here and just call
> drm_sched_fini() when the scheduler instance was initial
iver fini in s3
test (v2)")
Suggested-by: Christian König
Cc: Guchun Chen
Cc: Luben Tuikov
Cc: Mario Limonciello
Signed-off-by: Guilherme G. Piccoli
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/dr
On 01/02/2023 13:21, Luben Tuikov wrote:
> Hi Guilherme,
>
> Since setting sched->ready to false, seems to be taking place in, directly
> amdgpu_ring_fini()
> and in amdgpu_fence_driver_sw_fini() indirectly as that function calls
> drm_sched_fini()
> which sets it to false, we seem to have two c
#x27;s suggestion [0].
[0]
https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb...@amd.com/
Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence driver fini in s3
test (v2)")
Suggested-by: Christian König
Cc: Guchun Chen
Cc: Luben Tuikov
Cc: Mario Limonciello
Signe
On 31/01/2023 14:52, Alex Deucher wrote:
> [...]
>> (b) We can't use sched.ready, which would make sense...but amdgpu
>> overrides its meaning, the driver manipulates this value for its own
>> purposes of tracking ring init, or something like that.
>>
>> This is the tangential topic: what should we
On 31/01/2023 10:58, Chen, Guchun wrote:
> Hi Christian,
>
> Do you think if it makes sense that we can set 'ring->sched.ready' to be true
> in each ring init, even if before executing/setting up drm_sched_init in
> amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler
> struct
+ Luben
(sorry, missed that in the first submission).
On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
> Currently amdgpu calls drm_sched_fini() from the fence driver sw fini
> routine - such function is expected to be called only after the
> respective init function - drm_sched_ini
f44c8b459 ("drm/amdgpu: avoid over-handle of fence driver fini in s3
test (v2)")
Cc: Andrey Grodzovsky
Cc: Guchun Chen
Cc: Mario Limonciello
Signed-off-by: Guilherme G. Piccoli
---
Hi folks, first of all thanks in advance for reviews / comments!
Notice that I've used the Fixes
a
Cc: Sung Joon Kim
Cc: Swapnil Patel
Signed-off-by: Guilherme G. Piccoli
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 8 ++--
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 6 ++
3 files changed,
On 17/01/2023 15:14, Limonciello, Mario wrote:
> [Public]
>
>
>
>> -Original Message-
>> From: Guilherme G. Piccoli
>> Sent: Tuesday, January 17, 2023 12:14
>> To: Limonciello, Mario ; amd-
>> g...@lists.freedesktop.org; Deucher, Alexander
nel.org/amd-gfx/mn0pr12mb61013d20b8a2263b22ae1bcfe2...@mn0pr12mb6101.namprd12.prod.outlook.com
Suggested-by: Alex Deucher
Reviewed-by: Mario Limonciello
Cc: James Zhu
Cc: Lazar Lijo
Cc: Leo Liu
Cc: Sonny Jiang
Signed-off-by: Guilherme G. Piccoli
---
V3:
* Added Mario's review tag and Alex's suggested tag - than
onciello
Cc: Sonny Jiang
Reviewed-by: Alex Deucher
Signed-off-by: Guilherme G. Piccoli
---
V2/V3:
* Added Alex's review tag - thanks!
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 38 -
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/
On 17/01/2023 15:08, Limonciello, Mario wrote:
> [...]
>
> Should have added this tag too:
> Suggested-by: Alexander Deucher
>
> Looks good to me, thanks!
> Reviewed-by: Mario Limonciello
>
You're totally right, thanks for the reminder and apologies for missing
that! Just sending V3 heheh
Ah
nel.org/amd-gfx/mn0pr12mb61013d20b8a2263b22ae1bcfe2...@mn0pr12mb6101.namprd12.prod.outlook.com
Cc: James Zhu
Cc: Lazar Lijo
Cc: Leo Liu
Cc: Mario Limonciello
Cc: Sonny Jiang
Signed-off-by: Guilherme G. Piccoli
---
V2:
* Changed the approach after ML discussion- instead of cleaning up
the switch statement, removed it ent
onciello
Cc: Sonny Jiang
Reviewed-by: Alex Deucher
Signed-off-by: Guilherme G. Piccoli
---
V2:
* Added Alex's review tag - thanks!
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 38 -
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/
On 17/01/2023 13:24, Limonciello, Mario wrote:
> [...]
>>> Though I see two problems with that: first, I'm not sure what's the
>>> impact in the GPU functioning when I disable some IP block.
>>>
>
> It depends on the individual block what the impact is. For example
> if you don't have VCN, then y
On 16/01/2023 23:33, Limonciello, Mario wrote:
> [...]
>
> For debugging these type of problems, I think an effective debugging
> tactic would have been to mask the IP block (amdgpu.ip_block_mask).
Thank you, it worked indeed - nice suggestion!
Though I see two problems with that: first, I'm no
On 16/01/2023 20:00, Alex Deucher wrote:
> [...]
>
> It's not clear to me when this would be used. We only disable it
> briefly during new asic bring up, after that we never touch it again.
> No end user on production hardware should ever have to change it and
> doing so would break VCN on their
On 16/01/2023 19:27, Liu, Leo wrote:
> Secure part requires PSP load VCN boot sequence which is with indirect
> sram mode.
>
> Regards,
> Leo
With that said, and with the plans of just setting the indirect sram
mode nevertheless (with no switch/cases anymore - I'll submit the V2
tomorrow if every
On 16/01/2023 18:49, Limonciello, Mario wrote:
> [...]
>
> The problem with adding a comment about which platform it's in is that
> this will probably go stale. Some IP blocks are re-used in multiple ASICs.
>
> VCN 3, 1, 1 is a great example. This is used in both Yellow Carp (Rembrandt)
> as
On 16/01/2023 18:41, Alex Deucher wrote:
> [...]
>> + case IP_VERSION(4, 0, 0): /* Vega10 */
>
> This comment is incorrect. Vega10 does not have VCN (it has UVD and VCE).
>
> Alex
Thanks Alex! I'll resubmit V2 with this comment removed.
I've stolen it from
https://gitlab.freedeskto
ROR* hw_init of IP block
failed -110
amdgpu :04:00.0: amdgpu: amdgpu_device_ip_init failed
amdgpu :04:00.0: amdgpu: Fatal error during GPU init
Cc: James Zhu
Cc: Lazar Lijo
Cc: Leo Liu
Cc: Mario Limonciello
Cc: Sonny Jiang
Signed-off-by: Guilherme G. Piccoli
---
This work is bas
experience
with the name/number mapping.
Cc: James Zhu
Cc: Lazar Lijo
Cc: Leo Liu
Cc: Mario Limonciello
Cc: Sonny Jiang
Signed-off-by: Guilherme G. Piccoli
---
Hi folks, first of all thanks in advance for reviews/comments!
This work is based on agd5f/amd-staging-drm-next branch - there is
onciello
Cc: Sonny Jiang
Signed-off-by: Guilherme G. Piccoli
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 38 -
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
index f
: Filter Invalid 420 Modes for HDMI TMDS")
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2264
Reported-by: Melissa Wen
Cc: Fangzhi Zuo
Cc: Harry Wentland
Cc: Leo Li
Cc: Mark Broadworth
Cc: Rodrigo Siqueira
Cc: Sung Joon Kim
Signed-off-by: Guilherme G. Piccoli
---
Hi folks, notice
On 29/12/2022 07:15, Dmitry Osipenko wrote:
> [...]
> I'll push the patch to misc-fixes as soon as it will be rebased on
> 6.2-rc. Thanks!
>
> Best regards,
> Dmitry
>
Thank you Dmitry, much appreciated!
Cheers,
Guilherme
ioned in the commit message.
FWIW:
Tested-By: Guilherme G. Piccoli # Steam Deck
Cheers,
Guilherme
gt; Cc: gpicc...@igalia.com
> Signed-off-by: Daniel Vetter
> ---
Hi Daniel, thanks for the improvement - much appreciated!
Below a comment inline; other than that, feel free to add my:
Reviewed-by: Guilherme G. Piccoli
Cheers,
Guilherme
> [...]
>
> -* There's also proposal
On 10/12/2021 12:13, Christian König wrote:
> [...]
> How about issuing a PCIe reset and re-initializing the ASIC with just
> the VBIOS?
>
> That should be pretty straightforward I think.
>
> Christian.
Thanks Christian, that'd be perfect! Is it feasible? Per Alex comment,
we'd need to run ato
On 10/12/2021 11:16, Alex Deucher wrote:> [...]
> Why not just reload the driver after kexec?
>
> Alex
Because the original issue is the kdump case, and we want a very very
tiny kernel - also, the crash originally could have been caused by
amdgpu itself, so if it's a GPU issue, we don't want to m
Thanks a lot Alex / Gerd and Thomas, very informative stuff! I'm glad
there are projects to collect/save the data and reuse after a kdump,
this is very useful.
I'll continue my study on the atombios thing of AMD and QXL, maybe at
least we can make it work in qemu, that'd be great (like a small
ini
Hi all, I have a question about the possibility of reusing a framebuffer
after a regular (or panic) kexec - my case is with amdgpu (APU, aka, not
a separate GPU hardware), but I guess the question is kinda generic
hence I've looped most of the lists / people I think does make sense
(apologies for d
On 09/12/2021 14:31, Alex Deucher wrote:
> [...]
> Once the driver takes over, none of the pre-driver state is retained.
> You'll need to load the driver in the new kernel to initialize the
> displays. Note the efifb doesn't actually have the ability to program
> any hardware, it just takes over
Thanks again Alex! Some comments inlined below:
On 09/12/2021 15:06, Alex Deucher wrote:
> Not really in a generic way. It's asic and platform specific. In
> addition most modern displays require link training to bring up the
> display, so you can't just save and restore registers.
Oh sure, I u
42 matches
Mail list logo
