From: tiancyin
[ Upstream commit c1cefe115d1cdc460014483319d440b2f0d07c68 ]
[Why]
the member sdr_white_level of struct dc_cursor_attributes was not
initialized, then the random value result that
dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal
value is 0x3c00), this
From: Alex Deucher
[ Upstream commit e7ad88553aa1d48e950ca9a4934d246c1bee4be4 ]
Picasso is a new raven variant.
Reviewed-by: Kent Russell
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git
From: wentalou
[ Upstream commit 1712fb1a2f6829150032ac76eb0e39b82a549cfb ]
amdgpu_bo_restore_shadow would assign zero to r if succeeded.
r would remain zero if there is only one node in shadow_list.
current code would always return failure when r <= 0.
restart the timeout for each wait was a
From: shaoyunl
[ Upstream commit d4162c61e253177936fcfe6c29f7b224d9a1efb8 ]
On XGMI configuration the ib test may take longer to finish
Signed-off-by: shaoyunl
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c |
From: tiancyin
[ Upstream commit c1cefe115d1cdc460014483319d440b2f0d07c68 ]
[Why]
the member sdr_white_level of struct dc_cursor_attributes was not
initialized, then the random value result that
dcn10_set_cursor_sdr_white_level() set error hw_scale value 0x20D9(normal
value is 0x3c00), this
From: Alex Deucher
[ Upstream commit e7ad88553aa1d48e950ca9a4934d246c1bee4be4 ]
Picasso is a new raven variant.
Reviewed-by: Kent Russell
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Fri, Apr 26, 2019 at 7:12 PM Kazlauskas, Nicholas
wrote:
>
> On 4/26/19 6:50 AM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some testing on DCE-8
> > and DCE-11,
Use a 2 msecs switching headroom not only for slightly
delayed exiting of BTR mode, but now also for entering
it a bit before the max frame duration is exceeded.
With slowly changing time delay between successive flips
or with a bit of jitter in arrival of flips, this adapts
vblank early and
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
Pre-DCE12 needs special treatment for BTR / low framerate
compensation for more stable behaviour:
According to comments in the code and some testing on DCE-8
and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
programming with a lag of one frame, so the special BTR hw
programming for
Same as rev 2, except for patch 3/3 v3 to apply Nicholas
latest feedback into account. Retested on DCN1 and DCE8.
thanks,
-mario
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
The main reasoning and use case for sysfs would be the SMI CLI, since
unfortunately there is no ioctl support in there.
Kent
KENT RUSSELL
Sr. Software Engineer | Linux Compute Kernel
1 Commerce Valley Drive East
Markham, ON L3T 7X6
O +(1) 289-695-2122 | Ext 72122
Reviewed-by: David Francis
From: amd-gfx on behalf of Deucher,
Alexander
Sent: April 23, 2019 10:47:26 AM
To: Kazlauskas, Nicholas; amd-gfx@lists.freedesktop.org
Cc: Li, Sun peng (Leo); Wentland, Harry
Subject: Re: [PATCH] drm/amd/display: Expose
On 4/26/19 6:50 AM, Mario Kleiner wrote:
> Pre-DCE12 needs special treatment for BTR / low framerate
> compensation for more stable behaviour:
>
> According to comments in the code and some testing on DCE-8
> and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
> programming with a lag of one
On Mon, Apr 01, 2019 at 06:44:34PM +0200, Andrey Konovalov wrote:
> On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas
> wrote:
> > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > @@ -2120,13 +2135,14 @@ static int prctl_set_mm(int opt, unsigned long
> > > addr,
> > >
On Thu, Apr 25, 2019 at 11:25 PM Johannes Berg
wrote:
> On Thu, 2019-04-25 at 17:55 +0200, Arnd Bergmann wrote:
> > On Thu, Apr 25, 2019 at 5:35 PM Al Viro wrote:
> > >
> > > On Thu, Apr 25, 2019 at 12:21:53PM -0300, Mauro Carvalho Chehab wrote:
> > >
> > > > If I understand your patch
We also expose the firmware versions via ioctl which is what the UMDs uses. If
you'd prefer it in sysfs, we could do that too.
Alex
From: amd-gfx on behalf of Lin, Amber
Sent: Friday, April 26, 2019 10:14 AM
To: amd-gfx@lists.freedesktop.org
Cc: Freehill,
On Fri, Apr 26, 2019 at 12:56:48PM +1000, Dave Airlie wrote:
> Daniel, drm-misc-next-fixes?
Makes sense. Pushed.
Cheers, Daniel
>
> Dave.
>
> On Fri, 26 Apr 2019 at 12:25, wrote:
> >
> > Hi Dave,
> >
> > > -Original Message-
> > > From: Dave Airlie [mailto:airl...@gmail.com]
> > >
How about an interface to change the timeout on a per engine (gfx, compute,
dma, etc.) basis?
amdgpu.lockup_timeout=,
if only one parameter is given, we change it globably. If more are given, we
override the global one. Could also do a sysfs interface to change it on the
fly.
Alex
Hi Alex,
Currently we retrieve firmware versions from /sys/kernel/debug but this
requires debugfs being enabled and superuser privilege. Do you see a
concern we add firmware versions to amdgpu sysfs at
/sys/class/drm/cardX/device like vbios_version?
Regards,
Amber
Ping (mostly David and Monk).
Andrey
On 4/24/19 3:09 AM, Christian König wrote:
Am 24.04.19 um 05:02 schrieb Zhou, David(ChunMing):
>> -drm_sched_stop(>sched, >base);
>> -
>> /* after all hw jobs are reset, hw fence is meaningless, so
>> force_completion */
>>
On Wed, Apr 24, 2019 at 09:16:10PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Joerg Roedel
> ---
> drivers/iommu/intel-iommu.c | 2 +-
> drivers/iommu/intel_irq_remapping.c | 2 +-
> 2 files
On Wed, Apr 24, 2019 at 09:15:25PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Joerg Roedel
> ---
> drivers/iommu/amd_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Pre-DCE12 needs special treatment for BTR / low framerate
compensation for more stable behaviour:
According to comments in the code and some testing on DCE-8
and DCE-11, DCE-11 and earlier only apply VTOTAL_MIN/MAX
programming with a lag of one frame, so the special BTR hw
programming for
Use a 2 msecs switching headroom not only for slightly
delayed exiting of BTR mode, but now also for entering
it a bit before the max frame duration is exceeded.
With slowly changing time delay between successive flips
or with a bit of jitter in arrival of flips, this adapts
vblank early and
The comparison of inserted_frame_duration_in_us against a
duration calculated from max_refresh_in_uhz is both wrong
in its math and not needed, as the min_duration_in_us value
is already cached in in_out_vrr for reuse. No need to
recalculate it wrongly at each invocation.
Signed-off-by: Mario
Updated series. The debug patch is dropped, a r-b by Nicholas is tacked
onto patch 1/3 and patch 3/3 has the locking fix that Nicholas proposed.
In terms of testing 3/3 didn't change anything for the better or worse,
observed behaviour on retested DCN-1 and DCE-8 is the same.
Patch 2/3 is
On Wed, Apr 24, 2019 at 4:34 PM Kazlauskas, Nicholas
wrote:
>
> On 4/17/19 11:51 PM, Mario Kleiner wrote:
> > Pre-DCE12 needs special treatment for BTR / low framerate
> > compensation for more stable behaviour:
> >
> > According to comments in the code and some testing on DCE-8
> > and DCE-11,
On 2019-04-26 10:20 a.m., Quan, Evan wrote:
> My concern is there is already one module parameter "lockup_timeout".
> parm: lockup_timeout:GPU lockup timeout in ms > 0 (default 1)
> (int)
>
> Adding one more "timeout" seems redundant.
> And that will makes the description of
Am 26.04.19 um 10:20 schrieb Quan, Evan:
My concern is there is already one module parameter "lockup_timeout".
parm: lockup_timeout:GPU lockup timeout in ms > 0 (default 1)
(int)
Adding one more "timeout" seems redundant.
And that will makes the description of
My concern is there is already one module parameter "lockup_timeout".
parm: lockup_timeout:GPU lockup timeout in ms > 0 (default 1)
(int)
Adding one more "timeout" seems redundant.
And that will makes the description of "lockup_timeout"(seems working for all
jobs) does not match
Am 26.04.19 um 09:24 schrieb Evan Quan:
A new module parameter is added for determining
whether or not to enforce timeout on compute jobs.
Can we rework that a bit and instead of a bool have a separate
millisecond timeout for compute?
E.g. default is 0 and that means MAX_SCHEDULE_TIMEOUT
A new module parameter is added for determining
whether or not to enforce timeout on compute jobs.
Change-Id: If14b75977312e42dac0431072456e5b69cf1bc2f
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 8
Hi Dave,
> -Original Message-
> From: Dave Airlie [mailto:airl...@gmail.com]
> Sent: Friday, April 26, 2019 11:19 AM
> To: Yamada, Masahiro/山田 真弘
> Cc: David Airlie ; Daniel Vetter ;
> dri-devel ; nouveau
> ; Sam Ravnborg ; David
> (ChunMing) Zhou ; amd-gfx mailing list
> ; James (Qian)
On 25/04/2019 05:14, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Alexey Kardashevskiy
> ---
> arch/powerpc/platforms/powernv/npu-dma.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
Hi.
On Fri, Mar 29, 2019 at 8:37 PM Masahiro Yamada
wrote:
>
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
>
36 matches
Mail list logo
