date:20181125

RE: [PATCH] drm: should break if already get the best size

2018-11-25 Thread Liu, Monk

Ok, will send a v2 version with description

From: Deucher, Alexander
Sent: Saturday, November 24, 2018 3:34 AM
To: Zhu, Rex ; Liu, Monk ; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm: should break if already get the best size


Please add a proper patch description.



Alex


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Zhu, Rex mailto:rex@amd.com>>
Sent: Friday, November 23, 2018 4:44:31 AM
To: Liu, Monk; 
amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm: should break if already get the best size


Tested-by: Rex Zhu mailto:rex@amd.com>>



Without this patch, if we search node via rb tree.



For example: we insert  different node with rand size, size range in 
(1-).



the key in root node is 5587.



if we try to find the node with key equal to 5587 or 7381,


Loop:
node->key is 5587
node->key is 2273
node->key is 3706
node->key is 4892
node->key is 5296
node->key is 5461
node->key is 5519
node->key is 5549
node->key is 5570
node->key is 5581
node->key is 5584
node->key is 5585
node->key is 5586
node->key is 5586

Find the best node, key is 5587 (Loop 14 levels)

Loop:
node->key is 5587
node->key is 7381
node->key is 6474
node->key is 7034
node->key is 7228
node->key is 7314
node->key is 7339
node->key is 7349
node->key is 7372
node->key is 7377
node->key is 7378
node->key is 7379
node->key is 7379

find the best node, key is 7381. (Loop 13 levels)



With this patch:

we don't need to go down if we found the right node that size equal to we 
needed.



Best Regards
Rex


From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Monk Liu mailto:monk@amd.com>>
Sent: Thursday, November 22, 2018 8:33 PM
To: amd-gfx@lists.freedesktop.org
Cc: Liu, Monk
Subject: [PATCH] drm: should break if already get the best size

Signed-off-by: Monk Liu mailto:monk@amd.com>>
---
 drivers/gpu/drm/drm_mm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 3cc5fbd..369fd9b 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -318,6 +318,8 @@ static struct drm_mm_node *best_hole(struct drm_mm *mm, u64 
size)
 if (size <= node->hole_size) {
 best = node;
 rb = rb->rb_right;
+   if (size == node->hole_size)
+   break;
 } else {
 rb = rb->rb_left;
 }
--
2.7.4

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
amd-gfx Info Page - 
freedesktop.org
lists.freedesktop.org
To see the collection of prior postings to the list, visit the amd-gfx 
Archives.. Using amd-gfx: To post a message to all the list members, send email 
to amd-gfx@lists.freedesktop.org. You can 
subscribe to the list, or change your existing subscription, in the sections 
below.


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

Re: [PATCH] drm/amdgpu: Moved doorbell structures to seperate file

2018-11-25 Thread Deucher, Alexander

Fwded.  You can also see the archives here:

https://lists.freedesktop.org/archives/amd-gfx/2018-November/028781.html


Alex


From: Zeng, Oak
Sent: Friday, November 23, 2018 6:18:55 PM
To: Deucher, Alexander; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Moved doorbell structures to seperate file


Alex,



No I didn’t. I don’t know what happened to my email account.



Can you forward that comment to me again?



Regards,

Oak



From: Deucher, Alexander 
Sent: Friday, November 23, 2018 3:20 PM
To: Zeng, Oak ; amd-gfx@lists.freedesktop.org
Cc: Zeng, Oak 
Subject: Re: [PATCH] drm/amdgpu: Moved doorbell structures to seperate file



Did you see my other comments about consolidating vega10, raven, and vega12?



Reviewed-by: Alex Deucher 
mailto:alexander.deuc...@amd.com>>



From: amd-gfx 
mailto:amd-gfx-boun...@lists.freedesktop.org>>
 on behalf of Oak Zeng mailto:oz...@amd.com>>
Sent: Friday, November 23, 2018 3:01:23 PM
To: amd-gfx@lists.freedesktop.org
Cc: Zeng, Oak
Subject: [PATCH] drm/amdgpu: Moved doorbell structures to seperate file



Move doorbell structures, enum definitions and helper functions
from amdgpu.h to amdgpu_doorbell.h. No functional change

Change-Id: I09f7b84869b6d3c688b7a2506ff78d62b3de23f5
Signed-off-by: Oak Zeng mailto:oz...@amd.com>>
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h  | 227 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h | 249 +++
 2 files changed, 250 insertions(+), 226 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_doorbell.h

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index e4101b1..7fc32c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -81,6 +81,7 @@
 #include "amdgpu_job.h"
 #include "amdgpu_bo_list.h"
 #include "amdgpu_gem.h"
+#include "amdgpu_doorbell.h"

 #define MAX_GPU_INSTANCE16

@@ -361,173 +362,6 @@ int amdgpu_fence_slab_init(void);
 void amdgpu_fence_slab_fini(void);

 /*
- * GPU doorbell structures, functions & helpers
- */
-typedef enum _AMDGPU_DOORBELL_ASSIGNMENT
-{
-   AMDGPU_DOORBELL_KIQ = 0x000,
-   AMDGPU_DOORBELL_HIQ = 0x001,
-   AMDGPU_DOORBELL_DIQ = 0x002,
-   AMDGPU_DOORBELL_MEC_RING0   = 0x010,
-   AMDGPU_DOORBELL_MEC_RING1   = 0x011,
-   AMDGPU_DOORBELL_MEC_RING2   = 0x012,
-   AMDGPU_DOORBELL_MEC_RING3   = 0x013,
-   AMDGPU_DOORBELL_MEC_RING4   = 0x014,
-   AMDGPU_DOORBELL_MEC_RING5   = 0x015,
-   AMDGPU_DOORBELL_MEC_RING6   = 0x016,
-   AMDGPU_DOORBELL_MEC_RING7   = 0x017,
-   AMDGPU_DOORBELL_GFX_RING0   = 0x020,
-   AMDGPU_DOORBELL_sDMA_ENGINE0= 0x1E0,
-   AMDGPU_DOORBELL_sDMA_ENGINE1= 0x1E1,
-   AMDGPU_DOORBELL_IH  = 0x1E8,
-   AMDGPU_DOORBELL_MAX_ASSIGNMENT  = 0x3FF,
-   AMDGPU_DOORBELL_INVALID = 0x
-} AMDGPU_DOORBELL_ASSIGNMENT;
-
-struct amdgpu_doorbell {
-   /* doorbell mmio */
-   resource_size_t base;
-   resource_size_t size;
-   u32 __iomem *ptr;
-   u32 num_doorbells;  /* Number of doorbells actually 
reserved for amdgpu. */
-};
-
-typedef enum _AMDGPU_VEGA20_DOORBELL_ASSIGNMENT
-{
-   /* Compute + GFX: 0~255 */
-   AMDGPU_VEGA20_DOORBELL_KIQ = 0x000,
-   AMDGPU_VEGA20_DOORBELL_HIQ = 0x001,
-   AMDGPU_VEGA20_DOORBELL_DIQ = 0x002,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING0   = 0x003,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING1   = 0x004,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING2   = 0x005,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING3   = 0x006,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING4   = 0x007,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING5   = 0x008,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING6   = 0x009,
-   AMDGPU_VEGA20_DOORBELL_MEC_RING7   = 0x00A,
-   AMDGPU_VEGA20_DOORBELL_USERQUEUE_START = 0x00B,
-   AMDGPU_VEGA20_DOORBELL_USERQUEUE_END   = 0x08A,
-   AMDGPU_VEGA20_DOORBELL_GFX_RING0   = 0x08B,
-   /* SDMA:256~335*/
-   AMDGPU_VEGA20_DOORBELL_sDMA_ENGINE0= 0x100,
-   AMDGPU_VEGA20_DOORBELL_sDMA_ENGINE1= 0x10A,
-   AMDGPU_VEGA20_DOORBELL_sDMA_ENGINE2= 0x114,
-   AMDGPU_VEGA20_DOORBELL_sDMA_ENGINE3= 0x11E,
-   AMDGPU_VEGA20_DOORBELL_sDMA_ENGINE4= 0x128,
-   AMDGPU_VEGA20_DOORBELL_sDMA_ENGINE5= 0x132,
-   AMDGPU_VEGA20_DOORBELL_sDMA_ENGINE6= 0x13C,
-

[PATCH] drm/amdgpu: disable UVD/VCE for some polaris10 variants

2018-11-25 Thread Junwei Zhang

Some variants don't support UVD and VCE.

Signed-off-by: Junwei Zhang 
Reviewed-by: Flora Cui 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index f3a4cf1f013a..16a28d20be82 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1660,8 +1660,13 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
amdgpu_device_ip_block_add(adev, _v11_2_ip_block);
amdgpu_device_ip_block_add(adev, _v8_0_ip_block);
amdgpu_device_ip_block_add(adev, _v3_1_ip_block);
-   amdgpu_device_ip_block_add(adev, _v6_3_ip_block);
-   amdgpu_device_ip_block_add(adev, _v3_4_ip_block);
+   if ((adev->pdev->device == 0x67df) &&
+ (adev->pdev->revision == 0xf7)) {
+   /* Some polaris10 variants don't support UVD/VCE */
+   } else {
+   amdgpu_device_ip_block_add(adev, _v6_3_ip_block);
+   amdgpu_device_ip_block_add(adev, _v3_4_ip_block);
+   }
break;
case CHIP_CARRIZO:
amdgpu_device_ip_block_add(adev, _common_ip_block);
-- 
2.17.1

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

RE: [PATCH] drm/amdgpu: add the checking to avoid NULL pointer dereference

2018-11-25 Thread Sharma, Deepak



在 2018/11/24 2:10, Koenig, Christian 写道:
> Am 23.11.18 um 15:10 schrieb Zhou, David(ChunMing):
>> 在 2018/11/23 21:30, Koenig, Christian 写道:
>>> Am 23.11.18 um 14:27 schrieb Zhou, David(ChunMing):
 在 2018/11/22 19:25, Christian König 写道:
> Am 22.11.18 um 07:56 schrieb Sharma, Deepak:
>> when returned fence is not valid mostly due to userspace ignored 
>> previous error causes NULL pointer dereference.
> Again, this is clearly incorrect. The my other mails on the 
> earlier patch.
 Sorry for I didn't get your history, but looks from the patch 
 itself, it is still a valid patch, isn't it?
>>> No, the semantic of amdgpu_ctx_get_fence() is that we return NULL 
>>> when the fence is already signaled.
>>>
>>> So this patch could totally break userspace because it changes the 
>>> behavior when we try to sync to an already signaled fence.
>> Ah, I got your meaning, how about attached patch?
> Yeah something like this, but I would just give the 
> DRM_SYNCOBJ_CREATE_SIGNALED instead.
>
> I mean that's what this flag is good for isn't it?
Yeah, I give a flag initally when creating patch, but as you know, there is a 
swich case not be able to use that flag:

     case AMDGPU_FENCE_TO_HANDLE_GET_SYNC_FILE_FD:
     fd = get_unused_fd_flags(O_CLOEXEC);
     if (fd < 0) {
     dma_fence_put(fence);
     return fd;
     }

     sync_file = sync_file_create(fence);
     dma_fence_put(fence);
     if (!sync_file) {
     put_unused_fd(fd);
     return -ENOMEM;
     }

     fd_install(fd, sync_file->file);
     info->out.handle = fd;
     return 0;

So I change to stub fence instead.

-David

I have not applied this patch.
The issue was trying to address is when amdgpu_cs_ioctl() failed due to low 
memory (ENOMEM) but userspace chose to proceed and called 
amdgpu_cs_fence_to_handle_ioctl().
In amdgpu_cs_fence_to_handle_ioctl(), fence is null and later causing NULL 
pointer dereference, this patch was to avoid that and system panic
But I understand now that its a valid case retuning NULL if fence was already 
signaled but need to handle case so avoid kernel panic. Seems David patch 
should fix this, I will test it tomorrow. 

-Deepak
>
> Christian.
>
>> -David
>>> If that patch was applied then please revert it immediately.
>>>
>>> Christian.
>>>
 -David
> If you have already pushed the patch then please revert.
>
> Christian.
>
>> Signed-off-by: Deepak Sharma 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> index 024dfbd87f11..14166cd8a12f 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
>> @@ -1403,6 +1403,8 @@ static struct dma_fence 
>> *amdgpu_cs_get_fence(struct amdgpu_device *adev,
>>     fence = amdgpu_ctx_get_fence(ctx, entity, user->seq_no);
>>   amdgpu_ctx_put(ctx);
>> +    if(!fence)
>> +    return ERR_PTR(-EINVAL);
>>     return fence;
>>   }

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

Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants

2018-11-25 Thread Zhang, Jerry(Junwei)


On 11/24/18 3:32 AM, Deucher, Alexander wrote:


Is this required?  Are the harvesting fuses incorrect?  If the blocks 
are harvested, we should bail out of the blocks properly during init. 
 Also, please make this more explicit if we still need it.  E.g.,





The harvest fuse is indeed disabling UVD and VCE, as it's a mining card.
Then any command to UVD/VCE causing NULL pointer issue, like amdgpu_test.

AFAIW, windows also disable UVD and VCE in initialization.


   if ((adev->pdev->device == 0x67df) &&
  (adev->pdev->revision == 0xf7)) {

/* Some polaris12 variants don't support UVD/VCE */

  } else  {

amdgpu_device_ip_block_add(adev, _v6_3_ip_block);

amdgpu_device_ip_block_add(adev, _v3_4_ip_block);

    }




OK, will explicit the process.

Regards,
Jerry


That way if we re-arrange the order later, it will be easier to track.


Alex


*From:* amd-gfx  on behalf of 
Junwei Zhang 

*Sent:* Friday, November 23, 2018 3:32:27 AM
*To:* amd-gfx@lists.freedesktop.org
*Cc:* Zhang, Jerry
*Subject:* [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 
variants

Some variants don't support UVD and VCE.

Signed-off-by: Junwei Zhang 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c 
b/drivers/gpu/drm/amd/amdgpu/vi.c

index f3a4cf1f013a..3338b013ded4 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1660,6 +1660,10 @@ int vi_set_ip_blocks(struct amdgpu_device *adev)
 amdgpu_device_ip_block_add(adev, 
_v11_2_ip_block);

 amdgpu_device_ip_block_add(adev, _v8_0_ip_block);
 amdgpu_device_ip_block_add(adev, _v3_1_ip_block);
+   /* Some polaris12 variants don't support UVD/VCE */
+   if ((adev->pdev->device == 0x67df) &&
+ (adev->pdev->revision == 0xf7))
+   break;
 amdgpu_device_ip_block_add(adev, _v6_3_ip_block);
 amdgpu_device_ip_block_add(adev, _v3_4_ip_block);
 break;
--
2.17.1

___
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: amdgpu: several powerplay errors during boot of HAWAII PRO GPU

2018-11-25 Thread Kai Wasserbäch

[Please CC me on replies, I'm not subscribed to amd-gfx.]

Hey Alex,
Alex Deucher wrote on 23.11.18 21:22:
> On Fri, Nov 23, 2018 at 5:28 AM Kai Wasserbäch  
> wrote:
>> with the recent 4.19.x series of kernels I'm seeing several errors being 
>> logged
>> during boot for my R9 290 (HAWAII PRO) GPU:
>>> [   50.057264] amdgpu: [powerplay] Failed to retrieve minimum clocks.
>>> [   50.057266] amdgpu: [powerplay] Error in phm_get_clock_info
>>> [   50.057309] [drm] dce110_link_encoder_construct: Failed to get 
>>> encoder_cap_info from VBIOS with error code 4!
>>> [   50.057316] [drm] dce110_link_encoder_construct: Failed to get 
>>> encoder_cap_info from VBIOS with error code 4!
>>> [   50.057324] [drm] dce110_link_encoder_construct: Failed to get 
>>> encoder_cap_info from VBIOS with error code 4!
> 
> These are harmless.

ok, thanks. Maybe the error messages could be improved to indicate that they
aren't serious? Something along the lines of "Failed to retrieve minimum clocks,
falling back to $foo."?

>>> [   51.611918] amdgpu: [powerplay]
>>> failed to send message 282 ret is 254
> 
> These may be fixed by this patch if you are using an older pcie gen1/2 
> platform:
> https://patchwork.freedesktop.org/patch/259364/

I've applied that patch on top of 4.19.4 but I'm still seeing:
  [   17.407112] amdgpu: [powerplay]
  failed to send message 282 ret is 254
And as far as I know, I do have PCIe Gen3:
  [   14.992861] [drm] PCIE gen 3 link speeds already enabled

Cheers,
Kai



signature.asc
Description: OpenPGP digital signature
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

RE: [PATCH] drm: should break if already get the best size

Re: [PATCH] drm/amdgpu: Moved doorbell structures to seperate file

[PATCH] drm/amdgpu: disable UVD/VCE for some polaris10 variants

RE: [PATCH] drm/amdgpu: add the checking to avoid NULL pointer dereference

Re: [PATCH] drm/amdgpu: disable UVD/VCE for some polaris 12 variants

Re: amdgpu: several powerplay errors during boot of HAWAII PRO GPU

6 matches

Site Navigation

Mail list logo

Footer information