Well first of all don't expose the VMID to userspace.
The UMD doesn't know (and shouldn't know) which VMID is used for a
submission since this is dynamically assigned and can change at any time.
For debugging there is an interface to use an reserved VMID for your
debugged process which allows
Am 02.05.23 um 03:26 schrieb André Almeida:
Em 01/05/2023 16:24, Alex Deucher escreveu:
On Mon, May 1, 2023 at 2:58 PM André Almeida
wrote:
I know that devcoredump is also used for this kind of information,
but I believe
that using an IOCTL is better for interfacing Mesa + Linux rather
than
On Tue, May 2, 2023 at 11:12 AM Timur Kristóf wrote:
>
> Hi Christian,
>
> Christian König ezt írta (időpont: 2023. máj. 2.,
> Ke 9:59):
>>
>> Am 02.05.23 um 03:26 schrieb André Almeida:
>> > Em 01/05/2023 16:24, Alex Deucher escreveu:
>> >> On Mon, May 1, 2023 at 2:58 PM André Almeida
>> >> wr
Hi Timur,
Am 02.05.23 um 11:12 schrieb Timur Kristóf:
Hi Christian,
Christian König ezt írta (időpont: 2023.
máj. 2., Ke 9:59):
Am 02.05.23 um 03:26 schrieb André Almeida:
> Em 01/05/2023 16:24, Alex Deucher escreveu:
>> On Mon, May 1, 2023 at 2:58 PM André Almeida
>> w
On 5/1/23 10:31, Arnd Bergmann wrote:
From: Arnd Bergmann
A global function without a header prototype has made it into
linux-next during the merge window:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6339:6: error: no
previous prototype for 'amdgpu_dm_connector_funcs_force'
[
[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]
[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have enco
Hi Christian,
Christian König ezt írta (időpont: 2023. máj.
2., Ke 9:59):
> Am 02.05.23 um 03:26 schrieb André Almeida:
> > Em 01/05/2023 16:24, Alex Deucher escreveu:
> >> On Mon, May 1, 2023 at 2:58 PM André Almeida
> >> wrote:
> >>>
> >>> I know that devcoredump is also used for this kind of
On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
Leemhuis) wrote:
>
> [CCing the regression list, as it should be in the loop for regressions:
> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>
> [TLDR: I'm adding this report to the list of tracked Linux kernel
>
On Tue, May 2, 2023 at 9:34 AM Linux regression tracking (Thorsten
Leemhuis) wrote:
>
> On 02.05.23 15:13, Alex Deucher wrote:
> > On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
> > Leemhuis) wrote:
> >
> >> On 30.04.23 13:44, Felix Richter wrote:
> >>> Hi,
> >>>
> >>> I am ru
On 02.05.23 15:13, Alex Deucher wrote:
> On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
> Leemhuis) wrote:
>
>> On 30.04.23 13:44, Felix Richter wrote:
>>> Hi,
>>>
>>> I am running into an issue with the integrated GPU of the Ryzen 9 7950X. It
>>> seems to be a regression from
Hi,
On Tue, 2023-05-02 at 13:14 +0200, Christian König wrote:
> >
> > Christian König ezt írta (időpont: 2023.
> > máj. 2., Ke 9:59):
> >
> > > Am 02.05.23 um 03:26 schrieb André Almeida:
> > > > Em 01/05/2023 16:24, Alex Deucher escreveu:
> > > >> On Mon, May 1, 2023 at 2:58 PM André Almeid
On Tue, May 2, 2023 at 9:35 AM Timur Kristóf wrote:
>
> Hi,
>
> On Tue, 2023-05-02 at 13:14 +0200, Christian König wrote:
> > >
> > > Christian König ezt írta (időpont: 2023.
> > > máj. 2., Ke 9:59):
> > >
> > > > Am 02.05.23 um 03:26 schrieb André Almeida:
> > > > > Em 01/05/2023 16:24, Alex De
On 04/30/ , Yifan Zhang wrote:
> APUs w/ gfx9 onwards doesn't reply on PCIe atomics, rather
> it is internal path w/ native atomic support. Set have_atomics_support
> to true.
>
> Signed-off-by: Yifan Zhang
Reviewed-by: Lang Yu
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 6 ++
>
On 5/2/23 15:34, Linux regression tracking (Thorsten Leemhuis) wrote:
On 02.05.23 15:13, Alex Deucher wrote:
On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
Leemhuis) wrote:
On 30.04.23 13:44, Felix Richter wrote:
Hi,
I am running into an issue with the integrated GPU of
On 02.05.23 15:48, Felix Richter wrote:
> On 5/2/23 15:34, Linux regression tracking (Thorsten Leemhuis) wrote:
>> On 02.05.23 15:13, Alex Deucher wrote:
>>> On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
>>> Leemhuis) wrote:
>>>
On 30.04.23 13:44, Felix Richter wrote:
>>>
On Tue, 2023-05-02 at 09:45 -0400, Alex Deucher wrote:
> On Tue, May 2, 2023 at 9:35 AM Timur Kristóf
> wrote:
> >
> > Hi,
> >
> > On Tue, 2023-05-02 at 13:14 +0200, Christian König wrote:
> > > >
> > > > Christian König ezt írta (időpont:
> > > > 2023.
> > > > máj. 2., Ke 9:59):
> > > >
> >
As made mention of, in commit 9128e6babf10 ("drm/amdgpu: fix
amdgpu_irq_put call trace in gmc_v10_0_hw_fini") and commit c094b8923bdd
("drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v11_0_hw_fini"). It
is meaningless to call amdgpu_irq_put() for gmc.ecc_irq. So, remove it
from gmc_v9_0_hw_fini()
On Tue, May 2, 2023 at 11:22 AM Timur Kristóf wrote:
>
> On Tue, 2023-05-02 at 09:45 -0400, Alex Deucher wrote:
> > On Tue, May 2, 2023 at 9:35 AM Timur Kristóf
> > wrote:
> > >
> > > Hi,
> > >
> > > On Tue, 2023-05-02 at 13:14 +0200, Christian König wrote:
> > > > >
> > > > > Christian König ez
This DC patchset brings improvements in multiple areas. In summary, we
highlight:
* Block SubVP on displays that have pixclk > 1800Mhz
* Block SubVP high refresh when VRR active fixed
* Enforce 60us prefetch for 200Mhz DCFCLK modes
* Check Vactive for VRR active for FPO + Vactive
* Add symclk wor
From: Sung Lee
[WHY]
These registers would be useful to know when debugging pstate issues.
[HOW]
Add additional registers to hw state query.
Reviewed-by: Aric Cyr
Reviewed-by: Jun Lei
Acked-by: Alex Hung
Signed-off-by: Sung Lee
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h | 2 ++
From: Rodrigo Siqueira
Some times people send their dmesg log for debugging, and one common
task is to check the modesetting line to catch which DCN/DCE we need to
debug. This commit introduces a simple conversion from the DCN/DCE
version to a string shown in the dmesg log.
Reviewed-by: Hamza Ma
From: Leo Chen
[Why & How]
This is originally a change (9c75891f) in DCN32 because of the lack
of interface to set TX while keeping symclk on. Adding this workaround
to DCN314 will resolve the current issue.
Fixes: 9c75891feef0 ("drm/amd/display: rework recent update PHY state commit")
Reviewed-
From: Alvin Lee
[Description]
- For FPO + Vactive cases, we rely on the Vactive display to be at
it's nominal refresh rate because the Vactive pipe may not necessarily
assert P-State allow while it's in VBLANK
- For cases where the Vactive display has a stretched VBLANK due to
VRR, we could
From: Alvin Lee
[Description]
- Due to bandwidth / arbitration issues at 200Mhz DCFCLK,
we want to enforce minimum 60us of prefetch to avoid
intermittent underflow issues
- Since 60us prefetch is already enforced for UCLK DPM0,
and many DCFCLK's > 200Mhz are mapped to UCLK DPM1, in
theory
From: Alvin Lee
[Description]
- SubVP high refresh is blocked when VRR is active variable, but
we should also block it for when VRR is active fixed (video use
case)
Reviewed-by: Nevenko Stupar
Reviewed-by: Jun Lei
Cc: Mario Limonciello
Cc: Alex Deucher
Cc: sta...@vger.kernel.org
Acked-by
From: Alvin Lee
[Description]
- Enabling SubVP on high refresh rate displays had a side effect
of also enabling on high bandwidth displays such as 8K60
- However, these are not validated and should be blocked for
the time being
- Block SubVP on displays that have pix rate > 1800Mhz (includes
From: Aric Cyr
This version brings along following fixes:
- Block SubVP on displays that have pixclk > 1800Mhz
- Block SubVP high refresh when VRR active fixed
- Enforce 60us prefetch for 200Mhz DCFCLK modes
- Check Vactive for VRR active for FPO + Vactive
- Add symclk workaround during disable l
27 matches
Mail list logo
