radeon: Force loading with no microcode - will it damage any hardware?

[Damien Zammit]

Can someone with some AMD gpu hardware expertise please advise whether
forcing cards to continue loading regardless if microcode is missing
will do damage to hardware long term, for the cards supported by
'radeon' driver?

I have heard from someone that it might just be for the 3d CP unit only,
which might just disable 3d graphics if the microcode is missing on r600
and rv770.

I want to know if it's okay so we can get basic 2D support in libre
kernels where the microcode is deblobbed, even though I know it's
generally not recommended to omit microcode for all kinds of reasons.

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

Re: Cannot compile with GCC 8.1

[sylvain . bertrand]

On Thu, May 10, 2018 at 09:34:02PM +, sylvain.bertr...@gmail.com wrote:
> On Thu, May 10, 2018 at 10:27:12PM +0530, Dawson Dias wrote:
> > Wow they're just going to defer it untill GCC 9. So the kernel will be
> > unbuildable using GCC 8.x.
> > Pity.
> 
> And recent llvm do not compile with gcc 7.3.0 because of the extreme 
> complexity
> of the c++ syntax used in the latter... I was waiting for the official release
> of gcc 8.1 to see if the insane c++ syntax features used in llvm were finally
> implemented in g++, or the llvm guys do remove those which do only workin 
> clang
> and not in g++.
> (gcc 8.1 pre-release was not generating correct code for GNU make).
> 
> Really, an alternative "simple C" shader compiler would be more than welcome.

Recent llvm did workaround the 7.3.0 g++ advanced c++ bug.

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

Re: [PATCH 00/12] Assorted KFD fixes

[Oded Gabbay]

Thanks Felix!
Series applied to amdkfd-next

Oded

On Wed, May 2, 2018 at 12:56 AM, Felix Kuehling  wrote:
> These are some random patches I noticed when comparing amdkfd-next against
> amd-kfd-staging.
>
> Ben Goz (1):
>   drm/amdkfd: Locking PM mutex while allocating IB buffer
>
> Felix Kuehling (4):
>   drm/amdkfd: Remove redundant include of amd-iommu.h
>   drm/amdkfd: Fix signal handling performance again
>   drm/amdkfd: Remove initialization of cp_hqd_ib_control on CIK
>   drm/amdkfd: Add sanity checks in IRQ handlers
>
> Jay Cornwall (2):
>   drm/amdkfd: Reduce priority of context-saving waves before spin-wait
>   drm/amdkfd: Use volatile MTYPE in default/alternate apertures
>
> Oak Zeng (1):
>   drm/amdkfd: Dump HQD of HIQ
>
> Philip Yang (1):
>   drm/amdkfd: use %px to print user space address instead of %p
>
> Shaoyun Liu (1):
>   drm/amdkfd: Remove queue node when destroy queue failed
>
> Yong Zhao (2):
>   drm/amdkfd: Separate trap handler assembly code and its hex values
>   drm/amdkfd: Fix CP soft hang on APUs
>
>  drivers/gpu/drm/amd/amdkfd/cik_event_interrupt.c   |  20 +-
>  drivers/gpu/drm/amd/amdkfd/cik_regs.h  |   3 +-
>  drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h | 560 
> +
>  .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm  | 274 +-
>  .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx9.asm  | 307 +--
>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |   2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_device.c|   6 +-
>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |  12 +
>  drivers/gpu/drm/amd/amdkfd/kfd_events.c|   2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_int_process_v9.c|  40 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c   |   4 -
>  drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c|   7 +-
>  .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |  10 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_queue.c |   8 +-
>  14 files changed, 659 insertions(+), 596 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler.h
>
> --
> 2.7.4
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

Re: [PATCHv3] drm/amdkfd: Remove vla

[Oded Gabbay]

On Thu, May 3, 2018 at 12:49 AM, Kees Cook  wrote:
> On Fri, Apr 13, 2018 at 2:24 PM, Laura Abbott  wrote:
>>
>> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
>> turn on -Wvla. Switch to a constant value that covers all hardware.
>>
>> [1] https://lkml.org/lkml/2018/3/7/621
>>
>> Reviewed-by: Felix Kuehling 
>> Acked-by: Christian König 
>> Signed-off-by: Laura Abbott 
>
> Friendly ping -- I don't see this in -next yet. Oded, does this look
> okay to apply?
>
> Thanks!
>
> -Kees

Thanks!
Applied to amdkfd-next

Oded

>
>> ---
>> v3: Introduced a #define for the max value, switched to pr_err_once to
>> avoid log flood, switched to sizeof(array) per private suggestion.
>> ---
>>  drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
>>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  | 2 ++
>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> index 035c351f47c5..db6d9336b80d 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> @@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
>>  {
>> struct kfd_dev *dev = container_of(work, struct kfd_dev,
>> interrupt_work);
>> +   uint32_t ih_ring_entry[KFD_MAX_RING_ENTRY_SIZE];
>>
>> -   uint32_t ih_ring_entry[DIV_ROUND_UP(
>> -   dev->device_info->ih_ring_entry_size,
>> -   sizeof(uint32_t))];
>> +   if (dev->device_info->ih_ring_entry_size > sizeof(ih_ring_entry)) {
>> +   dev_err_once(kfd_chardev(), "Ring entry too small\n");
>> +   return;
>> +   }
>>
>> while (dequeue_ih_ring_entry(dev, ih_ring_entry))
>> dev->device_info->event_interrupt_class->interrupt_wq(dev,
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
>> b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> index 96a9cc0f02c9..a90db05dfe61 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
>> @@ -39,6 +39,8 @@
>>
>>  #include "amd_shared.h"
>>
>> +#define KFD_MAX_RING_ENTRY_SIZE8
>> +
>>  #define KFD_SYSFS_FILE_MODE 0444
>>
>>  #define KFD_MMAP_DOORBELL_MASK 0x8ull
>> --
>> 2.14.3
>>
>
>
>
> --
> Kees Cook
> Pixel Security
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx