RE: [PATCH] drm/amdgpu/sriov: Set the default value about gds vmid0 size

[Deng, Emily]

>-Original Message-
>From: Zhang, Jerry
>Sent: Friday, October 12, 2018 1:18 PM
>To: Deng, Emily ; amd-gfx@lists.freedesktop.org
>Subject: Re: [PATCH] drm/amdgpu/sriov: Set the default value about gds
>vmid0 size
>
>On 10/12/2018 11:21 AM, 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.
>>
>> Signed-off-by: Emily Deng 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 14 ++
>>   1 file changed, 14 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> index ae86238..d9df3dd 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
>> @@ -4872,6 +4872,17 @@ static void gfx_v9_0_set_rlc_funcs(struct
>amdgpu_device *adev)
>>  }
>>   }
>>
>> +static void gfx_v9_0_set_gds_default(struct amdgpu_device *adev) {
>> +switch (adev->asic_type) {
>> +case CHIP_VEGA10:
>> +adev->gds.mem.total_size = 0x1;
>Do you mean this value is same as the original value from
>mmGDS_VMID0_SIZE before reset?
>if so, we may provide a default value for recovery, e.g. in the gds.mem
>structure.
Yes.
>Regards,
>Jerry
>> +break;
>> +default:
>> +break;
>> +}
>> +}
>> +
>>   static void gfx_v9_0_set_gds_init(struct amdgpu_device *adev)
>>   {
>>  /* init asci gds info */
>> @@ -4879,6 +4890,9 @@ static void gfx_v9_0_set_gds_init(struct
>amdgpu_device *adev)
>>  adev->gds.gws.total_size = 64;
>>  adev->gds.oa.total_size = 16;
>>
>> +if (adev->gds.mem.total_size == 0 && amdgpu_sriov_vf(adev))
>> +gfx_v9_0_set_gds_default(adev);
>> +
>>  if (adev->gds.mem.total_size == 64 * 1024) {
>>  adev->gds.mem.gfx_partition_size = 4096;
>>  adev->gds.mem.cs_partition_size = 4096;

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH] drm/amdgpu/sriov: Set the default value about gds vmid0 size

[Zhang, Jerry(Junwei)]

On 10/12/2018 11:21 AM, 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.

Signed-off-by: Emily Deng 
---
  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index ae86238..d9df3dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4872,6 +4872,17 @@ static void gfx_v9_0_set_rlc_funcs(struct amdgpu_device 
*adev)
}
  }
  
+static void gfx_v9_0_set_gds_default(struct amdgpu_device *adev)

+{
+   switch (adev->asic_type) {
+   case CHIP_VEGA10:
+   adev->gds.mem.total_size = 0x1;
Do you mean this value is same as the original value from 
mmGDS_VMID0_SIZE before reset?
if so, we may provide a default value for recovery, e.g. in the gds.mem 
structure.


Regards,
Jerry

+   break;
+   default:
+   break;
+   }
+}
+
  static void gfx_v9_0_set_gds_init(struct amdgpu_device *adev)
  {
/* init asci gds info */
@@ -4879,6 +4890,9 @@ static void gfx_v9_0_set_gds_init(struct amdgpu_device 
*adev)
adev->gds.gws.total_size = 64;
adev->gds.oa.total_size = 16;
  
+	if (adev->gds.mem.total_size == 0 && amdgpu_sriov_vf(adev))

+   gfx_v9_0_set_gds_default(adev);
+
if (adev->gds.mem.total_size == 64 * 1024) {
adev->gds.mem.gfx_partition_size = 4096;
adev->gds.mem.cs_partition_size = 4096;


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 1/2] drm/amdgpu: fix sdma doorbell comments typo

[Huang, Ray]

> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Frank.Min
> Sent: Thursday, October 11, 2018 8:08 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Min, Frank 
> Subject: [PATCH 1/2] drm/amdgpu: fix sdma doorbell comments typo
> 
> Change-Id: I0a3dff9f01a90717e0c32b7fa81a5e891bd1d52d
> Signed-off-by: Frank.Min 

Reviewed-by: Huang Rui 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index c21d9b9..6317f35 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -432,7 +432,7 @@ typedef enum
> _AMDGPU_DOORBELL64_ASSIGNMENT
>* default non-graphics QWORD index is 0xe0 - 0xFF inclusive
>*/
> 
> - /* sDMA engines  reserved from 0xe0 -oxef  */
> + /* sDMA engines  reserved from 0xe0 -0xef  */
>   AMDGPU_DOORBELL64_sDMA_ENGINE0= 0xE0,
>   AMDGPU_DOORBELL64_sDMA_HI_PRI_ENGINE0 = 0xE1,
>   AMDGPU_DOORBELL64_sDMA_ENGINE1= 0xE8,
> --
> 2.7.4
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH 2/2] drm/amdgpu: skip vm entries checking while in sriov vf

[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: [PATCH 2/2] drm/amdgpu: skip vm entries checking while in
> sriov vf
> 
> On 2018-10-11 08:32 AM, Christian König wrote:
> > Am 11.10.2018 um 14:09 schrieb Frank.Min:
> >> vm page table would be allocated while in amdgpu_vm_init by
> >> amdgpu_allocate_static_csa for sriov, so the checking here would be
> >> skipped.
> >
> > NAK, that checking is actually correct and points out that this
> > doesn't work correctly.
> >
> > Fix the function to be able to handle the case when there are already
> > mappings in the VM.
> 
> KFD and the Thunk assume that they own the entire address space. If
> something is already mapped, KFD and the Thunk would not be aware of it.
> 
> amdgpu_allocate_static_csa runs during driver initialization, before there are
> any VMs. Looks like amdgpu_map_static_csa is the more important function
> here, which currently runs in amdgpu_driver_open_kms.
> 
> Could amdgpu_map_static_csa be delayed to the first time user mode maps
> memory into the VM through GEM APIs? That way it would allow turning a
> VM into a compute VM that hasn't been used for any GEM memory
> mappings.
>

Yes. Frank and I found, while we do acquire_process_vm(), the vm->va RB trees 
are always not empty under SRIOV, because amdgpu_map_static_csa() will be 
called while vm inits under SRIOV, that will actually map the CSA BO to the VM 
and insert the node into vm->va before it acquires process VM in KFD. 
 
Thanks,
Ray

> Regards,
>   Felix
> 
> >
> > Christian.
> >
> >>
> >> Change-Id: Id30b86ad15ae509aeed9ed8ab60c259c88af3df5
> >> Signed-off-by: Frank.Min 
> >> ---
> >>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 9 +
> >>   1 file changed, 5 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> index 6904d79..6066f87 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >> @@ -3100,11 +3100,12 @@ int amdgpu_vm_make_compute(struct
> >> amdgpu_device *adev, struct amdgpu_vm *vm, uns
> >>   return r;
> >>     /* Sanity checks */
> >> -    if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
> >> -    r = -EINVAL;
> >> -    goto unreserve_bo;
> >> +    if (!amdgpu_sriov_vf(adev)) {
> >> +    if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
> >> +    r = -EINVAL;
> >> +    goto unreserve_bo;
> >> +    }
> >>   }
> >> -
> >>   if (pasid) {
> >>   unsigned long flags;
> >>
> >
> > ___
> > amd-gfx mailing list
> > amd-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH] drm/amdgpu/sriov: Set the default value about gds vmid0 size

[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.

Signed-off-by: Emily Deng 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index ae86238..d9df3dd 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
@@ -4872,6 +4872,17 @@ static void gfx_v9_0_set_rlc_funcs(struct amdgpu_device 
*adev)
}
 }
 
+static void gfx_v9_0_set_gds_default(struct amdgpu_device *adev)
+{
+   switch (adev->asic_type) {
+   case CHIP_VEGA10:
+   adev->gds.mem.total_size = 0x1;
+   break;
+   default:
+   break;
+   }
+}
+
 static void gfx_v9_0_set_gds_init(struct amdgpu_device *adev)
 {
/* init asci gds info */
@@ -4879,6 +4890,9 @@ static void gfx_v9_0_set_gds_init(struct amdgpu_device 
*adev)
adev->gds.gws.total_size = 64;
adev->gds.oa.total_size = 16;
 
+   if (adev->gds.mem.total_size == 0 && amdgpu_sriov_vf(adev))
+   gfx_v9_0_set_gds_default(adev);
+
if (adev->gds.mem.total_size == 64 * 1024) {
adev->gds.mem.gfx_partition_size = 4096;
adev->gds.mem.cs_partition_size = 4096;
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v4 4/4] drm/amd/display: Set FreeSync state using drm VRR properties

[Harry Wentland]

On 2018-10-11 04:56 PM, Kazlauskas, Nicholas wrote:
> On 10/11/2018 04:39 PM, Harry Wentland wrote:
>> On 2018-10-11 12:39 PM, Nicholas Kazlauskas wrote:
>>> Support for AMDGPU specific FreeSync properties and ioctls are dropped
>>> from amdgpu_dm in favor of supporting drm variable refresh rate
>>> properties.
>>>
>>> The drm vrr_capable property is now attached to any DP/HDMI connector.
>>> Its value is updated accordingly to the connector's FreeSync capabiltiy.
>>>
>>> The freesync_enable logic and ioctl control has has been dropped in
>>> favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
>>> fine grained atomic control over which CRTCs should support variable
>>> refresh rate.
>>>
>>> To handle state changes for vrr_enabled it was easiest to drop the
>>> forced modeset on freesync_enabled change. This patch now performs the
>>> required stream updates when planes are flipped.
>>>
>>> This is done for a few reasons:
>>>
>>> (1) VRR stream updates can be done in the fast update path
>>>
>>> (2) amdgpu_dm_atomic_check would need to be hacked apart to check
>>>  desired variable refresh state and capability before the CRTC
>>>  disable pass.
>>>
>>> (3) Performing VRR stream updates on-flip is needed for enabling BTR
>>>  support.
>>>
>>> VRR packets and timing adjustments are now tracked and compared to
>>> previous values sent to the hardware.
>>>
>>> Signed-off-by: Nicholas Kazlauskas 
>>> ---
>>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
>>>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +-
>>>   2 files changed, 138 insertions(+), 124 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> index 6a2342d72742..d5de4b91e144 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device 
>>> *adev)
>>>   /* TODO: implement later */
>>>   }
>>>   -static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
>>> -    struct drm_file *filp)
>>> -{
>>> -    struct drm_atomic_state *state;
>>> -    struct drm_modeset_acquire_ctx ctx;
>>> -    struct drm_crtc *crtc;
>>> -    struct drm_connector *connector;
>>> -    struct drm_connector_state *old_con_state, *new_con_state;
>>> -    int ret = 0;
>>> -    uint8_t i;
>>> -    bool enable = false;
>>> -
>>> -    drm_modeset_acquire_init(, 0);
>>> -
>>> -    state = drm_atomic_state_alloc(dev);
>>> -    if (!state) {
>>> -    ret = -ENOMEM;
>>> -    goto out;
>>> -    }
>>> -    state->acquire_ctx = 
>>> -
>>> -retry:
>>> -    drm_for_each_crtc(crtc, dev) {
>>> -    ret = drm_atomic_add_affected_connectors(state, crtc);
>>> -    if (ret)
>>> -    goto fail;
>>> -
>>> -    /* TODO rework amdgpu_dm_commit_planes so we don't need this */
>>> -    ret = drm_atomic_add_affected_planes(state, crtc);
>>> -    if (ret)
>>> -    goto fail;
>>> -    }
>>> -
>>> -    for_each_oldnew_connector_in_state(state, connector, old_con_state, 
>>> new_con_state, i) {
>>> -    struct dm_connector_state *dm_new_con_state = 
>>> to_dm_connector_state(new_con_state);
>>> -    struct drm_crtc_state *new_crtc_state;
>>> -    struct amdgpu_crtc *acrtc = 
>>> to_amdgpu_crtc(dm_new_con_state->base.crtc);
>>> -    struct dm_crtc_state *dm_new_crtc_state;
>>> -
>>> -    if (!acrtc) {
>>> -    ASSERT(0);
>>> -    continue;
>>> -    }
>>> -
>>> -    new_crtc_state = drm_atomic_get_new_crtc_state(state, 
>>> >base);
>>> -    dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
>>> -
>>> -    dm_new_crtc_state->freesync_enabled = enable;
>>> -    }
>>> -
>>> -    ret = drm_atomic_commit(state);
>>> -
>>> -fail:
>>> -    if (ret == -EDEADLK) {
>>> -    drm_atomic_state_clear(state);
>>> -    drm_modeset_backoff();
>>> -    goto retry;
>>> -    }
>>> -
>>> -    drm_atomic_state_put(state);
>>> -
>>> -out:
>>> -    drm_modeset_drop_locks();
>>> -    drm_modeset_acquire_fini();
>>> -    return ret;
>>> -}
>>>     static const struct amdgpu_display_funcs dm_display_funcs = {
>>>   .bandwidth_update = dm_bandwidth_update, /* called unconditionally */
>>> @@ -1881,7 +1815,6 @@ static const struct amdgpu_display_funcs 
>>> dm_display_funcs = {
>>>   dm_crtc_get_scanoutpos,/* called unconditionally */
>>>   .add_encoder = NULL, /* VBIOS parsing. DAL does it. */
>>>   .add_connector = NULL, /* VBIOS parsing. DAL does it. */
>>> -    .notify_freesync = amdgpu_notify_freesync,
>>
>> Please also drop from amdgpu_display_funcs definition in amdgpu_mode.h. 
>> Might want to drop the set_freesync_property from there as well.
> 
> Oh right, I forgot about those. Will do.
> 
>>
>>>     };
>>>   @@ -2834,7 +2767,8 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)

Re: [PATCH v4 4/4] drm/amd/display: Set FreeSync state using drm VRR properties

[Kazlauskas, Nicholas]

On 10/11/2018 04:39 PM, Harry Wentland wrote:

On 2018-10-11 12:39 PM, Nicholas Kazlauskas wrote:

Support for AMDGPU specific FreeSync properties and ioctls are dropped
from amdgpu_dm in favor of supporting drm variable refresh rate
properties.

The drm vrr_capable property is now attached to any DP/HDMI connector.
Its value is updated accordingly to the connector's FreeSync capabiltiy.

The freesync_enable logic and ioctl control has has been dropped in
favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
fine grained atomic control over which CRTCs should support variable
refresh rate.

To handle state changes for vrr_enabled it was easiest to drop the
forced modeset on freesync_enabled change. This patch now performs the
required stream updates when planes are flipped.

This is done for a few reasons:

(1) VRR stream updates can be done in the fast update path

(2) amdgpu_dm_atomic_check would need to be hacked apart to check
 desired variable refresh state and capability before the CRTC
 disable pass.

(3) Performing VRR stream updates on-flip is needed for enabling BTR
 support.

VRR packets and timing adjustments are now tracked and compared to
previous values sent to the hardware.

Signed-off-by: Nicholas Kazlauskas 
---
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +-
  2 files changed, 138 insertions(+), 124 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6a2342d72742..d5de4b91e144 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device 
*adev)
/* TODO: implement later */
  }
  
-static int amdgpu_notify_freesync(struct drm_device *dev, void *data,

-   struct drm_file *filp)
-{
-   struct drm_atomic_state *state;
-   struct drm_modeset_acquire_ctx ctx;
-   struct drm_crtc *crtc;
-   struct drm_connector *connector;
-   struct drm_connector_state *old_con_state, *new_con_state;
-   int ret = 0;
-   uint8_t i;
-   bool enable = false;
-
-   drm_modeset_acquire_init(, 0);
-
-   state = drm_atomic_state_alloc(dev);
-   if (!state) {
-   ret = -ENOMEM;
-   goto out;
-   }
-   state->acquire_ctx = 
-
-retry:
-   drm_for_each_crtc(crtc, dev) {
-   ret = drm_atomic_add_affected_connectors(state, crtc);
-   if (ret)
-   goto fail;
-
-   /* TODO rework amdgpu_dm_commit_planes so we don't need this */
-   ret = drm_atomic_add_affected_planes(state, crtc);
-   if (ret)
-   goto fail;
-   }
-
-   for_each_oldnew_connector_in_state(state, connector, old_con_state, 
new_con_state, i) {
-   struct dm_connector_state *dm_new_con_state = 
to_dm_connector_state(new_con_state);
-   struct drm_crtc_state *new_crtc_state;
-   struct amdgpu_crtc *acrtc = 
to_amdgpu_crtc(dm_new_con_state->base.crtc);
-   struct dm_crtc_state *dm_new_crtc_state;
-
-   if (!acrtc) {
-   ASSERT(0);
-   continue;
-   }
-
-   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
>base);
-   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
-
-   dm_new_crtc_state->freesync_enabled = enable;
-   }
-
-   ret = drm_atomic_commit(state);
-
-fail:
-   if (ret == -EDEADLK) {
-   drm_atomic_state_clear(state);
-   drm_modeset_backoff();
-   goto retry;
-   }
-
-   drm_atomic_state_put(state);
-
-out:
-   drm_modeset_drop_locks();
-   drm_modeset_acquire_fini();
-   return ret;
-}
  
  static const struct amdgpu_display_funcs dm_display_funcs = {

.bandwidth_update = dm_bandwidth_update, /* called unconditionally */
@@ -1881,7 +1815,6 @@ static const struct amdgpu_display_funcs dm_display_funcs 
= {
dm_crtc_get_scanoutpos,/* called unconditionally */
.add_encoder = NULL, /* VBIOS parsing. DAL does it. */
.add_connector = NULL, /* VBIOS parsing. DAL does it. */
-   .notify_freesync = amdgpu_notify_freesync,


Please also drop from amdgpu_display_funcs definition in amdgpu_mode.h. Might 
want to drop the set_freesync_property from there as well.


Oh right, I forgot about those. Will do.



  
  };
  
@@ -2834,7 +2767,8 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
  
  	state->adjust = cur->adjust;

state->vrr_infopacket = cur->vrr_infopacket;
-   state->freesync_enabled = cur->freesync_enabled;
+   state->vrr_supported = cur->vrr_supported;
+   state->freesync_config = cur->freesync_config;
  
  	/* TODO 

Re: [PATCH v4 4/4] drm/amd/display: Set FreeSync state using drm VRR properties

[Harry Wentland]

On 2018-10-11 12:39 PM, Nicholas Kazlauskas wrote:
> Support for AMDGPU specific FreeSync properties and ioctls are dropped
> from amdgpu_dm in favor of supporting drm variable refresh rate
> properties.
> 
> The drm vrr_capable property is now attached to any DP/HDMI connector.
> Its value is updated accordingly to the connector's FreeSync capabiltiy.
> 
> The freesync_enable logic and ioctl control has has been dropped in
> favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
> fine grained atomic control over which CRTCs should support variable
> refresh rate.
> 
> To handle state changes for vrr_enabled it was easiest to drop the
> forced modeset on freesync_enabled change. This patch now performs the
> required stream updates when planes are flipped.
> 
> This is done for a few reasons:
> 
> (1) VRR stream updates can be done in the fast update path
> 
> (2) amdgpu_dm_atomic_check would need to be hacked apart to check
> desired variable refresh state and capability before the CRTC
> disable pass.
> 
> (3) Performing VRR stream updates on-flip is needed for enabling BTR
> support.
> 
> VRR packets and timing adjustments are now tracked and compared to
> previous values sent to the hardware.
> 
> Signed-off-by: Nicholas Kazlauskas 
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +-
>  2 files changed, 138 insertions(+), 124 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 6a2342d72742..d5de4b91e144 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device 
> *adev)
>   /* TODO: implement later */
>  }
>  
> -static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
> - struct drm_file *filp)
> -{
> - struct drm_atomic_state *state;
> - struct drm_modeset_acquire_ctx ctx;
> - struct drm_crtc *crtc;
> - struct drm_connector *connector;
> - struct drm_connector_state *old_con_state, *new_con_state;
> - int ret = 0;
> - uint8_t i;
> - bool enable = false;
> -
> - drm_modeset_acquire_init(, 0);
> -
> - state = drm_atomic_state_alloc(dev);
> - if (!state) {
> - ret = -ENOMEM;
> - goto out;
> - }
> - state->acquire_ctx = 
> -
> -retry:
> - drm_for_each_crtc(crtc, dev) {
> - ret = drm_atomic_add_affected_connectors(state, crtc);
> - if (ret)
> - goto fail;
> -
> - /* TODO rework amdgpu_dm_commit_planes so we don't need this */
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - goto fail;
> - }
> -
> - for_each_oldnew_connector_in_state(state, connector, old_con_state, 
> new_con_state, i) {
> - struct dm_connector_state *dm_new_con_state = 
> to_dm_connector_state(new_con_state);
> - struct drm_crtc_state *new_crtc_state;
> - struct amdgpu_crtc *acrtc = 
> to_amdgpu_crtc(dm_new_con_state->base.crtc);
> - struct dm_crtc_state *dm_new_crtc_state;
> -
> - if (!acrtc) {
> - ASSERT(0);
> - continue;
> - }
> -
> - new_crtc_state = drm_atomic_get_new_crtc_state(state, 
> >base);
> - dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
> -
> - dm_new_crtc_state->freesync_enabled = enable;
> - }
> -
> - ret = drm_atomic_commit(state);
> -
> -fail:
> - if (ret == -EDEADLK) {
> - drm_atomic_state_clear(state);
> - drm_modeset_backoff();
> - goto retry;
> - }
> -
> - drm_atomic_state_put(state);
> -
> -out:
> - drm_modeset_drop_locks();
> - drm_modeset_acquire_fini();
> - return ret;
> -}
>  
>  static const struct amdgpu_display_funcs dm_display_funcs = {
>   .bandwidth_update = dm_bandwidth_update, /* called unconditionally */
> @@ -1881,7 +1815,6 @@ static const struct amdgpu_display_funcs 
> dm_display_funcs = {
>   dm_crtc_get_scanoutpos,/* called unconditionally */
>   .add_encoder = NULL, /* VBIOS parsing. DAL does it. */
>   .add_connector = NULL, /* VBIOS parsing. DAL does it. */
> - .notify_freesync = amdgpu_notify_freesync,

Please also drop from amdgpu_display_funcs definition in amdgpu_mode.h. Might 
want to drop the set_freesync_property from there as well.

>  
>  };
>  
> @@ -2834,7 +2767,8 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
>  
>   state->adjust = cur->adjust;
>   state->vrr_infopacket = cur->vrr_infopacket;
> - state->freesync_enabled = cur->freesync_enabled;
> + state->vrr_supported = cur->vrr_supported;
> + 

Re: [PATCH 2/2] drm/amdgpu: skip vm entries checking while in sriov vf

[Felix Kuehling]

On 2018-10-11 08:32 AM, Christian König wrote:
> Am 11.10.2018 um 14:09 schrieb Frank.Min:
>> vm page table would be allocated while in amdgpu_vm_init
>> by amdgpu_allocate_static_csa for sriov, so the checking
>> here would be skipped.
>
> NAK, that checking is actually correct and points out that this
> doesn't work correctly.
>
> Fix the function to be able to handle the case when there are already
> mappings in the VM.

KFD and the Thunk assume that they own the entire address space. If
something is already mapped, KFD and the Thunk would not be aware of it.

amdgpu_allocate_static_csa runs during driver initialization, before
there are any VMs. Looks like amdgpu_map_static_csa is the more
important function here, which currently runs in amdgpu_driver_open_kms.

Could amdgpu_map_static_csa be delayed to the first time user mode maps
memory into the VM through GEM APIs? That way it would allow turning a
VM into a compute VM that hasn't been used for any GEM memory mappings.

Regards,
  Felix

>
> Christian.
>
>>
>> Change-Id: Id30b86ad15ae509aeed9ed8ab60c259c88af3df5
>> Signed-off-by: Frank.Min 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 9 +
>>   1 file changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> index 6904d79..6066f87 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
>> @@ -3100,11 +3100,12 @@ int amdgpu_vm_make_compute(struct
>> amdgpu_device *adev, struct amdgpu_vm *vm, uns
>>   return r;
>>     /* Sanity checks */
>> -    if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
>> -    r = -EINVAL;
>> -    goto unreserve_bo;
>> +    if (!amdgpu_sriov_vf(adev)) {
>> +    if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
>> +    r = -EINVAL;
>> +    goto unreserve_bo;
>> +    }
>>   }
>> -
>>   if (pasid) {
>>   unsigned long flags;
>>   
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support

[Harry Wentland]

On 2018-10-03 04:25 AM, Mike Lothian wrote:
> Hi
> 
> 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 very little about prime, 
so maybe someone else can chime in and give a better opinion.

Harry

> If the discrete card is rendering slower than the display's frequency could 
> the frequency be dropped on integrated display? I think there are laptops 
> that have freesync now
> 
> Cheers
> 
> Mike
> 
> On Mon, 1 Oct 2018 at 08:15 Daniel Vetter  > wrote:
> 
> On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote:
> > These patches are part of a proposed new interface for supporting 
> variable refresh rate via DRM properties.
> >
> > === Changes from v1 ===
> >
> > For drm:
> >
> > * The variable_refresh_capable property is now flagged as 
> DRM_MODE_PROP_IMMUTABLE
> >
> > For drm/gpu/amd/display:
> >
> > * Patches no longer pull in IOCTL/FreeSync refactoring code
> > * FreeSync enable/disable behavior has been modified to reflect changes 
> in userspace behavior from xf86-video-amdgpu and mesa
> >
> > === Adaptive sync and variable refresh rate ===
> >
> > Adaptive sync is part of the DisplayPort spec and allows for graphics 
> adapters to drive displays with varying frame timings.
> >
> > Variable refresh rate (VRR) is essentially the same, but defined for 
> HDMI.
> >
> > === Use cases for variable refresh rate ===
> >
> > Variable frame (flip) timings don't align well with fixed refresh rate 
> displays. This results in stuttering, tearing and/or input lag. By adjusting 
> the display refresh rate dynamically these issues can be reduced or 
> eliminated.
> >
> > However, not all content is suitable for dynamic refresh adaptation. 
> Content that is flipped infrequently or at random intervals tends to fair 
> poorly. Multiple clients trying to flip under the same screen can similarly 
> interfere with prediction.
> >
> > Userland needs a way to let the driver know when the content on the 
> screen is suitable for variable refresh rate and if the user wishes to have 
> the feature enabled.
> >
> > === DRM API to support variable refresh rates ===
> >
> > This patch introduces a new API via atomic properties on the DRM 
> connector and CRTC.
> >
> > The connector has two new optional properties:
> >
> > * bool variable_refresh_capable - set by the driver if the hardware is 
> capable of supporting variable refresh tech
> >
> > * bool variable_refresh_enabled - set by the user to enable variable 
> refresh adjustment over the connector
> >
> > The CRTC has one additional default property:
> >
> > * bool variable_refresh - a content hint to the driver specifying that 
> the CRTC contents are suitable for variable refresh adjustment
> >
> > == Overview for DRM driver developers ===
> >
> > Driver developers can attach the optional connector properties via 
> drm_connector_attach_variable_refresh_properties on connectors that support 
> variable refresh (typically DP or HDMI).
> >
> > The variable_refresh_capable property should be managed as the output 
> on the connector changes. The property is read only from userspace.
> >
> > The variable_refresh_enabled property is intended to be a property 
> controlled by userland as a global on/off switch for variable refresh 
> technology. It should be checked before enabling variable refresh rate.
> >
> > === Overview for Userland developers ==
> >
> > The variable_refresh property on the CRTC should be set to true when 
> the CRTCs are suitable for variable refresh rate. In practice this is 
> probably an application like a game - a single window that covers the whole 
> CRTC surface and is the only client issuing flips.
> >
> > To demonstrate the suitability of the API for variable refresh and 
> dynamic adaptation there are additional patches using this API that implement 
> adaptive variable refresh across kernel and userland projects:
> >
> > * DRM (dri-devel)
> > * amdgpu DRM kernel driver (amd-gfx)
> > * xf86-video-amdgpu (amd-gfx)
> > * mesa (mesa-dev)
> >
> > These patches enable adaptive variable refresh on X for AMD hardware 
> provided that the user sets the variable_refresh_enabled property to true on 
> supported connectors (ie. using xrandr --set-prop).
> >
> > The patches have been tested as working on upstream userland with the 
> GNOME desktop environment under a single monitor setup. They also work on KDE 
> in single monitor setup if the compositor is disabled.
> >
> > The patches require that the application window can issue screen flips 
> via the Present extension to xf86-video-amdgpu. Due to Present 

Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support

[Harry Wentland]

On 2018-10-03 04:41 AM, Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote:
>>
>>
>> On 2018-10-01 03:15 AM, Daniel Vetter wrote:
>>> On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote:
 These patches are part of a proposed new interface for supporting variable 
 refresh rate via DRM properties.

 === Changes from v1 ===

 For drm:

 * The variable_refresh_capable property is now flagged as 
 DRM_MODE_PROP_IMMUTABLE

 For drm/gpu/amd/display:

 * Patches no longer pull in IOCTL/FreeSync refactoring code
 * FreeSync enable/disable behavior has been modified to reflect changes in 
 userspace behavior from xf86-video-amdgpu and mesa

 === Adaptive sync and variable refresh rate ===

 Adaptive sync is part of the DisplayPort spec and allows for graphics 
 adapters to drive displays with varying frame timings.

 Variable refresh rate (VRR) is essentially the same, but defined for HDMI.

 === Use cases for variable refresh rate ===

 Variable frame (flip) timings don't align well with fixed refresh rate 
 displays. This results in stuttering, tearing and/or input lag. By 
 adjusting the display refresh rate dynamically these issues can be reduced 
 or eliminated.

 However, not all content is suitable for dynamic refresh adaptation. 
 Content that is flipped infrequently or at random intervals tends to fair 
 poorly. Multiple clients trying to flip under the same screen can 
 similarly interfere with prediction.

 Userland needs a way to let the driver know when the content on the screen 
 is suitable for variable refresh rate and if the user wishes to have the 
 feature enabled.

 === DRM API to support variable refresh rates ===

 This patch introduces a new API via atomic properties on the DRM connector 
 and CRTC.

 The connector has two new optional properties:

 * bool variable_refresh_capable - set by the driver if the hardware is 
 capable of supporting variable refresh tech

 * bool variable_refresh_enabled - set by the user to enable variable 
 refresh adjustment over the connector

 The CRTC has one additional default property:

 * bool variable_refresh - a content hint to the driver specifying that the 
 CRTC contents are suitable for variable refresh adjustment

 == Overview for DRM driver developers ===

 Driver developers can attach the optional connector properties via 
 drm_connector_attach_variable_refresh_properties on connectors that 
 support variable refresh (typically DP or HDMI).

 The variable_refresh_capable property should be managed as the output on 
 the connector changes. The property is read only from userspace.

 The variable_refresh_enabled property is intended to be a property 
 controlled by userland as a global on/off switch for variable refresh 
 technology. It should be checked before enabling variable refresh rate.

 === Overview for Userland developers ==

 The variable_refresh property on the CRTC should be set to true when the 
 CRTCs are suitable for variable refresh rate. In practice this is probably 
 an application like a game - a single window that covers the whole CRTC 
 surface and is the only client issuing flips.

 To demonstrate the suitability of the API for variable refresh and dynamic 
 adaptation there are additional patches using this API that implement 
 adaptive variable refresh across kernel and userland projects:

 * DRM (dri-devel)
 * amdgpu DRM kernel driver (amd-gfx)
 * xf86-video-amdgpu (amd-gfx)
 * mesa (mesa-dev)

 These patches enable adaptive variable refresh on X for AMD hardware 
 provided that the user sets the variable_refresh_enabled property to true 
 on supported connectors (ie. using xrandr --set-prop).

 The patches have been tested as working on upstream userland with the 
 GNOME desktop environment under a single monitor setup. They also work on 
 KDE in single monitor setup if the compositor is disabled.

 The patches require that the application window can issue screen flips via 
 the Present extension to xf86-video-amdgpu. Due to Present extension 
 limitations some desktop environments and multi-monitor setups are 
 currently not compatible.

 Full implementation details for these changes can be reviewed in their 
 respective mailing lists.

 === Previous discussions ===

 These patches are based upon feedback from patches and feedback from two 
 previous threads on the subject which are linked below for reference:

 https://lists.freedesktop.org/archives/amd-gfx/2018-April/021047.html
 

Re: [PATCH v2 0/3] A DRM API for adaptive sync and variable refresh rate support

[Harry Wentland]

On 2018-10-03 02:35 PM, Manasi Navare wrote:
> On Wed, Oct 03, 2018 at 10:41:20AM +0200, Daniel Vetter wrote:
>> On Tue, Oct 02, 2018 at 10:49:17AM -0400, Harry Wentland wrote:
>>>
>>>
>>> On 2018-10-01 03:15 AM, Daniel Vetter wrote:
 On Mon, Sep 24, 2018 at 02:15:34PM -0400, Nicholas Kazlauskas wrote:
> These patches are part of a proposed new interface for supporting 
> variable refresh rate via DRM properties.
>
> === Changes from v1 ===
>
> For drm:
>
> * The variable_refresh_capable property is now flagged as 
> DRM_MODE_PROP_IMMUTABLE
>
> For drm/gpu/amd/display:
>
> * Patches no longer pull in IOCTL/FreeSync refactoring code
> * FreeSync enable/disable behavior has been modified to reflect changes 
> in userspace behavior from xf86-video-amdgpu and mesa
>
> === Adaptive sync and variable refresh rate ===
>
> Adaptive sync is part of the DisplayPort spec and allows for graphics 
> adapters to drive displays with varying frame timings.
>
> Variable refresh rate (VRR) is essentially the same, but defined for HDMI.
>
> === Use cases for variable refresh rate ===
>
> Variable frame (flip) timings don't align well with fixed refresh rate 
> displays. This results in stuttering, tearing and/or input lag. By 
> adjusting the display refresh rate dynamically these issues can be 
> reduced or eliminated.
>
> However, not all content is suitable for dynamic refresh adaptation. 
> Content that is flipped infrequently or at random intervals tends to fair 
> poorly. Multiple clients trying to flip under the same screen can 
> similarly interfere with prediction.
>
> Userland needs a way to let the driver know when the content on the 
> screen is suitable for variable refresh rate and if the user wishes to 
> have the feature enabled.
>
> === DRM API to support variable refresh rates ===
>
> This patch introduces a new API via atomic properties on the DRM 
> connector and CRTC.
>
> The connector has two new optional properties:
>
> * bool variable_refresh_capable - set by the driver if the hardware is 
> capable of supporting variable refresh tech
>
> * bool variable_refresh_enabled - set by the user to enable variable 
> refresh adjustment over the connector
>
> The CRTC has one additional default property:
>
> * bool variable_refresh - a content hint to the driver specifying that 
> the CRTC contents are suitable for variable refresh adjustment
>
> == Overview for DRM driver developers ===
>
> Driver developers can attach the optional connector properties via 
> drm_connector_attach_variable_refresh_properties on connectors that 
> support variable refresh (typically DP or HDMI).
>
> The variable_refresh_capable property should be managed as the output on 
> the connector changes. The property is read only from userspace.
>
> The variable_refresh_enabled property is intended to be a property 
> controlled by userland as a global on/off switch for variable refresh 
> technology. It should be checked before enabling variable refresh rate.
>
> === Overview for Userland developers ==
>
> The variable_refresh property on the CRTC should be set to true when the 
> CRTCs are suitable for variable refresh rate. In practice this is 
> probably an application like a game - a single window that covers the 
> whole CRTC surface and is the only client issuing flips.
>
> To demonstrate the suitability of the API for variable refresh and 
> dynamic adaptation there are additional patches using this API that 
> implement adaptive variable refresh across kernel and userland projects:
>
> * DRM (dri-devel)
> * amdgpu DRM kernel driver (amd-gfx)
> * xf86-video-amdgpu (amd-gfx)
> * mesa (mesa-dev)
>
> These patches enable adaptive variable refresh on X for AMD hardware 
> provided that the user sets the variable_refresh_enabled property to true 
> on supported connectors (ie. using xrandr --set-prop).
>
> The patches have been tested as working on upstream userland with the 
> GNOME desktop environment under a single monitor setup. They also work on 
> KDE in single monitor setup if the compositor is disabled.
>
> The patches require that the application window can issue screen flips 
> via the Present extension to xf86-video-amdgpu. Due to Present extension 
> limitations some desktop environments and multi-monitor setups are 
> currently not compatible.
>
> Full implementation details for these changes can be reviewed in their 
> respective mailing lists.
>
> === Previous discussions ===
>
> These patches are based upon feedback from patches and feedback from two 
> previous threads on the subject which are 

[PATCH v4 4/4] drm/amd/display: Set FreeSync state using drm VRR properties

[Nicholas Kazlauskas]

Support for AMDGPU specific FreeSync properties and ioctls are dropped
from amdgpu_dm in favor of supporting drm variable refresh rate
properties.

The drm vrr_capable property is now attached to any DP/HDMI connector.
Its value is updated accordingly to the connector's FreeSync capabiltiy.

The freesync_enable logic and ioctl control has has been dropped in
favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
fine grained atomic control over which CRTCs should support variable
refresh rate.

To handle state changes for vrr_enabled it was easiest to drop the
forced modeset on freesync_enabled change. This patch now performs the
required stream updates when planes are flipped.

This is done for a few reasons:

(1) VRR stream updates can be done in the fast update path

(2) amdgpu_dm_atomic_check would need to be hacked apart to check
desired variable refresh state and capability before the CRTC
disable pass.

(3) Performing VRR stream updates on-flip is needed for enabling BTR
support.

VRR packets and timing adjustments are now tracked and compared to
previous values sent to the hardware.

Signed-off-by: Nicholas Kazlauskas 
---
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +-
 2 files changed, 138 insertions(+), 124 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6a2342d72742..d5de4b91e144 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1802,72 +1802,6 @@ static void dm_bandwidth_update(struct amdgpu_device 
*adev)
/* TODO: implement later */
 }
 
-static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
-   struct drm_file *filp)
-{
-   struct drm_atomic_state *state;
-   struct drm_modeset_acquire_ctx ctx;
-   struct drm_crtc *crtc;
-   struct drm_connector *connector;
-   struct drm_connector_state *old_con_state, *new_con_state;
-   int ret = 0;
-   uint8_t i;
-   bool enable = false;
-
-   drm_modeset_acquire_init(, 0);
-
-   state = drm_atomic_state_alloc(dev);
-   if (!state) {
-   ret = -ENOMEM;
-   goto out;
-   }
-   state->acquire_ctx = 
-
-retry:
-   drm_for_each_crtc(crtc, dev) {
-   ret = drm_atomic_add_affected_connectors(state, crtc);
-   if (ret)
-   goto fail;
-
-   /* TODO rework amdgpu_dm_commit_planes so we don't need this */
-   ret = drm_atomic_add_affected_planes(state, crtc);
-   if (ret)
-   goto fail;
-   }
-
-   for_each_oldnew_connector_in_state(state, connector, old_con_state, 
new_con_state, i) {
-   struct dm_connector_state *dm_new_con_state = 
to_dm_connector_state(new_con_state);
-   struct drm_crtc_state *new_crtc_state;
-   struct amdgpu_crtc *acrtc = 
to_amdgpu_crtc(dm_new_con_state->base.crtc);
-   struct dm_crtc_state *dm_new_crtc_state;
-
-   if (!acrtc) {
-   ASSERT(0);
-   continue;
-   }
-
-   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
>base);
-   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
-
-   dm_new_crtc_state->freesync_enabled = enable;
-   }
-
-   ret = drm_atomic_commit(state);
-
-fail:
-   if (ret == -EDEADLK) {
-   drm_atomic_state_clear(state);
-   drm_modeset_backoff();
-   goto retry;
-   }
-
-   drm_atomic_state_put(state);
-
-out:
-   drm_modeset_drop_locks();
-   drm_modeset_acquire_fini();
-   return ret;
-}
 
 static const struct amdgpu_display_funcs dm_display_funcs = {
.bandwidth_update = dm_bandwidth_update, /* called unconditionally */
@@ -1881,7 +1815,6 @@ static const struct amdgpu_display_funcs dm_display_funcs 
= {
dm_crtc_get_scanoutpos,/* called unconditionally */
.add_encoder = NULL, /* VBIOS parsing. DAL does it. */
.add_connector = NULL, /* VBIOS parsing. DAL does it. */
-   .notify_freesync = amdgpu_notify_freesync,
 
 };
 
@@ -2834,7 +2767,8 @@ dm_crtc_duplicate_state(struct drm_crtc *crtc)
 
state->adjust = cur->adjust;
state->vrr_infopacket = cur->vrr_infopacket;
-   state->freesync_enabled = cur->freesync_enabled;
+   state->vrr_supported = cur->vrr_supported;
+   state->freesync_config = cur->freesync_config;
 
/* TODO Duplicate dc_stream after objects are stream object is 
flattened */
 
@@ -3053,8 +2987,6 @@ amdgpu_dm_connector_atomic_duplicate_state(struct 
drm_connector *connector)
__drm_atomic_helper_connector_duplicate_state(connector, 
_state->base);
 
new_state->freesync_capable = 

[PATCH v4 3/4] drm: Document variable refresh properties

[Nicholas Kazlauskas]

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 a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 4b1501b4835b..8da2a178cf85 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -575,6 +575,13 @@ Explicit Fencing Properties
 .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
:doc: explicit fencing properties
 
+
+Variable Refresh Properties
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: Variable refresh properties
+
 Existing KMS Properties
 ---
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index f0deeb7298d0..2a12853ca917 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1254,6 +1254,28 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * DOC: Variable refresh properties
+ *
+ * Variable refresh rate control is supported via properties on the
+ * _connector and _crtc objects.
+ *
+ * "vrr_capable":
+ * Optional _connector boolean property that drivers should attach
+ * with drm_connector_attach_vrr_capable_property() on connectors that
+ * could support variable refresh rates. Drivers should update the
+ * property value by calling drm_connector_set_vrr_capable_property().
+ *
+ * Absence of the property should indicate absence of support.
+ *
+ * "vrr_enabled":
+ * Default _crtc boolean property that notifies the driver that the
+ * variable refresh rate adjustment should be enabled for the CRTC.
+ *
+ * Support for variable refresh rate will depend on the "vrr_capable"
+ * property exposed on the _connector object.
+ */
+
 /**
  * drm_connector_attach_vrr_capable_property - creates the
  * vrr_capable property
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v4 2/4] drm: Add vrr_enabled property to drm CRTC

[Nicholas Kazlauskas]

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 considered an error.

Capability for variable refresh rate support should be determined
by querying the vrr_capable drm connector property.

It is worth noting that while the property is intended for atomic use
it isn't filtered from legacy userspace queries. This allows for Xorg
userspace drivers to implement support.

Signed-off-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 
 drivers/gpu/drm/drm_crtc.c| 2 ++
 drivers/gpu/drm/drm_mode_config.c | 6 ++
 include/drm/drm_crtc.h| 9 +
 include/drm/drm_mode_config.h | 5 +
 5 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..eec396a57b88 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -433,6 +433,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
drm_property_blob_put(mode);
return ret;
+   } else if (property == config->prop_vrr_enabled) {
+   state->vrr_enabled = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -491,6 +493,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->active;
else if (property == config->prop_mode_id)
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
+   else if (property == config->prop_vrr_enabled)
+   *val = state->vrr_enabled;
else if (property == config->degamma_lut_property)
*val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
else if (property == config->ctm_property)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5f488aa80bcd..e4eb2c897ff4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
drm_object_attach_property(>base, config->prop_mode_id, 
0);
drm_object_attach_property(>base,
   config->prop_out_fence_ptr, 0);
+   drm_object_attach_property(>base,
+  config->prop_vrr_enabled, 0);
}
 
return 0;
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..5670c67f28d4 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
 
+   prop = drm_property_create_bool(dev, 0,
+   "VRR_ENABLED");
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_vrr_enabled = prop;
+
prop = drm_property_create(dev,
DRM_MODE_PROP_BLOB,
"DEGAMMA_LUT", 0);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b21437bc95bf..39c3900aab3c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -290,6 +290,15 @@ struct drm_crtc_state {
 */
u32 pageflip_flags;
 
+   /**
+* @vrr_enabled:
+*
+* Indicates if variable refresh rate should be enabled for the CRTC.
+* Support for the requested vrr state will depend on driver and
+* hardware capabiltiy - lacking support is not treated as failure.
+*/
+   bool vrr_enabled;
+
/**
 * @event:
 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 928e4172a0bb..49f2fcfdb5fc 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -639,6 +639,11 @@ struct drm_mode_config {
 * connectors must be of and active must be set to disabled, too.
 */
struct drm_property *prop_mode_id;
+   /**
+* @prop_vrr_enabled: Default atomic CRTC property to indicate
+* whether variable refresh rate should be enabled on the CRTC.
+*/
+   struct drm_property *prop_vrr_enabled;
 
/**
 * @dvi_i_subconnector_property: Optional DVI-I property to
-- 
2.19.1

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH v4 1/4] drm: Add vrr_capable property to the drm connector

[Nicholas Kazlauskas]

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 refresh rates using
drm_connector_attach_vrr_capable_property().

The value should be updated based on driver and hardware capabiltiy
by using drm_connector_set_vrr_capable_property().

Signed-off-by: Nicholas Kazlauskas 
---
 drivers/gpu/drm/drm_connector.c | 49 +
 include/drm/drm_connector.h | 15 ++
 2 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1e40e5decbe9..f0deeb7298d0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1254,6 +1254,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_connector_attach_vrr_capable_property - creates the
+ * vrr_capable property
+ * @connector: connector to create the vrr_capable property on.
+ *
+ * This is used by atomic drivers to add support for querying
+ * variable refresh rate capability for a connector.
+ *
+ * Returns:
+ * Zero on success, negative errono on failure.
+ */
+int drm_connector_attach_vrr_capable_property(
+   struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->vrr_capable_property) {
+   prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
+   "vrr_capable");
+   if (!prop)
+   return -ENOMEM;
+
+   connector->vrr_capable_property = prop;
+   drm_object_attach_property(>base, prop, 0);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
+
 /**
  * drm_connector_attach_scaling_mode_property - attach atomic scaling mode 
property
  * @connector: connector to attach scaling mode property on.
@@ -1582,6 +1613,24 @@ void drm_connector_set_link_status_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_set_link_status_property);
 
+/**
+ * drm_connector_set_vrr_capable_property - sets the variable refresh rate
+ * capable property for a connector
+ * @connector: drm connector
+ * @capable: True if the connector is variable refresh rate capable
+ *
+ * Should be used by atomic drivers to update the indicated support for
+ * variable refresh rate over a connector.
+ */
+void drm_connector_set_vrr_capable_property(
+   struct drm_connector *connector, bool capable)
+{
+   drm_object_property_set_value(>base,
+ connector->vrr_capable_property,
+ capable);
+}
+EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
+
 /**
  * drm_connector_init_panel_orientation_property -
  * initialize the connecters panel_orientation property
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 91a877fa00cb..b2263005234a 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -910,6 +910,17 @@ struct drm_connector {
 */
struct drm_property *scaling_mode_property;
 
+   /**
+* @vrr_capable_property: Optional property to help userspace
+* query hardware support for variable refresh rate on a connector.
+* connector. Drivers can add the property to a connector by
+* calling drm_connector_attach_vrr_capable_property().
+*
+* This should be updated only by calling
+* drm_connector_set_vrr_capable_property().
+*/
+   struct drm_property *vrr_capable_property;
+
/**
 * @content_protection_property: DRM ENUM property for content
 * protection. See drm_connector_attach_content_protection_property().
@@ -1183,6 +1194,8 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev);
 int drm_connector_attach_content_type_property(struct drm_connector *dev);
 int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
   u32 scaling_mode_mask);
+int drm_connector_attach_vrr_capable_property(
+   struct drm_connector *connector);
 int drm_connector_attach_content_protection_property(
struct drm_connector *connector);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
@@ -1199,6 +1212,8 @@ int drm_connector_update_edid_property(struct 
drm_connector *connector,
   const struct edid *edid);
 void drm_connector_set_link_status_property(struct drm_connector *connector,
uint64_t link_status);
+void drm_connector_set_vrr_capable_property(
+   struct 

[PATCH v4 0/4] A DRM API for adaptive sync and variable refresh rate support

[Nicholas Kazlauskas]

These patches are part of a proposed new interface for supporting variable 
refresh rate via DRM properties.

=== Changes from v3 ===

drm changes:

* Docstring and formatting fixes

amd/display changes:

* Updated commit message and debug statements

=== Changes from v2 ===

The interface has changed substantially from the last revision and the cover 
letter has been updated accordingly.

drm changes:

* Most "variable_refresh" prefixes in code have been shortened to just "vrr". 
This was motivated after changes to the interface had function names close to 
80 characters long. Comments from the mailing list were already shortening 
these in discussion as well.
* Documentation for "Variable Refresh" has been added to the KMS properties 
subsection for DRM driver developers.
* The drm_connector property "variable_refresh_capable" has been renamed to 
"vrr_capable".
* The drm_crtc property "variable_refresh" has been been renamed "vrr_enabled" 
to better reflect its usage.
* The drm_connector "variable_refresh_enabled" property has been removed. 
Managing this is now up to userspace when it sets "vrr_enabled".
* The "vrr_capable" property no longer has any state in drm_connector_state 
associated with it. The value can now be updated with the 
drm_connector_set_vrr_capable_property() function. This better matches the 
immutable flag on the property.
* The "variable_refresh_changed" flag has been removed from atomic helpers 
based on feedback from the mailing list and updated interface usage in the amd 
kernel driver.

amd/display changes:

* Updated interface usage based on the new properties
* Updated VRR infopacket handling based on new xf86-video-amdgpu usage

=== Adaptive sync and variable refresh rate ===

Adaptive sync is part of the DisplayPort specification and allows for graphics 
adapters to drive displays with varying frame timings.

Variable refresh rate (VRR) is essentially the same, but defined for HDMI.

=== Use cases for variable refresh rate ===

Variable frame (flip) timings don't align well with fixed refresh rate 
displays. This results in stuttering, tearing and/or input lag. By adjusting 
the display refresh rate dynamically these issues can be reduced or eliminated.

However, not all content is suitable for dynamic refresh adaptation. The user 
may experience "flickering" from differences in panel luminance at different 
refresh rates. Content that flips at an infrequent rate or demand is more 
likely to cause large changes in refresh rate that result in flickering.

Userland needs a way to let the driver know when the screen content is suitable 
for variable refresh rates.

=== DRM API to support variable refresh rates ===

This patch introduces a new API via atomic properties on the DRM connector and 
CRTC.

The drm_connector has one new optional boolean property:

* bool vrr_capable - set by the driver if the hardware is capable of supporting 
variable refresh rates

The drm_crtc has one new default boolean property:

* bool vrr_enabled - set by userspace indicating that variable refresh rate 
should be enabled

== Overview for DRM driver developers ===

Driver developers can attach the "vrr_capable" property by calling 
drm_connector_attach_vrr_capable_property(). This should be done on connectors 
that could be capable of supporting variable refresh rates (such as DP or HDMI).

The "vrr_capable" can then be updated accordingly by calling 
drm_connector_set_vrr_capable_property().

The "vrr_enabled" property can be checked from the drm_crtc_state object.

=== Overview for Userland developers ==

The "vrr_enabled" property on the CRTC should be set to true when the CRTC is 
suitable for variable refresh rates.

To demonstrate the suitability of the API for variable refresh and dynamic 
adaptation there are additional patches using this API that implement adaptive 
variable refresh across kernel and userland projects:

* DRM (dri-devel)
* amdgpu DRM kernel driver (amd-gfx)
* xf86-video-amdgpu 
(https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu)
* mesa (mesa-dev)

These patches enable adaptive variable refresh on X for AMD hardware. Support 
for variable refresh is disabled by default in xf86-video-amdgpu and will 
require additional user configuration.

The patches have been tested as working on upstream userland with the GNOME 
desktop environment under a single monitor setup. They also work on KDE in a 
single monitor setup with the compositor disabled.

The patches require that suitable applications flip via the Present extension 
to xf86-video-amdgpu for the entire Screen. Some compositors may interfere with 
this if they are unable to unredirect the window.

Full implementation details for these changes can be reviewed in their 
respective mailing lists and the xf86-video-amdgpu GitLab.

=== Previous discussions ===

These patches are based upon feedback from previous threads on the subject. 
These are linked below for reference:

Re: [PATCH 00/18] VCN start/stop clean up

[Alex Deucher]

On Wed, Oct 10, 2018 at 3:27 PM James Zhu  wrote:
>
> Clean up current VCN start/stop function, and update with latest
> firmware/hardware implemention.
>

Series is:
Acked-by: Alex Deucher 

> James Zhu (18):
>   drm/amdgpu/vcn:Add new register offset/mask for VCN
>   drm/amdgpu/vcn:Update latest UVD_MPC register for VCN
>   drm/amdgpu/vcn:Update latest spg mode stop for VCN
>   drm/amdgpu/vcn:Add ring W/R PTR check for VCN DPG mode stop
>   drm/amdgpu/vcn:Reduce unnecessary local variable
>   drm/amdgpu/vcn:Update DPG mode VCN memory control
>   drm/amdgpu/vcn:Update DPG mode VCN global tiling registers
>   drm/amdgpu/vcn:Add DPG mode Register XX check
>   drm/amdgpu/vcn:Remove DPG mode unused steps during vcn start
>   drm/amdgpu/vcn:Apply new UMC enable for VNC DPG mode start
>   drm/amdgpu/vcn:Update SPG mode VCN memory control
>   drm/amdgpu/vcn:Update SPG mode VCN global tiling
>   drm/amdgpu/vcn:Move SPG mode mc resume after MPC control
>   drm/amdgpu/vcn:Add SPG mode Register XX check
>   drm/amdgpu/vcn:Remove SPG mode unused steps during vcn start
>   drm/amdgpu/vcn:Apply new UMC enable for VNC DPG mode
>   drm/amdgpu/vcn:Set VCPU busy after gate power during vcn SPG start
>   drm/amdgpu/vcn:Update SPG mode UVD status clear
>
>  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c  | 288 
> -
>  .../drm/amd/include/asic_reg/vcn/vcn_1_0_offset.h  |  14 +
>  .../drm/amd/include/asic_reg/vcn/vcn_1_0_sh_mask.h |  18 ++
>  3 files changed, 201 insertions(+), 119 deletions(-)
>
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 18/18] drm/amdgpu/vcn:Update SPG mode UVD status clear

[Leo Liu]

Looks good to me. The whole series are:

Acked-by: Leo Liu 


On 10/10/2018 02:42 PM, James Zhu wrote:

Update Static Power Gate mode UVD status clear

Signed-off-by: James Zhu 
---
  drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c 
b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
index d8fe14d..bc64706 100644
--- a/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/vcn_v1_0.c
@@ -883,9 +883,9 @@ static int vcn_v1_0_start_spg_mode(struct amdgpu_device 
*adev)
UVD_SYS_INT_EN__UVD_JRBC_EN_MASK,
~UVD_SYS_INT_EN__UVD_JRBC_EN_MASK);
  
-	/* clear the bit 4 of VCN_STATUS */

-   WREG32_P(SOC15_REG_OFFSET(UVD, 0, mmUVD_STATUS), 0,
-   ~(2 << UVD_STATUS__VCPU_REPORT__SHIFT));
+   /* clear the busy bit of UVD_STATUS */
+   tmp = RREG32_SOC15(UVD, 0, mmUVD_STATUS) & ~UVD_STATUS__UVD_BUSY;
+   WREG32_SOC15(UVD, 0, mmUVD_STATUS, tmp);
  
  	/* force RBC into idle state */

rb_bufsz = order_base_2(ring->ring_size);


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 1/2] drm/amdgpu: fix sdma doorbell comments typo

[Alex Deucher]

On Thu, Oct 11, 2018 at 8:10 AM Frank.Min  wrote:
>
> Change-Id: I0a3dff9f01a90717e0c32b7fa81a5e891bd1d52d
> Signed-off-by: Frank.Min 

This patch is:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index c21d9b9..6317f35 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -432,7 +432,7 @@ typedef enum _AMDGPU_DOORBELL64_ASSIGNMENT
>  * default non-graphics QWORD index is 0xe0 - 0xFF inclusive
>  */
>
> -   /* sDMA engines  reserved from 0xe0 -oxef  */
> +   /* sDMA engines  reserved from 0xe0 -0xef  */
> AMDGPU_DOORBELL64_sDMA_ENGINE0= 0xE0,
> AMDGPU_DOORBELL64_sDMA_HI_PRI_ENGINE0 = 0xE1,
> AMDGPU_DOORBELL64_sDMA_ENGINE1= 0xE8,
> --
> 2.7.4
>
> ___
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCH 2/2] drm/amdgpu: skip vm entries checking while in sriov vf

[Christian König]

Am 11.10.2018 um 14:09 schrieb Frank.Min:

vm page table would be allocated while in amdgpu_vm_init
by amdgpu_allocate_static_csa for sriov, so the checking
here would be skipped.


NAK, that checking is actually correct and points out that this doesn't 
work correctly.


Fix the function to be able to handle the case when there are already 
mappings in the VM.


Christian.



Change-Id: Id30b86ad15ae509aeed9ed8ab60c259c88af3df5
Signed-off-by: Frank.Min 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6904d79..6066f87 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3100,11 +3100,12 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm, uns
return r;
  
  	/* Sanity checks */

-   if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
-   r = -EINVAL;
-   goto unreserve_bo;
+   if (!amdgpu_sriov_vf(adev)) {
+   if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
+   r = -EINVAL;
+   goto unreserve_bo;
+   }
}
-
if (pasid) {
unsigned long flags;
  


___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 2/2] drm/amdgpu: skip vm entries checking while in sriov vf

[Frank . Min]

vm page table would be allocated while in amdgpu_vm_init
by amdgpu_allocate_static_csa for sriov, so the checking
here would be skipped.

Change-Id: Id30b86ad15ae509aeed9ed8ab60c259c88af3df5
Signed-off-by: Frank.Min 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 6904d79..6066f87 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -3100,11 +3100,12 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, 
struct amdgpu_vm *vm, uns
return r;
 
/* Sanity checks */
-   if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
-   r = -EINVAL;
-   goto unreserve_bo;
+   if (!amdgpu_sriov_vf(adev)) {
+   if (!RB_EMPTY_ROOT(>va.rb_root) || vm->root.entries) {
+   r = -EINVAL;
+   goto unreserve_bo;
+   }
}
-
if (pasid) {
unsigned long flags;
 
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amdgpu: fix sdma doorbell comments typo

[Frank . Min]

Change-Id: I0a3dff9f01a90717e0c32b7fa81a5e891bd1d52d
Signed-off-by: Frank.Min 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c21d9b9..6317f35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -432,7 +432,7 @@ typedef enum _AMDGPU_DOORBELL64_ASSIGNMENT
 * default non-graphics QWORD index is 0xe0 - 0xFF inclusive
 */
 
-   /* sDMA engines  reserved from 0xe0 -oxef  */
+   /* sDMA engines  reserved from 0xe0 -0xef  */
AMDGPU_DOORBELL64_sDMA_ENGINE0= 0xE0,
AMDGPU_DOORBELL64_sDMA_HI_PRI_ENGINE0 = 0xE1,
AMDGPU_DOORBELL64_sDMA_ENGINE1= 0xE8,
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

[PATCH 1/2] drm/amdgpu: fix sdma doorbell comments typo

[Frank . Min]

Change-Id: I0a3dff9f01a90717e0c32b7fa81a5e891bd1d52d
Signed-off-by: Frank.Min 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c21d9b9..6317f35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -432,7 +432,7 @@ typedef enum _AMDGPU_DOORBELL64_ASSIGNMENT
 * default non-graphics QWORD index is 0xe0 - 0xFF inclusive
 */
 
-   /* sDMA engines  reserved from 0xe0 -oxef  */
+   /* sDMA engines  reserved from 0xe0 -0xef  */
AMDGPU_DOORBELL64_sDMA_ENGINE0= 0xE0,
AMDGPU_DOORBELL64_sDMA_HI_PRI_ENGINE0 = 0xE1,
AMDGPU_DOORBELL64_sDMA_ENGINE1= 0xE8,
-- 
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx