Great, can I get an rb or acked-by for the patch in this case?
Thanks,
Christian.
Am 10.10.2018 um 09:52 schrieb Liu, Monk:
> Thanks Sigil
>
> Hi Christian
>
> Looks we can enable/disable ctx-switch for SDMA at will, no dependency or
> conflict on SRIOV
>
> /Monk
>
> -Original Message-
Am 12.10.2018 um 16:41 schrieb Rex Zhu:
Signed-off-by: Rex Zhu
Good catch, but we need a commit message.
With that added the patch is Reviewed-by: Christian König
.
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
These patches are part of a proposed new interface for supporting variable
refresh rate via DRM properties.
=== Changes from v4 ===
amd changes:
* Removed unused FreeSync functions from amdgpu
=== Changes from v3 ===
drm changes:
* Docstring and formatting fixes
amd/display changes:
*
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces the "vrr_capable" property on the connector to
allow userspace to query support for variable refresh rates.
Atomic drivers should attach this property to connectors that are
capable of driving variable
Support for AMDGPU specific FreeSync properties and ioctls are dropped
from amdgpu_dm in favor of supporting drm variable refresh rate
properties.
The notify_freesync and set_freesync_property functions are dropped
from amdgpu_display_funcs.
The drm vrr_capable property is now attached to any
This patch introduces the 'vrr_enabled' CRTC property to allow
dynamic control over variable refresh rate support for a CRTC.
This property should be treated like a content hint to the driver -
if the hardware or driver is not capable of driving variable refresh
timings then this is not
These include the drm_connector 'vrr_capable' and the drm_crtc
'vrr_enabled' properties.
Signed-off-by: Nicholas Kazlauskas
---
Documentation/gpu/drm-kms.rst | 7 +++
drivers/gpu/drm/drm_connector.c | 22 ++
2 files changed, 29 insertions(+)
diff --git
This and the r420 patch applied. Thanks!
Alex
On Fri, Oct 12, 2018 at 1:11 PM Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case, I replaced "Pass through." with
>
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
index 3a072a7..df9b173 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c
On 2018-10-11 12:09 a.m., Bhawanpreet Lakha wrote:
> From: David Francis
>
> [Why]
> A quick-and-dirty way of getting performance data for the amdgpu
> driver would make performance improvements easier
>
> [How]
> The PERF_TRACE functionality is a tic-toc style debug method.
> Put PERF_TRACE
On 10/12/18 7:29 PM, Alex Deucher wrote:
> This and the r420 patch applied. Thanks!
>
Thanks, Alex. :)
--
Gustavo
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
From: hersen wu
[WHY] dp debugfs file does not exist for eDP under
/sys/kernel/debug/dri/0/eDP-1. the root is phy debugfs
is created for dp connector only.
[HOW] for eDP connector, create phy debugfs too.
Signed-off-by: Hersen Wu
Reviewed-by: David Francis
Acked-by: Leo Li
---
On 2018-10-12 10:50 a.m., sunpeng...@amd.com wrote:
> From: hersen wu
>
> [WHY] dp debugfs file does not exist for eDP under
> /sys/kernel/debug/dri/0/eDP-1. the root is phy debugfs
> is created for dp connector only.
> [HOW] for eDP connector, create phy debugfs too.
>
>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1357317 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/radeon/r420.c | 1 +
1 file changed, 1 insertion(+)
diff --git
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that in this particular case, I replaced "Pass through." with
"Fall through.", which is what GCC is expecting to find.
Addresses-Coverity-ID: 114734 ("Missing break in switch")
From: Leo Li
This fixes a general protection fault, caused by accessing the contents
of a flip_done completion object that has already been freed. It occurs
due to the preemption of a non-blocking commit worker thread W by
another commit thread X. X continues to clear its atomic state at the
>-Original Message-
>From: Christian König
>Sent: Friday, October 12, 2018 3:40 PM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu/sriov: Set the default value about gds
>vmid0 size
>
>Am 12.10.2018 um 05:21 schrieb Emily Deng:
>> For sriov, when first
Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
>>> I'm curious to know whether this will/could work over PRIME
>> I don't see why this shouldn't work over PRIME as long as the
>> presenting GPU supports
On Fri, 12 Oct 2018 07:35:57 +
"Koenig, Christian" wrote:
> Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
> > On Wed, 10 Oct 2018 09:35:50 -0400
> > "Kazlauskas, Nicholas" wrote:
> >
> >> The patches I've put out target this use case mostly because of the
> >> benefit for a relatively
Am 12.10.2018 um 06:05 schrieb Huang, Ray:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Felix Kuehling
>> Sent: Friday, October 12, 2018 3:46 AM
>> To: Koenig, Christian ; Min, Frank
>> ; amd-gfx@lists.freedesktop.org
>> Subject: Re:
Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
> On Wed, 10 Oct 2018 09:35:50 -0400
> "Kazlauskas, Nicholas" wrote:
>
>> The patches I've put out target this use case mostly because of the
>> benefit for a relatively simple interface. VRR can and has been used in
>> more ways that this, however.
On 2018-10-11 9:44 p.m., Harry Wentland wrote:
> On 2018-10-03 04:25 AM, Mike Lothian wrote:
>>
>> I'm curious to know whether this will/could work over PRIME
>
> I don't see why this shouldn't work over PRIME as long as the
> presenting GPU supports the new variable refresh rate API, but I know
Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
> On Fri, 12 Oct 2018 07:35:57 +
> "Koenig, Christian" wrote:
>
>> Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
>>> On Wed, 10 Oct 2018 09:35:50 -0400
>>> "Kazlauskas, Nicholas" wrote:
>>>
The patches I've put out target this use case
On 10/12/2018 03:39 PM, Christian König wrote:
Am 12.10.2018 um 05:21 schrieb Emily Deng:
For sriov, when first run windows guest, then run linux guest, the gds
vmid0 size will be reset to 0 by windows guest. So if the value has been
reset to 0, then set the value to the default value in linux
On 10/12/2018 06:08 PM, Emily Deng wrote:
For sriov, when first run windows guest, then run linux guest, the gds
vmid0 size will be reset to 0 by windows guest. So if the value has been
reset to 0, then set the value to the default value in linux guest.
v2:
Fixed value instead of reading
Am 12.10.2018 um 12:11 schrieb Zhang, Jerry(Junwei):
On 10/12/2018 06:08 PM, Emily Deng wrote:
For sriov, when first run windows guest, then run linux guest, the gds
vmid0 size will be reset to 0 by windows guest. So if the value has been
reset to 0, then set the value to the default value in
On 10/12/2018 05:34 PM, Emily Deng wrote:
For sriov, when first run windows guest, then run linux guest, the gds
vmid0 size will be reset to 0 by windows guest. So if the value has been
reset to 0, then set the value to the default value in linux guest.
v2:
Fixed value instead of reading
For sriov, when first run windows guest, then run linux guest, the gds
vmid0 size will be reset to 0 by windows guest. So if the value has been
reset to 0, then set the value to the default value in linux guest.
v2:
Fixed value instead of reading mmGDS_VMID0_SIZE.
Signed-off-by: Emily Deng
---
For sriov, when first run windows guest, then run linux guest, the gds
vmid0 size will be reset to 0 by windows guest. So if the value has been
reset to 0, then set the value to the default value in linux guest.
v2:
Fixed value instead of reading mmGDS_VMID0_SIZE.
Signed-off-by: Emily Deng
---
On Wed, 10 Oct 2018 09:35:50 -0400
"Kazlauskas, Nicholas" wrote:
> The patches I've put out target this use case mostly because of the
> benefit for a relatively simple interface. VRR can and has been used in
> more ways that this, however.
>
> An example usecase that differs from this would
> -Original Message-
> From: amd-gfx On Behalf Of
> Koenig, Christian
> Sent: Friday, October 12, 2018 3:25 PM
> To: Huang, Ray ; Kuehling, Felix
> ; Min, Frank ; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 2/2] drm/amdgpu: skip vm entries checking while in sriov
> vf
>
>
Am 12.10.2018 um 09:31 schrieb Zhu, Rex:
>
>> -Original Message-
>> From: amd-gfx On Behalf Of
>> Koenig, Christian
>> Sent: Friday, October 12, 2018 3:25 PM
>> To: Huang, Ray ; Kuehling, Felix
>> ; Min, Frank ; amd-
>> g...@lists.freedesktop.org
>> Subject: Re: [PATCH 2/2] drm/amdgpu:
Am 12.10.2018 um 05:21 schrieb Emily Deng:
For sriov, when first run windows guest, then run linux guest, the gds
vmid0 size will be reset to 0 by windows guest. So if the value has been
reset to 0, then set the value to the default value in linux guest.
Can we just always use the fixed value
Ping! Adding a few people directly and more mailing lists.
Can I get an acked-by/rb for this? It's only a cleanup and not much
functional change.
Regards,
Christian.
Am 04.10.2018 um 15:12 schrieb Christian König:
No need for that any more. Just replace the list when there isn't enough
room
On 10/12/2018 07:20 AM, Koenig, Christian wrote:
Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
On Fri, 12 Oct 2018 07:35:57 +
"Koenig, Christian" wrote:
Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
On Wed, 10 Oct 2018 09:35:50 -0400
"Kazlauskas, Nicholas" wrote:
The patches
35 matches
Mail list logo