Re: release ex mode after hw_init

2017-11-08 Thread Oded Gabbay
Yes, that's fine now

On Mon, Nov 6, 2017 at 6:01 PM, Felix Kuehling  wrote:
> [+Oded]
>
> Hi Pixel,
>
> Thanks, this looks a lot cleaner. The series is Reviewed-by: Felix
> Kuehling . Oded, are you OK with this as well?
>
> Regards,
>   Felix
>
>
> On 2017-11-06 03:18 AM, Pixel Ding wrote:
>> Hi Felix,
>>
>> Please review.
>>
>> [PATCH 1/2] drm/amdkfd: initialise kfd inside amdgpu_device_init
>> As you suggested, move kfd init/fini inside amdgpu_device_init.
>> Other changes for KFD interfaces are dropped.
>>
>> [PATCH 2/2] drm/amdgpu: release exclusive mode after hw_init
>>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 1/1] drm/amdkfd: CWSR and trap handler support

2017-11-08 Thread Oded Gabbay
Yes, that would be helpful to review.
I assume the asm file provided is just a reference code and doesn't
need to be in the kernel tree for this to work, correct ?


On Thu, Nov 9, 2017 at 4:46 AM, Felix Kuehling  wrote:
> I'll probably need a v2 of this patch. #include  should
> not be needed. That's a leftover from some late cleanup.
>
> This change also ended up a bit big after squashing about 12 changes and
> fixes, and adding more cleanups on top of that. Let me know you want me
> to split it. I'm thinking this may make sense:
>
>  1. Add trap handler .asm file
>  2. Implement CWSR support
>  3. Implement user mode trap handler support
>
> I also pushed an updated kfd_ioctl.h to the Thunk github WIP branch.
>
> Regards,
>   Felix
>
>
> On 2017-11-08 09:29 PM, Felix Kuehling wrote:
>> From: shaoyunl 
>>
>> CWSR = compute wave save restore
>>
>> This hardware feature allows the GPU to preempt shader execution in
>> the middle of a compute wave, save the state and restore it later
>> to resume execution.
>>
>> This feature requires help from a trap handler, which is like an
>> interrupt handler running on the compute unit. The trap handler is
>> written mostly by the hardware team. It's provided as pre-compiled
>> shader code with the SP3 assembly source code as reference.
>>
>> Memory for saving the state is allocated per queue in user mode and
>> the address and size passed to the create_queue ioctl. The size
>> depends on the number of waves that can be in flight simultaneously
>> on a given ASIC.
>>
>> A second-level user mode trap handler can be installed. The CWSR trap
>> handler jumps to the secondary trap handler conditionally for any
>> conditions not handled by it. This can be used e.g. for debugging or
>> catching math exceptions.
>>
>> Signed-off-by: Shaoyun.liu 
>> Signed-off-by: Jay Cornwall 
>> Signed-off-by: Yong Zhao 
>> Signed-off-by: Felix Kuehling 
>> ---
>>  .../gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm  | 1384 
>> 
>>  drivers/gpu/drm/amd/amdkfd/kfd_chardev.c   |   44 +-
>>  drivers/gpu/drm/amd/amdkfd/kfd_device.c|   24 +-
>>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c  |   28 +
>>  .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.h  |5 +
>>  drivers/gpu/drm/amd/amdkfd/kfd_module.c|4 +
>>  drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c|   27 +
>>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h  |   31 +-
>>  drivers/gpu/drm/amd/amdkfd/kfd_process.c   |   89 +-
>>  .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c |4 +-
>>  include/uapi/linux/kfd_ioctl.h |   15 +-
>>  11 files changed, 1644 insertions(+), 11 deletions(-)
>>  create mode 100644 drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm 
>> b/drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm
>> new file mode 100644
>> index 000..751cc2e
>> --- /dev/null
>> +++ b/drivers/gpu/drm/amd/amdkfd/cwsr_trap_handler_gfx8.asm
>> @@ -0,0 +1,1384 @@
>> +/*
>> + * Copyright 2015-2017 Advanced Micro Devices, Inc.
>> + *
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the 
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be included 
>> in
>> + * all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +#if 0
>> +HW (VI) source code for CWSR trap handler
>> +#Version 18 + multiple trap handler
>> +
>> +// this performance-optimal version was originally from Seven Xu at SRDC
>> +
>> +// Revison #18   --...
>> +/* Rev History
>> +** #1. Branch from gc dv.   
>> //gfxip/gfx8/main/src/test/suites/block/cs/sr/cs_trap_handler.sp3#1,#50, 
>> #51, #52-53(Skip, Already Fixed by PV), #54-56(merged),#57-58(mergerd, 
>> skiped-already fixed by PV)
>> +** #4. SR Memory Layout:
>> +** 1. VGPR-SGPR-HWREG-{LDS}
>> +** 2. tba_hi.bits.26 - 

Re: [PATCH 2/2] drm/amdkfd: Use order_base_2 to get log2 of buffes sizes

2017-11-08 Thread Oded Gabbay
Thanks,
Applied to -next

On Tue, Nov 7, 2017 at 12:04 AM, Deucher, Alexander
 wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Felix Kuehling
>> Sent: Monday, November 06, 2017 2:52 PM
>> To: amd-gfx@lists.freedesktop.org; oded.gab...@gmail.com
>> Cc: Kuehling, Felix
>> Subject: [PATCH 2/2] drm/amdkfd: Use order_base_2 to get log2 of buffes
>> sizes
>>
>> Replace (ffs(size) - 1) with order_base_2(size) as a more straight
>> forward way to get log2 of buffer sizes.
>>
>> Signed-off-by: Felix Kuehling 
>
> Series is:
> Reviewed-by: Alex Deucher 
>
>> ---
>>  drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c | 6 +++---
>>  drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c  | 6 +++---
>>  2 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
>> b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
>> index efed6ef..7aa57ab 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c
>> @@ -183,7 +183,7 @@ static int update_mqd(struct mqd_manager *mm,
>> void *mqd,
>>* Calculating queue size which is log base 2 of actual queue size -1
>>* dwords and another -1 for ffs
>>*/
>> - m->cp_hqd_pq_control |= ffs(q->queue_size / 4) - 1 - 1;
>> + m->cp_hqd_pq_control |= order_base_2(q->queue_size / 4) - 1;
>>   m->cp_hqd_pq_base_lo = lower_32_bits((uint64_t)q-
>> >queue_address >> 8);
>>   m->cp_hqd_pq_base_hi = upper_32_bits((uint64_t)q-
>> >queue_address >> 8);
>>   m->cp_hqd_pq_rptr_report_addr_lo = lower_32_bits((uint64_t)q-
>> >read_ptr);
>> @@ -208,7 +208,7 @@ static int update_mqd_sdma(struct mqd_manager
>> *mm, void *mqd,
>>   struct cik_sdma_rlc_registers *m;
>>
>>   m = get_sdma_mqd(mqd);
>> - m->sdma_rlc_rb_cntl = (ffs(q->queue_size / 4) - 1)
>> + m->sdma_rlc_rb_cntl = order_base_2(q->queue_size / 4)
>>   << SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT |
>>   q->vmid <<
>> SDMA0_RLC0_RB_CNTL__RB_VMID__SHIFT |
>>   1 <<
>> SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_ENABLE__SHIFT |
>> @@ -349,7 +349,7 @@ static int update_mqd_hiq(struct mqd_manager
>> *mm, void *mqd,
>>* Calculating queue size which is log base 2 of actual queue
>>* size -1 dwords
>>*/
>> - m->cp_hqd_pq_control |= ffs(q->queue_size / 4) - 1 - 1;
>> + m->cp_hqd_pq_control |= order_base_2(q->queue_size / 4) - 1;
>>   m->cp_hqd_pq_base_lo = lower_32_bits((uint64_t)q-
>> >queue_address >> 8);
>>   m->cp_hqd_pq_base_hi = upper_32_bits((uint64_t)q-
>> >queue_address >> 8);
>>   m->cp_hqd_pq_rptr_report_addr_lo = lower_32_bits((uint64_t)q-
>> >read_ptr);
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c
>> b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c
>> index 85e1b67..2ba7cea 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c
>> @@ -121,7 +121,7 @@ static int __update_mqd(struct mqd_manager *mm,
>> void *mqd,
>>   m->cp_hqd_pq_control = 5 <<
>> CP_HQD_PQ_CONTROL__RPTR_BLOCK_SIZE__SHIFT |
>>   atc_bit << CP_HQD_PQ_CONTROL__PQ_ATC__SHIFT
>> |
>>   mtype << CP_HQD_PQ_CONTROL__MTYPE__SHIFT;
>> - m->cp_hqd_pq_control |= ffs(q->queue_size / 4) - 1 - 1;
>> + m->cp_hqd_pq_control |= order_base_2(q->queue_size / 4) - 1;
>>   pr_debug("cp_hqd_pq_control 0x%x\n", m->cp_hqd_pq_control);
>>
>>   m->cp_hqd_pq_base_lo = lower_32_bits((uint64_t)q-
>> >queue_address >> 8);
>> @@ -151,7 +151,7 @@ static int __update_mqd(struct mqd_manager *mm,
>> void *mqd,
>>* is safe, giving a maximum field value of 0xA.
>>*/
>>   m->cp_hqd_eop_control |= min(0xA,
>> - ffs(q->eop_ring_buffer_size / 4) - 1 - 1);
>> + order_base_2(q->eop_ring_buffer_size / 4) - 1);
>>   m->cp_hqd_eop_base_addr_lo =
>>   lower_32_bits(q->eop_ring_buffer_address >> 8);
>>   m->cp_hqd_eop_base_addr_hi =
>> @@ -287,7 +287,7 @@ static int update_mqd_sdma(struct mqd_manager
>> *mm, void *mqd,
>>   struct vi_sdma_mqd *m;
>>
>>   m = get_sdma_mqd(mqd);
>> - m->sdmax_rlcx_rb_cntl = (ffs(q->queue_size / 4) - 1)
>> + m->sdmax_rlcx_rb_cntl = order_base_2(q->queue_size / 4)
>>   << SDMA0_RLC0_RB_CNTL__RB_SIZE__SHIFT |
>>   q->vmid << SDMA0_RLC0_RB_CNTL__RB_VMID__SHIFT |
>>   1 <<
>> SDMA0_RLC0_RB_CNTL__RPTR_WRITEBACK_ENABLE__SHIFT |
>> --
>> 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

Re: [PATCH] drm/amdgpu: Remove check which is not valid for certain VBIOS

2017-11-08 Thread Wang, Ken
It fixes some headless board VBIOS which will be failed to load.


From: Alex Deucher 
Sent: Wednesday, November 8, 2017 10:38:37 PM
To: Wang, Ken
Cc: amd-gfx list
Subject: Re: [PATCH] drm/amdgpu: Remove check which is not valid for certain 
VBIOS

On Wed, Nov 8, 2017 at 1:49 AM,   wrote:
> From: Ken Wang 

What cases does this fix?  I'm guessing VFCT or some other platform
method for getting the vbios?

Acked-by: Alex Deucher 

>
> Signed-off-by: Ken Wang 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> index c21adf6..057e1ec 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> @@ -59,12 +59,6 @@ static bool check_atom_bios(uint8_t *bios, size_t size)
> return false;
> }
>
> -   tmp = bios[0x18] | (bios[0x19] << 8);
> -   if (bios[tmp + 0x14] != 0x0) {
> -   DRM_INFO("Not an x86 BIOS ROM\n");
> -   return false;
> -   }
> -
> bios_header_start = bios[0x48] | (bios[0x49] << 8);
> if (!bios_header_start) {
> DRM_INFO("Can't locate bios header\n");
> --
> 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: [RFC 0/7] UVD support for SI in amdgpu

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 5:38 PM, Piotr Redlewski  wrote:
> Hi,
>
> Following series implements UVD support for SI in amdgpu driver. Code is based
> on CIK's UVD support in amdgpu and SI's UVD support in radeon drivers. To 
> work,
> it requires tahiti uvd firmware with added header - I've created simple script
> to produce exactly this, so if anyone is interested it can be found here:
> https://gist.github.com/anonymous/6d974a970340f7f64b6fcc4f95267e43
>
> Code is based on amd-staging-drm-next branch in Alex's tree. After applying
> these patches, uvd boots up and seems to work ok. I've tested it with 
> vdpauinfo
> and mpv.
>
> Some comments/issues for the patches:
> 1. To make uvd work, I had to bring back fb location programming. Using 
> location
> programmed by vbios, vram location is not available for uvd mc (at least on my
> machine) due to too wide address. Starting address is 40-bit long for fb, but
> uvd mc supports only 32-bits (judging by comments in amdgpu code and actual 
> code
> in radeon driver)

Something else must be going on.  The vram location is irrelevant with
respect to the limitations of UVD.  I think the limitations with UVD
are more to do with the location of the active buffers relative to
each other rather than the absolute location of some aperture in the
GPU's address space.  CI has the same limitation as I recall so there
is probably a bug somewhere.  Windows has used the fb location as set
by the vbios since evergreen, so it definitely should work.

> 2. I don't know why, but I couldn't get the uvd to boot without setting uvd mc
> offsets before starting other engines. Because of that I set it in .sw_init
> function. In my opinion this should be fixed as it generally doesn't follow
> amdgpu driver architecture (hardware setup during software setup stage) and
> probably will break suspending and resume (I didn't test it). As I mentioned,
> I couldn't figure out why this is happening, so I count on help with finding 
> fix
> for this.
> 3. I found some redefinitions in include/asic_reg/uvd/uvd_4_0_sh_mask.h. I 
> guess
> this file is generated, so fix should be made wherever it is generated from. 
> For
> now I removed offending lines just to silence the compiler warnings.
> 4. I'm not sure whether I choose the right version for the uvd. Existing code 
> in
> si.c suggested that it should be 3.1, however I went with the 4.0, because for
> this version there are available new style headers.

I think the regs are pretty much the same between 3.x and 4.x so it
should be fine.

Alex


>
> Regards,
> Piotr
>
> Piotr Redlewski (7):
>   drm/amdgpu: remove duplicated definitions of some of the SI registers
>   drm/amdgpu/uvd4: fix some register's mask and shift definitions
>   drm/amdgpu/gmc6: don't use vram location programmed by the vbios
>   drm/amdgpu/uvd4: add early init stage functions for uvd 4.0
>   drm/amdgpu/uvd4: add sw init and fini stages' functions for uvd 4.0
>   drm/amdgpu/uvd4: add hardware specific functions for uvd 4.0
>   drm/amdgpu: enable UVD for SI
>
>  drivers/gpu/drm/amd/amdgpu/Makefile|   3 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   6 +
>  drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  14 +
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 114 ++-
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.h  |   5 +
>  drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   7 -
>  drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  |  40 +-
>  drivers/gpu/drm/amd/amdgpu/si.c| 256 ++-
>  drivers/gpu/drm/amd/amdgpu/si_ih.c |   3 +
>  drivers/gpu/drm/amd/amdgpu/sid.h   |  52 +-
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c  | 810 
> +
>  drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h  |  29 +
>  .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |   2 -
>  13 files changed, 1273 insertions(+), 68 deletions(-)
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
>  create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h
>
> --
> 2.15.0
>
> ___
> 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


[pull] amdgpu drm-next-4.15

2017-11-08 Thread Alex Deucher
Hi Dave,

A few more fixes for 4.15.

The following changes since commit d65d31388a23b14df9494135ad6c6549a59a3caa:

  Merge tag 'drm-misc-next-fixes-2017-11-07' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-08 05:22:49 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.15

for you to fetch changes up to cdd9a8b8599b952e2b39763090689ec2ad8e40c3:

  drm/amdgpu: use irq-safe lock for kiq->ring_lock (2017-11-08 17:55:14 -0500)


Dan Carpenter (2):
  drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
  drm/amdgpu: Potential uninitialized variable in 
amdgpu_vm_update_directories()

Evan Quan (1):
  drm/amd/powerplay: suppress KASAN out of bounds warning in 
vega10_populate_all_memory_levels

Nicolas Iooss (1):
  drm/amd/powerplay: initialize a variable before using it

Pixel Ding (1):
  drm/amdgpu: bypass lru touch for KIQ ring submission

Roger He (1):
  drm/amd/amdgpu: fix evicted VRAM bo adjudgement condition

pding (1):
  drm/amdgpu: use irq-safe lock for kiq->ring_lock

 drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c   |  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|  5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c   | 10 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c |  6 ++
 6 files changed, 17 insertions(+), 11 deletions(-)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[RFC 1/7] drm/amdgpu: remove duplicated definitions of some of the SI registers

2017-11-08 Thread Piotr Redlewski
Some of the registers are defined both in the sid.h and in the new style
headers. Removed definitions from the sid.h

Signed-off-by: Piotr Redlewski 
---
 drivers/gpu/drm/amd/amdgpu/si.c|  1 +
 drivers/gpu/drm/amd/amdgpu/si_ih.c |  3 +++
 drivers/gpu/drm/amd/amdgpu/sid.h   | 16 
 3 files changed, 4 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index 8284d5dbfc30..2ac1c2be8ca4 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -42,6 +42,7 @@
 #include "dce_virtual.h"
 #include "gca/gfx_6_0_d.h"
 #include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
 #include "gmc/gmc_6_0_d.h"
 #include "dce/dce_6_0_d.h"
 #include "uvd/uvd_4_0_d.h"
diff --git a/drivers/gpu/drm/amd/amdgpu/si_ih.c 
b/drivers/gpu/drm/amd/amdgpu/si_ih.c
index d2c6b80309c8..ca53ff7e3c56 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_ih.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_ih.c
@@ -26,6 +26,9 @@
 #include "sid.h"
 #include "si_ih.h"
 
+#include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
+
 static void si_ih_set_interrupt_funcs(struct amdgpu_device *adev);
 
 static void si_ih_enable_interrupts(struct amdgpu_device *adev)
diff --git a/drivers/gpu/drm/amd/amdgpu/sid.h b/drivers/gpu/drm/amd/amdgpu/sid.h
index c57eff159374..59f8fc944ecb 100644
--- a/drivers/gpu/drm/amd/amdgpu/sid.h
+++ b/drivers/gpu/drm/amd/amdgpu/sid.h
@@ -2320,10 +2320,6 @@
 #   define NI_INPUT_GAMMA_XVYCC_2223
 #   define NI_OVL_INPUT_GAMMA_MODE(x)  (((x) & 0x3) << 4)
 
-#define IH_RB_WPTR__RB_OVERFLOW_MASK   0x1
-#define IH_RB_CNTL__WPTR_OVERFLOW_CLEAR_MASK 0x8000
-#define SRBM_STATUS__IH_BUSY_MASK  0x2
-#define SRBM_SOFT_RESET__SOFT_RESET_IH_MASK0x400
 
 #defineBLACKOUT_MODE_MASK  0x0007
 #defineVGA_RENDER_CONTROL  0xC0
@@ -2411,16 +2407,6 @@
 #define MC_SEQ_MISC0__MT__HBM0x6000
 #define MC_SEQ_MISC0__MT__DDR3   0xB000
 
-#define SRBM_STATUS__MCB_BUSY_MASK 0x200
-#define SRBM_STATUS__MCB_BUSY__SHIFT 0x9
-#define SRBM_STATUS__MCB_NON_DISPLAY_BUSY_MASK 0x400
-#define SRBM_STATUS__MCB_NON_DISPLAY_BUSY__SHIFT 0xa
-#define SRBM_STATUS__MCC_BUSY_MASK 0x800
-#define SRBM_STATUS__MCC_BUSY__SHIFT 0xb
-#define SRBM_STATUS__MCD_BUSY_MASK 0x1000
-#define SRBM_STATUS__MCD_BUSY__SHIFT 0xc
-#define SRBM_STATUS__VMC_BUSY_MASK 0x100
-#define SRBM_STATUS__VMC_BUSY__SHIFT 0x8
 
 
 #define GRBM_STATUS__GUI_ACTIVE_MASK 0x8000
@@ -2447,8 +2433,6 @@
 
 #define PCIE_BUS_CLK1
 #define TCLK(PCIE_BUS_CLK / 10)
-#define CC_DRM_ID_STRAPS__ATI_REV_ID_MASK  0xf000
-#define CC_DRM_ID_STRAPS__ATI_REV_ID__SHIFT 0x1c
 #definePCIE_PORT_INDEX 0xe
 #definePCIE_PORT_DATA  0xf
 #define EVERGREEN_PIF_PHY0_INDEX0x8
-- 
2.15.0

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


[RFC 0/7] UVD support for SI in amdgpu

2017-11-08 Thread Piotr Redlewski
Hi,

Following series implements UVD support for SI in amdgpu driver. Code is based
on CIK's UVD support in amdgpu and SI's UVD support in radeon drivers. To work,
it requires tahiti uvd firmware with added header - I've created simple script
to produce exactly this, so if anyone is interested it can be found here:
https://gist.github.com/anonymous/6d974a970340f7f64b6fcc4f95267e43

Code is based on amd-staging-drm-next branch in Alex's tree. After applying
these patches, uvd boots up and seems to work ok. I've tested it with vdpauinfo
and mpv.

Some comments/issues for the patches:
1. To make uvd work, I had to bring back fb location programming. Using location
programmed by vbios, vram location is not available for uvd mc (at least on my
machine) due to too wide address. Starting address is 40-bit long for fb, but
uvd mc supports only 32-bits (judging by comments in amdgpu code and actual code
in radeon driver)
2. I don't know why, but I couldn't get the uvd to boot without setting uvd mc
offsets before starting other engines. Because of that I set it in .sw_init
function. In my opinion this should be fixed as it generally doesn't follow
amdgpu driver architecture (hardware setup during software setup stage) and
probably will break suspending and resume (I didn't test it). As I mentioned,
I couldn't figure out why this is happening, so I count on help with finding fix
for this.
3. I found some redefinitions in include/asic_reg/uvd/uvd_4_0_sh_mask.h. I guess
this file is generated, so fix should be made wherever it is generated from. For
now I removed offending lines just to silence the compiler warnings.
4. I'm not sure whether I choose the right version for the uvd. Existing code in
si.c suggested that it should be 3.1, however I went with the 4.0, because for
this version there are available new style headers.

Regards,
Piotr

Piotr Redlewski (7):
  drm/amdgpu: remove duplicated definitions of some of the SI registers
  drm/amdgpu/uvd4: fix some register's mask and shift definitions
  drm/amdgpu/gmc6: don't use vram location programmed by the vbios
  drm/amdgpu/uvd4: add early init stage functions for uvd 4.0
  drm/amdgpu/uvd4: add sw init and fini stages' functions for uvd 4.0
  drm/amdgpu/uvd4: add hardware specific functions for uvd 4.0
  drm/amdgpu: enable UVD for SI

 drivers/gpu/drm/amd/amdgpu/Makefile|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h   |   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c|  14 +
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c  | 114 ++-
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.h  |   5 +
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c  |   7 -
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c  |  40 +-
 drivers/gpu/drm/amd/amdgpu/si.c| 256 ++-
 drivers/gpu/drm/amd/amdgpu/si_ih.c |   3 +
 drivers/gpu/drm/amd/amdgpu/sid.h   |  52 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c  | 810 +
 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h  |  29 +
 .../drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h |   2 -
 13 files changed, 1273 insertions(+), 68 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h

-- 
2.15.0

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


[RFC 2/7] drm/amdgpu/uvd4: fix some register's mask and shift definitions

2017-11-08 Thread Piotr Redlewski
UVD_LMI_CTRL__RFU_MASK and UVD_LMI_CTRL__RFU__SHIFT are defined twice,
each time with different values

Signed-off-by: Piotr Redlewski 
---
 drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h 
b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h
index 8ee3149df5b7..2ef1273e65ab 100644
--- a/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h
+++ b/drivers/gpu/drm/amd/include/asic_reg/uvd/uvd_4_0_sh_mask.h
@@ -340,8 +340,6 @@
 #define UVD_LMI_CTRL__REQ_MODE_MASK 0x0200L
 #define UVD_LMI_CTRL__REQ_MODE__SHIFT 0x0009
 #define UVD_LMI_CTRL__RFU_MASK 0xf800L
-#define UVD_LMI_CTRL__RFU_MASK 0xfc00L
-#define UVD_LMI_CTRL__RFU__SHIFT 0x001a
 #define UVD_LMI_CTRL__RFU__SHIFT 0x001b
 #define UVD_LMI_CTRL__VCPU_DATA_COHERENCY_EN_MASK 0x0020L
 #define UVD_LMI_CTRL__VCPU_DATA_COHERENCY_EN__SHIFT 0x0015
-- 
2.15.0

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


[RFC 3/7] drm/amdgpu/gmc6: don't use vram location programmed by the vbios

2017-11-08 Thread Piotr Redlewski
On SI chips, fb location programmed by the vbios (40-bit address) is out of
reach of the UVD memory controller, which supports only 32-bits.

This partially reverts following commits:
commit e4f6b39e8bcd ("drm/amdgpu: remove *_mc_access from display funcs")
commit 71086a3e8470 ("drm/amdgpu/gmc6: drop fb location programming")
commit ba3a5b83dd9b ("drm/amdgpu/gmc6: use the vram location programmed by the 
vbios")

Signed-off-by: Piotr Redlewski 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h |   6 ++
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c| 114 ++-
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.h|   5 ++
 drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c|  40 ---
 4 files changed, 155 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 4069a3b2f55f..0bd916bd4c08 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -262,6 +262,12 @@ struct amdgpu_audio {
int num_pins;
 };
 
+struct amdgpu_mode_mc_save {
+   u32 vga_render_control;
+   u32 vga_hdp_control;
+   bool crtc_enabled[AMDGPU_MAX_CRTCS];
+};
+
 struct amdgpu_display_funcs {
/* display watermarks */
void (*bandwidth_update)(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index bd2c4f727df6..b9549806abc1 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -393,8 +393,118 @@ static u32 dce_v6_0_hpd_get_gpio_reg(struct amdgpu_device 
*adev)
return mmDC_GPIO_HPD_A;
 }
 
-static void dce_v6_0_set_vga_render_state(struct amdgpu_device *adev,
- bool render)
+static u32 evergreen_get_vblank_counter(struct amdgpu_device *adev, int crtc)
+{
+   if (crtc >= adev->mode_info.num_crtc)
+   return 0;
+   else
+   return RREG32(mmCRTC_STATUS_FRAME_COUNT + crtc_offsets[crtc]);
+}
+
+void dce_v6_0_stop_mc_access(struct amdgpu_device *adev,
+struct amdgpu_mode_mc_save *save)
+{
+   u32 crtc_enabled, tmp, frame_count;
+   int i, j;
+
+   save->vga_render_control = RREG32(mmVGA_RENDER_CONTROL);
+   save->vga_hdp_control = RREG32(mmVGA_HDP_CONTROL);
+
+   /* disable VGA render */
+   WREG32(mmVGA_RENDER_CONTROL, 0);
+
+   /* blank the display controllers */
+   for (i = 0; i < adev->mode_info.num_crtc; i++) {
+   crtc_enabled = RREG32(mmCRTC_CONTROL + crtc_offsets[i]) & 
CRTC_CONTROL__CRTC_MASTER_EN_MASK;
+   if (crtc_enabled) {
+   save->crtc_enabled[i] = true;
+   tmp = RREG32(mmCRTC_BLANK_CONTROL + crtc_offsets[i]);
+
+   if (!(tmp & 
CRTC_BLANK_CONTROL__CRTC_BLANK_DATA_EN_MASK)) {
+   dce_v6_0_vblank_wait(adev, i);
+   WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 1);
+   tmp |= 
CRTC_BLANK_CONTROL__CRTC_BLANK_DATA_EN_MASK;
+   WREG32(mmCRTC_BLANK_CONTROL + crtc_offsets[i], 
tmp);
+   WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 0);
+   }
+   /* wait for the next frame */
+   frame_count = evergreen_get_vblank_counter(adev, i);
+   for (j = 0; j < adev->usec_timeout; j++) {
+   if (evergreen_get_vblank_counter(adev, i) != 
frame_count)
+   break;
+   udelay(1);
+   }
+
+   /* XXX this is a hack to avoid strange behavior with 
EFI on certain systems */
+   WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 1);
+   tmp = RREG32(mmCRTC_CONTROL + crtc_offsets[i]);
+   tmp &= ~CRTC_CONTROL__CRTC_MASTER_EN_MASK;
+   WREG32(mmCRTC_CONTROL + crtc_offsets[i], tmp);
+   WREG32(mmCRTC_UPDATE_LOCK + crtc_offsets[i], 0);
+   save->crtc_enabled[i] = false;
+   /* * */
+   } else {
+   save->crtc_enabled[i] = false;
+   }
+   }
+}
+
+void dce_v6_0_resume_mc_access(struct amdgpu_device *adev,
+  struct amdgpu_mode_mc_save *save)
+{
+   u32 tmp;
+   int i, j;
+
+   /* update crtc base addresses */
+   for (i = 0; i < adev->mode_info.num_crtc; i++) {
+   WREG32(mmGRPH_PRIMARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
+  upper_32_bits(adev->mc.vram_start));
+   WREG32(mmGRPH_SECONDARY_SURFACE_ADDRESS_HIGH + crtc_offsets[i],
+  upper_32_bits(adev->mc.vram_start));
+   

[RFC 7/7] drm/amdgpu: enable UVD for SI

2017-11-08 Thread Piotr Redlewski
Signed-off-by: Piotr Redlewski 
---
 drivers/gpu/drm/amd/amdgpu/Makefile | 3 ++-
 drivers/gpu/drm/amd/amdgpu/si.c | 5 +++--
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile 
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 6a025c476b37..5c1bae35d2aa 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -38,7 +38,8 @@ amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o 
kv_dpm.o \
ci_smc.o ci_dpm.o dce_v8_0.o gfx_v7_0.o cik_sdma.o uvd_v4_2.o 
vce_v2_0.o \
amdgpu_amdkfd_gfx_v7.o
 
-amdgpu-$(CONFIG_DRM_AMDGPU_SI)+= si.o gmc_v6_0.o gfx_v6_0.o si_ih.o si_dma.o 
dce_v6_0.o si_dpm.o si_smc.o
+amdgpu-$(CONFIG_DRM_AMDGPU_SI)+= si.o gmc_v6_0.o gfx_v6_0.o si_ih.o si_dma.o \
+   dce_v6_0.o si_dpm.o si_smc.o uvd_v4_0.o
 
 amdgpu-y += \
vi.o mxgpu_vi.o nbio_v6_1.o soc15.o mxgpu_ai.o nbio_v7_0.o
diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index bc6fd1ff4f86..0e0445602215 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -38,6 +38,7 @@
 #include "gmc_v6_0.h"
 #include "si_dma.h"
 #include "dce_v6_0.h"
+#include "uvd_v4_0.h"
 #include "si.h"
 #include "dce_virtual.h"
 #include "gca/gfx_6_0_d.h"
@@ -2214,7 +2215,7 @@ int si_set_ip_blocks(struct amdgpu_device *adev)
amdgpu_ip_block_add(adev, _v6_0_ip_block);
amdgpu_ip_block_add(adev, _v6_0_ip_block);
amdgpu_ip_block_add(adev, _dma_ip_block);
-   /* amdgpu_ip_block_add(adev, _v3_1_ip_block); */
+   amdgpu_ip_block_add(adev, _v4_0_ip_block);
/* amdgpu_ip_block_add(adev, _v1_0_ip_block); */
break;
case CHIP_OLAND:
@@ -2228,7 +2229,7 @@ int si_set_ip_blocks(struct amdgpu_device *adev)
amdgpu_ip_block_add(adev, _v6_4_ip_block);
amdgpu_ip_block_add(adev, _v6_0_ip_block);
amdgpu_ip_block_add(adev, _dma_ip_block);
-   /* amdgpu_ip_block_add(adev, _v3_1_ip_block); */
+   amdgpu_ip_block_add(adev, _v4_0_ip_block);
/* amdgpu_ip_block_add(adev, _v1_0_ip_block); */
break;
case CHIP_HAINAN:
-- 
2.15.0

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


[RFC 6/7] drm/amdgpu/uvd4: add hardware specific functions for uvd 4.0

2017-11-08 Thread Piotr Redlewski
Add logic for starting, stopping, suspending and resuming uvd block

Signed-off-by: Piotr Redlewski 
---
 drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c |   7 -
 drivers/gpu/drm/amd/amdgpu/si.c   | 250 -
 drivers/gpu/drm/amd/amdgpu/sid.h  |  22 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c | 488 ++
 4 files changed, 736 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
index 9430d4809b53..0744117ee7d2 100644
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -1695,13 +1695,6 @@ static void gfx_v6_0_gpu_init(struct amdgpu_device *adev)
WREG32(mmDMA_TILING_CONFIG + DMA0_REGISTER_OFFSET, gb_addr_config);
WREG32(mmDMA_TILING_CONFIG + DMA1_REGISTER_OFFSET, gb_addr_config);
 
-#if 0
-   if (adev->has_uvd) {
-   WREG32(mmUVD_UDEC_ADDR_CONFIG, gb_addr_config);
-   WREG32(mmUVD_UDEC_DB_ADDR_CONFIG, gb_addr_config);
-   WREG32(mmUVD_UDEC_DBW_ADDR_CONFIG, gb_addr_config);
-   }
-#endif
gfx_v6_0_tiling_mode_table_init(adev);
 
gfx_v6_0_setup_rb(adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/si.c b/drivers/gpu/drm/amd/amdgpu/si.c
index 2ac1c2be8ca4..bc6fd1ff4f86 100644
--- a/drivers/gpu/drm/amd/amdgpu/si.c
+++ b/drivers/gpu/drm/amd/amdgpu/si.c
@@ -971,6 +971,28 @@ static void si_smc_wreg(struct amdgpu_device *adev, u32 
reg, u32 v)
spin_unlock_irqrestore(>smc_idx_lock, flags);
 }
 
+static u32 si_uvd_ctx_rreg(struct amdgpu_device *adev, u32 reg)
+{
+   unsigned long flags;
+   u32 r;
+
+   spin_lock_irqsave(>uvd_ctx_idx_lock, flags);
+   WREG32(mmUVD_CTX_INDEX, ((reg) & 0x1ff));
+   r = RREG32(mmUVD_CTX_DATA);
+   spin_unlock_irqrestore(>uvd_ctx_idx_lock, flags);
+   return r;
+}
+
+static void si_uvd_ctx_wreg(struct amdgpu_device *adev, u32 reg, u32 v)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>uvd_ctx_idx_lock, flags);
+   WREG32(mmUVD_CTX_INDEX, ((reg) & 0x1ff));
+   WREG32(mmUVD_CTX_DATA, (v));
+   spin_unlock_irqrestore(>uvd_ctx_idx_lock, flags);
+}
+
 static struct amdgpu_allowed_register_entry si_allowed_read_registers[] = {
{GRBM_STATUS},
{GB_ADDR_CONFIG},
@@ -1219,9 +1241,231 @@ static u32 si_get_xclk(struct amdgpu_device *adev)
return reference_clock;
 }
 
-//xxx:not implemented
+
+static unsigned si_uvd_calc_upll_post_div(unsigned vco_freq,
+ unsigned target_freq,
+ unsigned pd_min,
+ unsigned pd_even)
+{
+   unsigned post_div = vco_freq / target_freq;
+
+   /* adjust to post divider minimum value */
+   if (post_div < pd_min)
+   post_div = pd_min;
+
+   /* we alway need a frequency less than or equal the target */
+   if ((vco_freq / post_div) > target_freq)
+   post_div += 1;
+
+   /* post dividers above a certain value must be even */
+   if (post_div > pd_even && post_div % 2)
+   post_div += 1;
+
+   return post_div;
+}
+
+/**
+ * si_uvd_calc_upll_dividers - calc UPLL clock dividers
+ *
+ * @adev: amdgpu_device pointer
+ * @vclk: wanted VCLK
+ * @dclk: wanted DCLK
+ * @vco_min: minimum VCO frequency
+ * @vco_max: maximum VCO frequency
+ * @fb_factor: factor to multiply vco freq with
+ * @fb_mask: limit and bitmask for feedback divider
+ * @pd_min: post divider minimum
+ * @pd_max: post divider maximum
+ * @pd_even: post divider must be even above this value
+ * @optimal_fb_div: resulting feedback divider
+ * @optimal_vclk_div: resulting vclk post divider
+ * @optimal_dclk_div: resulting dclk post divider
+ *
+ * Calculate dividers for UVDs UPLL (R6xx-SI, except APUs).
+ * Returns zero on success -EINVAL on error.
+ */
+int si_uvd_calc_upll_dividers(struct amdgpu_device *adev,
+ unsigned vclk, unsigned dclk,
+ unsigned vco_min, unsigned vco_max,
+ unsigned fb_factor, unsigned fb_mask,
+ unsigned pd_min, unsigned pd_max,
+ unsigned pd_even,
+ unsigned *optimal_fb_div,
+ unsigned *optimal_vclk_div,
+ unsigned *optimal_dclk_div)
+{
+   unsigned vco_freq, ref_freq = adev->clock.spll.reference_freq;
+
+   /* start off with something large */
+   unsigned optimal_score = ~0;
+
+   /* loop through vco from low to high */
+   vco_min = max(max(vco_min, vclk), dclk);
+   for (vco_freq = vco_min; vco_freq <= vco_max; vco_freq += 100) {
+
+   uint64_t fb_div = (uint64_t)vco_freq * fb_factor;
+   unsigned vclk_div, dclk_div, score;
+
+   do_div(fb_div, ref_freq);
+
+

[RFC 5/7] drm/amdgpu/uvd4: add sw init and fini stages' functions for uvd 4.0

2017-11-08 Thread Piotr Redlewski
Load firmware and initialize uvd ring

Signed-off-by: Piotr Redlewski 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 14 
 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c   | 40 +
 2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index be607b2be4e9..59ae2f2012ad 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -52,6 +52,9 @@
 #define FW_1_66_16 ((1 << 24) | (66 << 16) | (16 << 8))
 
 /* Firmware Names */
+#ifdef CONFIG_DRM_AMDGPU_SI
+#define FIRMWARE_TAHITI"radeon/tahiti_uvd.bin"
+#endif
 #ifdef CONFIG_DRM_AMDGPU_CIK
 #define FIRMWARE_BONAIRE   "radeon/bonaire_uvd.bin"
 #define FIRMWARE_KABINI"radeon/kabini_uvd.bin"
@@ -94,6 +97,9 @@ struct amdgpu_uvd_cs_ctx {
unsigned *buf_sizes;
 };
 
+#ifdef CONFIG_DRM_AMDGPU_SI
+MODULE_FIRMWARE(FIRMWARE_TAHITI);
+#endif
 #ifdef CONFIG_DRM_AMDGPU_CIK
 MODULE_FIRMWARE(FIRMWARE_BONAIRE);
 MODULE_FIRMWARE(FIRMWARE_KABINI);
@@ -126,6 +132,14 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
INIT_DELAYED_WORK(>uvd.idle_work, amdgpu_uvd_idle_work_handler);
 
switch (adev->asic_type) {
+#ifdef CONFIG_DRM_AMDGPU_SI
+   case CHIP_TAHITI:
+   case CHIP_VERDE:
+   case CHIP_PITCAIRN:
+   case CHIP_OLAND:
+   fw_name = FIRMWARE_TAHITI;
+   break;
+#endif
 #ifdef CONFIG_DRM_AMDGPU_CIK
case CHIP_BONAIRE:
fw_name = FIRMWARE_BONAIRE;
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
index 127269a0a90c..cfa6959db43d 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
@@ -91,6 +91,44 @@ static int uvd_v4_0_early_init(void *handle)
return 0;
 }
 
+static int uvd_v4_0_sw_init(void *handle)
+{
+   struct amdgpu_ring *ring;
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+   int r;
+
+   /* UVD TRAP */
+   r = amdgpu_irq_add_id(adev, AMDGPU_IH_CLIENTID_LEGACY, 124, 
>uvd.irq);
+   if (r)
+   return r;
+
+   r = amdgpu_uvd_sw_init(adev);
+   if (r)
+   return r;
+
+   r = amdgpu_uvd_resume(adev);
+   if (r)
+   return r;
+
+   ring = >uvd.ring;
+   sprintf(ring->name, "uvd");
+   r = amdgpu_ring_init(adev, ring, 512, >uvd.irq, 0);
+
+   return r;
+}
+
+static int uvd_v4_0_sw_fini(void *handle)
+{
+   int r;
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   r = amdgpu_uvd_suspend(adev);
+   if (r)
+   return r;
+
+   return amdgpu_uvd_sw_fini(adev);
+}
+
 /**
  * uvd_v4_0_ring_emit_fence - emit an fence & trap command
  *
@@ -229,6 +267,8 @@ static const struct amd_ip_funcs uvd_v4_0_ip_funcs = {
.name = "uvd_v4_0",
.early_init = uvd_v4_0_early_init,
.late_init = NULL,
+   .sw_init = uvd_v4_0_sw_init,
+   .sw_fini = uvd_v4_0_sw_fini,
 };
 
 static const struct amdgpu_ring_funcs uvd_v4_0_ring_funcs = {
-- 
2.15.0

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


[RFC 4/7] drm/amdgpu/uvd4: add early init stage functions for uvd 4.0

2017-11-08 Thread Piotr Redlewski
Add uvd ring and interrupt functions

Signed-off-by: Piotr Redlewski 
---
 drivers/gpu/drm/amd/amdgpu/sid.h  |  14 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c | 282 ++
 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h |  29 
 3 files changed, 319 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
 create mode 100644 drivers/gpu/drm/amd/amdgpu/uvd_v4_0.h

diff --git a/drivers/gpu/drm/amd/amdgpu/sid.h b/drivers/gpu/drm/amd/amdgpu/sid.h
index 59f8fc944ecb..42556e2fafd4 100644
--- a/drivers/gpu/drm/amd/amdgpu/sid.h
+++ b/drivers/gpu/drm/amd/amdgpu/sid.h
@@ -1646,16 +1646,20 @@
 /*
  * PM4
  */
-#define PACKET0(reg, n)((RADEON_PACKET_TYPE0 << 30) |  
\
-(((reg) >> 2) & 0x) |  \
+#define PACKET_TYPE0 0
+#define PACKET_TYPE1 1
+#define PACKET_TYPE2 2
+#define PACKET_TYPE3 3
+
+#define PACKET0(reg, n)((PACKET_TYPE0 << 30) | 
\
+((reg) & 0x) | \
 ((n) & 0x3FFF) << 16)
 #define CP_PACKET2 0x8000
 #definePACKET2_PAD_SHIFT   0
 #definePACKET2_PAD_MASK(0x3fff << 0)
 
 #define PACKET2(v) (CP_PACKET2 | REG_SET(PACKET2_PAD, (v)))
-#define RADEON_PACKET_TYPE3 3
-#define PACKET3(op, n) ((RADEON_PACKET_TYPE3 << 30) |  \
+#define PACKET3(op, n) ((PACKET_TYPE3 << 30) | \
 (((op) & 0xFF) << 8) | \
 ((n) & 0x3FFF) << 16)
 
@@ -2407,8 +2411,6 @@
 #define MC_SEQ_MISC0__MT__HBM0x6000
 #define MC_SEQ_MISC0__MT__DDR3   0xB000
 
-
-
 #define GRBM_STATUS__GUI_ACTIVE_MASK 0x8000
 #define CP_INT_CNTL_RING__TIME_STAMP_INT_ENABLE_MASK 0x400
 #define CP_INT_CNTL_RING0__PRIV_REG_INT_ENABLE_MASK 0x80
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c 
b/drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
new file mode 100644
index ..127269a0a90c
--- /dev/null
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v4_0.c
@@ -0,0 +1,282 @@
+/*
+ * Copyright 2013 Advanced Micro Devices, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors: Christian König 
+ */
+
+#include 
+#include 
+#include "amdgpu.h"
+#include "amdgpu_uvd.h"
+#include "sid.h"
+
+#include "uvd/uvd_4_0_d.h"
+#include "uvd/uvd_4_0_sh_mask.h"
+
+#include "oss/oss_1_0_d.h"
+#include "oss/oss_1_0_sh_mask.h"
+
+#include "bif/bif_3_0_d.h"
+
+static void uvd_v4_0_set_ring_funcs(struct amdgpu_device *adev);
+static void uvd_v4_0_set_irq_funcs(struct amdgpu_device *adev);
+
+/**
+ * uvd_v4_0_ring_get_rptr - get read pointer
+ *
+ * @ring: amdgpu_ring pointer
+ *
+ * Returns the current hardware read pointer
+ */
+static uint64_t uvd_v4_0_ring_get_rptr(struct amdgpu_ring *ring)
+{
+   struct amdgpu_device *adev = ring->adev;
+
+   return RREG32(mmUVD_RBC_RB_RPTR);
+}
+
+/**
+ * uvd_v4_0_ring_get_wptr - get write pointer
+ *
+ * @ring: amdgpu_ring pointer
+ *
+ * Returns the current hardware write pointer
+ */
+static uint64_t uvd_v4_0_ring_get_wptr(struct amdgpu_ring *ring)
+{
+   struct amdgpu_device *adev = ring->adev;
+
+   return RREG32(mmUVD_RBC_RB_WPTR);
+}
+
+/**
+ * uvd_v4_0_ring_set_wptr - set write pointer
+ *
+ * @ring: amdgpu_ring pointer
+ *
+ * Commits the write pointer to the hardware
+ */
+static void uvd_v4_0_ring_set_wptr(struct amdgpu_ring *ring)
+{
+   struct amdgpu_device *adev = ring->adev;
+
+   WREG32(mmUVD_RBC_RB_WPTR, lower_32_bits(ring->wptr));
+}
+
+static int uvd_v4_0_early_init(void *handle)
+{
+   struct amdgpu_device *adev = (struct amdgpu_device *)handle;
+
+   uvd_v4_0_set_ring_funcs(adev);
+   uvd_v4_0_set_irq_funcs(adev);
+
+   return 0;
+}
+
+/**
+ * 

Re: [PATCH v2] amd/display: Fix potential null dereference in dce_calcs.c

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 4:47 PM, Ernst Sjöstrand  wrote:
> Reported by smatch:
> bw_calcs() error: potential null dereference 'data'
>
> Signed-off-by: Ernst Sjöstrand 

Reviewed and pushed.  thanks!

Alex

> ---
> I couldn't use DC_ERROR because the dc_context had the wrong variable
> name. Seems like a larger project to fix...
>
>  drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index 4f8a95368ffc..6347712db834 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -2794,6 +2794,8 @@ bool bw_calcs(struct dc_context *ctx,
>  {
> struct bw_calcs_data *data = kzalloc(sizeof(struct bw_calcs_data),
>  GFP_KERNEL);
> +   if (!data)
> +   return false;
>
> populate_initial_data(pipe, pipe_count, data);
>
> --
> 2.14.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


Applied "ASoC: amd: use do_div rather than 64 bit division to fix 32 bit builds" to the asoc tree

2017-11-08 Thread Mark Brown
The patch

   ASoC: amd: use do_div rather than 64 bit division to fix 32 bit builds

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 7db08b2cb36cbfbcb06c44dc8e48ccb6a119466f Mon Sep 17 00:00:00 2001
From: Guenter Roeck 
Date: Wed, 8 Nov 2017 16:34:54 -0500
Subject: [PATCH] ASoC: amd: use do_div rather than 64 bit division to fix 32
 bit builds

ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!

64-bit divides require special operations to avoid build errors on 32-bit
systems.

[Reword the commit message to make it clearer - Alex]

fixes: 61add8147942 (ASoC: amd: Report accurate hw_ptr during dma)
Signed-off-by: Guenter Roeck 
Reviewed-on: https://chromium-review.googlesource.com/678919
Reviewed-by: Jason Clinton 
Reviewed-on: https://chromium-review.googlesource.com/681618
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/acp-pcm-dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 13d040a4d26f..ef7e98ad960c 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct 
snd_pcm_substream *substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (bytescount > rtd->renderbytescount)
bytescount = bytescount - rtd->renderbytescount;
-   pos =  bytescount % buffersize;
} else {
if (bytescount > rtd->capturebytescount)
bytescount = bytescount - rtd->capturebytescount;
-   pos = bytescount % buffersize;
}
+   pos = do_div(bytescount, buffersize);
return bytes_to_frames(runtime, pos);
 }
 
-- 
2.15.0

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


Re: [PATCH] amd/display: Fix potential null dereference in dce_calcs.c

2017-11-08 Thread Harry Wentland
On 2017-11-08 03:54 PM, Deucher, Alexander wrote:
>> -Original Message-
>> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
>> Of Ernst Sjöstrand
>> Sent: Wednesday, November 08, 2017 3:17 PM
>> To: amd-gfx@lists.freedesktop.org
>> Subject: [PATCH] amd/display: Fix potential null dereference in dce_calcs.c
>>
>> Reported by smatch:
>> bw_calcs() error: potential null dereference 'data'
>>
>> Signed-off-by: Ernst Sjöstrand 
>> ---
>>  drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
>> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
>> index 4f8a95368ffc..64a885195208 100644
>> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
>> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
>> @@ -2794,6 +2794,10 @@ bool bw_calcs(struct dc_context *ctx,
>>  {
>>  struct bw_calcs_data *data = kzalloc(sizeof(struct bw_calcs_data),
>>   GFP_KERNEL);
>> +if (!data) {
>> +DRM_ERROR("Failed to allocate bw_calcs_data\n");
> 
> I think we are trying to keep DRM specifics out of dc as much as possible so 
> drop the error message and just return false.
> 

Alternatively use DC_ERROR() to log, just like you would with DRM_ERROR.

Note that if you trace it you'll go down the rabbit hole that's the DC logger. 
It's still on our list to clean up and route more directly to kernel logging 
functionality. A task for that is in amd/display/TODO.

Thanks for the patch.

Harry

> Thanks!
> 
> Alex
> 
>> +return false;
>> +}
>>
>>  populate_initial_data(pipe, pipe_count, data);
>>
>> --
>> 2.14.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
> 
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


[PATCH] amdgpu/dm: Default PRE_VEGA ASIC support to 'y'

2017-11-08 Thread Harry Wentland
Even though we default PRE_VEGA support to 'n' upstream in amd-staging
we want to keep it enabled by default.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig 
b/drivers/gpu/drm/amd/display/Kconfig
index ec3285f65517..5b124a67404c 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -11,7 +11,7 @@ config DRM_AMD_DC
 
 config DRM_AMD_DC_PRE_VEGA
bool "DC support for Polaris and older ASICs"
-   default n
+   default y
help
  Choose this option to enable the new DC support for older asics
  by default. This includes Polaris, Carrizo, Tonga, Bonaire,
-- 
2.14.1

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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 02:35:05PM -0500, Alex Deucher wrote:
> On Wed, Nov 8, 2017 at 2:30 PM, Guenter Roeck  wrote:
> > On Wed, Nov 8, 2017 at 11:18 AM, Deucher, Alexander

> >> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
> >> > which was applied at 16:07?

> >> Yes, this is a fix for that patch.  It fixes a 64 bit division that wasn't
> >> properly handled.

Ugh.  Two problems here.  One is obviously that there's a patch that was
sent out only a couple of days ago with a whole bunch of tags about
internal testing and review and now you've found issues with it.  That's
worrying.

The other is that you really, really need to get more on top of upstream
process.  There have been constant problems with this driver and they
feel like they're getting worse not better, with the original send of
this the noise in the subject lines and body of the e-mail means that
what you're sending looks like a case of git send-email CCing people in
accidentally rather than a deliberate upstream submission.

The constant problems mean that even as I open the e-mail I'm expecting
to have to push back on something which isn't great and affects the way
I review things.

> > In that case, the subject should reflect the problem fixed, the description
> > should describe the problem, and there should be a Fixes: tag pointing to
> > the problematic patch.

> I updated the patch subject and added a fixes tag when I resent it
> after removing the chrome tags.  The subject could have been bit
> better, but I wasn't sure how far to take it since it wasn't my patch
> originally.

If you're concerned about rewriting commit logs just add a note saying
that you did so in the commit log.  Please resend normally.


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


Re: [PATCH 1/2] drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 2:53 PM, Ernst Sjöstrand  wrote:
> Can't find these anywhere yet, errors still there.
>
> https://patchwork.freedesktop.org/series/31220/

Applied.  thanks for the reminder.

Alex

>
> Regards
> //Ernst
>
> 2017-09-30 10:25 GMT+02:00 Christian König :
>> Am 30.09.2017 um 10:13 schrieb Dan Carpenter:
>>>
>>> We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
>>> amdgpu_cs_sysvm_access_required into find_mapping") and now my static
>>> checker complains that "r" might not be initialized at the end of the
>>> function.  I've reviewed the code, and that seems possible, but it's
>>> also possible I may have missed something.
>>>
>>> Signed-off-by: Dan Carpenter 
>>
>>
>> Good catches, Reviewed-by: Christian König  for
>> both patches.
>>
>>
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>>> index b46280c1279f..2918de2f39ec 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>>> @@ -648,7 +648,7 @@ int amdgpu_vce_ring_parse_cs(struct amdgpu_cs_parser
>>> *p, uint32_t ib_idx)
>>> uint32_t allocated = 0;
>>> uint32_t tmp, handle = 0;
>>> uint32_t *size = 
>>> -   int i, r, idx = 0;
>>> +   int i, r = 0, idx = 0;
>>> p->job->vm = NULL;
>>> ib->gpu_addr = amdgpu_sa_bo_gpu_addr(ib->sa_bo);
>>
>>
>>
>> ___
>> 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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Guenter Roeck
On Wed, Nov 8, 2017 at 11:35 AM, Alex Deucher  wrote:

> On Wed, Nov 8, 2017 at 2:30 PM, Guenter Roeck  wrote:
> > On Wed, Nov 8, 2017 at 11:18 AM, Deucher, Alexander
> >  wrote:
> >>
> >> > -Original Message-
> >> > From: Mark Brown [mailto:broo...@kernel.org]
> >> > Sent: Wednesday, November 08, 2017 1:48 PM
> >> > To: Alex Deucher
> >> > Cc: amd-gfx list; alsa-de...@alsa-project.org; Maling list - DRI
> >> > developers;
> >> > Mukunda, Vijendar; Liam Girdwood; Takashi Iwai; Guenter Roeck;
> Deucher,
> >> > Alexander
> >> > Subject: Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma
> >> >
> >> > On Wed, Nov 08, 2017 at 01:40:32PM -0500, Alex Deucher wrote:
> >> > > On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown 
> >> > wrote:
> >> >
> >> > > > Like I said in reply to your other mail please don't resubmit
> >> > > > already
> >> > > > applied patches.  The current tip of my topic/amd branch appears
> to
> >> > > > be
> >> > > > this very patch, if there's anything needs changing please send an
> >> > > > incremental patch.
> >> >
> >> > > I'm not seeing this one in your tree either.  This is just a resend
> of
> >> > > Guenter's patch from an hour ago with the chromium stuff removed.
> >> > > Maybe you already applied it in the interim?
> >> >
> >> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
> >> > which was applied at 16:07?
> >>
> >> Yes, this is a fix for that patch.  It fixes a 64 bit division that
> wasn't
> >> properly handled.
> >>
> >
> > In that case, the subject should reflect the problem fixed, the
> description
> > should describe the problem, and there should be a Fixes: tag pointing to
> > the problematic patch.
>
> I updated the patch subject and added a fixes tag when I resent it
> after removing the chrome tags.  The subject could have been bit
> better, but I wasn't sure how far to take it since it wasn't my patch
> originally.
>
>
In such situations, it is probably better to write a new patch with proper
subject and description and add a tag such as "Reported-by:",
"Suggested-by:", or "Originally-from:" to give some credit if you feel
generous. The attempt to retain my ownership caused way more trouble than
it is worth.

Guenter



> Alex
>
> >
> > Sorry, I was not aware that the problematic patch is already pending
> > upstream, or I would have submitted a proper patch upstream myself.
> >
> > Guenter
> >
> >>
> >> Alex
> >>
> >
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 2:49 PM, Mark Brown  wrote:
> On Wed, Nov 08, 2017 at 11:13:50AM -0800, Guenter Roeck wrote:
>> On Wed, Nov 8, 2017 at 10:47 AM, Mark Brown  wrote:
>
>> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
>> > which was applied at 16:07?
>
>> I suspect we may be getting hit by chromeos-isms again. In Chrome OS, we
>> don't use Fixes: tags but "FIXUP: " in the subject
>> (not that I like it, but it is what it is).
>
> So it probably is the same patch that was just resent with a slightly
> modified subject line?  That's what it looked like initially.

The original patch which was applied to your tree already:
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?h=for-next=61add8147942d23519b91f0edc30980d7c14482c
That patch as a 64 bit divide in it which was fixed by this patch from Guenter:
https://lists.freedesktop.org/archives/dri-devel/2017-November/157063.html
which contained a bunch of Chrome tags.  I removed the tags and
updated the subject and added a fixes line and resent it as this patch
(subject of this thread):
https://lists.freedesktop.org/archives/dri-devel/2017-November/157076.html
Please apply.  Sorry for the confusion.

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


Re: [PATCH 1/2] drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()

2017-11-08 Thread Ernst Sjöstrand
Can't find these anywhere yet, errors still there.

https://patchwork.freedesktop.org/series/31220/

Regards
//Ernst

2017-09-30 10:25 GMT+02:00 Christian König :
> Am 30.09.2017 um 10:13 schrieb Dan Carpenter:
>>
>> We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
>> amdgpu_cs_sysvm_access_required into find_mapping") and now my static
>> checker complains that "r" might not be initialized at the end of the
>> function.  I've reviewed the code, and that seems possible, but it's
>> also possible I may have missed something.
>>
>> Signed-off-by: Dan Carpenter 
>
>
> Good catches, Reviewed-by: Christian König  for
> both patches.
>
>
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> index b46280c1279f..2918de2f39ec 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
>> @@ -648,7 +648,7 @@ int amdgpu_vce_ring_parse_cs(struct amdgpu_cs_parser
>> *p, uint32_t ib_idx)
>> uint32_t allocated = 0;
>> uint32_t tmp, handle = 0;
>> uint32_t *size = 
>> -   int i, r, idx = 0;
>> +   int i, r = 0, idx = 0;
>> p->job->vm = NULL;
>> ib->gpu_addr = amdgpu_sa_bo_gpu_addr(ib->sa_bo);
>
>
>
> ___
> 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] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 11:13:50AM -0800, Guenter Roeck wrote:
> On Wed, Nov 8, 2017 at 10:47 AM, Mark Brown  wrote:

> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
> > which was applied at 16:07?

> I suspect we may be getting hit by chromeos-isms again. In Chrome OS, we
> don't use Fixes: tags but "FIXUP: " in the subject
> (not that I like it, but it is what it is).

So it probably is the same patch that was just resent with a slightly
modified subject line?  That's what it looked like initially.


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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 2:30 PM, Guenter Roeck  wrote:
> On Wed, Nov 8, 2017 at 11:18 AM, Deucher, Alexander
>  wrote:
>>
>> > -Original Message-
>> > From: Mark Brown [mailto:broo...@kernel.org]
>> > Sent: Wednesday, November 08, 2017 1:48 PM
>> > To: Alex Deucher
>> > Cc: amd-gfx list; alsa-de...@alsa-project.org; Maling list - DRI
>> > developers;
>> > Mukunda, Vijendar; Liam Girdwood; Takashi Iwai; Guenter Roeck; Deucher,
>> > Alexander
>> > Subject: Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma
>> >
>> > On Wed, Nov 08, 2017 at 01:40:32PM -0500, Alex Deucher wrote:
>> > > On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown 
>> > wrote:
>> >
>> > > > Like I said in reply to your other mail please don't resubmit
>> > > > already
>> > > > applied patches.  The current tip of my topic/amd branch appears to
>> > > > be
>> > > > this very patch, if there's anything needs changing please send an
>> > > > incremental patch.
>> >
>> > > I'm not seeing this one in your tree either.  This is just a resend of
>> > > Guenter's patch from an hour ago with the chromium stuff removed.
>> > > Maybe you already applied it in the interim?
>> >
>> > Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
>> > which was applied at 16:07?
>>
>> Yes, this is a fix for that patch.  It fixes a 64 bit division that wasn't
>> properly handled.
>>
>
> In that case, the subject should reflect the problem fixed, the description
> should describe the problem, and there should be a Fixes: tag pointing to
> the problematic patch.

I updated the patch subject and added a fixes tag when I resent it
after removing the chrome tags.  The subject could have been bit
better, but I wasn't sure how far to take it since it wasn't my patch
originally.

Alex

>
> Sorry, I was not aware that the problematic patch is already pending
> upstream, or I would have submitted a proper patch upstream myself.
>
> Guenter
>
>>
>> Alex
>>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 01:40:32PM -0500, Alex Deucher wrote:
> On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown  wrote:

> > Like I said in reply to your other mail please don't resubmit already
> > applied patches.  The current tip of my topic/amd branch appears to be
> > this very patch, if there's anything needs changing please send an
> > incremental patch.

> I'm not seeing this one in your tree either.  This is just a resend of
> Guenter's patch from an hour ago with the chromium stuff removed.
> Maybe you already applied it in the interim?

Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
which was applied at 16:07?


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


RE: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Deucher, Alexander
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, November 08, 2017 1:48 PM
> To: Alex Deucher
> Cc: amd-gfx list; alsa-de...@alsa-project.org; Maling list - DRI developers;
> Mukunda, Vijendar; Liam Girdwood; Takashi Iwai; Guenter Roeck; Deucher,
> Alexander
> Subject: Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma
> 
> On Wed, Nov 08, 2017 at 01:40:32PM -0500, Alex Deucher wrote:
> > On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown 
> wrote:
> 
> > > Like I said in reply to your other mail please don't resubmit already
> > > applied patches.  The current tip of my topic/amd branch appears to be
> > > this very patch, if there's anything needs changing please send an
> > > incremental patch.
> 
> > I'm not seeing this one in your tree either.  This is just a resend of
> > Guenter's patch from an hour ago with the chromium stuff removed.
> > Maybe you already applied it in the interim?
> 
> Is this different to "ASoC: amd: Report accurate hw_ptr during dma"
> which was applied at 16:07?

Yes, this is a fix for that patch.  It fixes a 64 bit division that wasn't 
properly handled.

Alex

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


Re: [PATCH 1/3] ASoC: AMD: Make the driver name consistent across files

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 06:12:34PM +, Deucher, Alexander wrote:

> This didn't not appear to be in your tree yet and I never got any 
> confirmation it being
> applied.  Apologies.

Ah, sorry - my bad.  This was one that I tried to apply but which didn't
apply.


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


Applied "ASoC: amd: Make the driver name consistent across files" to the asoc tree

2017-11-08 Thread Mark Brown
The patch

   ASoC: amd: Make the driver name consistent across files

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From bdd2a858afd55cc11723df9dd2841241a4c49ce5 Mon Sep 17 00:00:00 2001
From: Akshu Agrawal 
Date: Wed, 8 Nov 2017 12:24:02 -0500
Subject: [PATCH] ASoC: amd: Make the driver name consistent across files

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci:00/:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

TEST=boot and check for device in lsmod

[Removed yet more ChromeOS crap from the changelog -- broonie]

Signed-off-by: Akshu Agrawal 
Tested-by: Jason Clinton 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff6c73e..f07fd2e2870a 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e19f281afeaa..13d040a4d26f 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1189,7 +1191,7 @@ static struct platform_driver acp_dma_driver = {
.probe = acp_audio_probe,
.remove = acp_audio_remove,
.driver = {
-   .name = "acp_audio_dma",
+   .name = DRV_NAME,
.pm = _pm_ops,
},
 };
@@ -1200,4 +1202,4 @@ MODULE_AUTHOR("vijendar.muku...@amd.com");
 MODULE_AUTHOR("maruthi.bayyavar...@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.15.0

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


Re: [PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 1:22 PM, Mark Brown  wrote:
> On Wed, Nov 08, 2017 at 01:18:41PM -0500, Alex Deucher wrote:
>> From: Guenter Roeck 
>>
>> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
>>
>> 64-bit divides require special operations to avoid build errors on 32-bit
>> systems.
>
> Like I said in reply to your other mail please don't resubmit already
> applied patches.  The current tip of my topic/amd branch appears to be
> this very patch, if there's anything needs changing please send an
> incremental patch.

I'm not seeing this one in your tree either.  This is just a resend of
Guenter's patch from an hour ago with the chromium stuff removed.
Maybe you already applied it in the interim?

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


[PATCH umr] Switch GRBM index when reading wave data directly.

2017-11-08 Thread Tom St Denis
Signed-off-by: Tom St Denis 
---
 src/lib/wave_status.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/lib/wave_status.c b/src/lib/wave_status.c
index fe2add779fdd..7f0130bb9347 100644
--- a/src/lib/wave_status.c
+++ b/src/lib/wave_status.c
@@ -116,7 +116,9 @@ static int umr_get_wave_status_vi(struct umr_asic *asic, 
unsigned se, unsigned s
read(asic->fd.wave, , 32*4);
} else {
int n = 0;
+   umr_grbm_select_index(asic, se, sh, cu);
read_wave_status_via_mmio(asic, simd, wave, [0], );
+   umr_grbm_select_index(asic, 0x, 0x, 0x);
}
 
if (buf[0] != 0) {
@@ -218,7 +220,9 @@ static int umr_get_wave_status_ai(struct umr_asic *asic, 
unsigned se, unsigned s
read(asic->fd.wave, , 32*4);
} else {
int n = 0;
+   umr_grbm_select_index(asic, se, sh, cu);
read_wave_status_via_mmio(asic, simd, wave, [0], );
+   umr_grbm_select_index(asic, 0x, 0x, 0x);
}
 
if (buf[0] != 1) {
-- 
2.12.0

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


[PATCH] ASoC: amd: fix report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
From: Guenter Roeck 

ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!

64-bit divides require special operations to avoid build errors on 32-bit
systems.

fixes: 61add8147942 (ASoC: amd: Report accurate hw_ptr during dma)
Signed-off-by: Guenter Roeck 
Reviewed-on: https://chromium-review.googlesource.com/678919
Reviewed-by: Jason Clinton 
(cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
Reviewed-on: https://chromium-review.googlesource.com/681618
Signed-off-by: Alex Deucher 
---

v2: resend with the Chromium tags removed and the subject updated.

 sound/soc/amd/acp-pcm-dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 13d040a4d26f..ef7e98ad960c 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct 
snd_pcm_substream *substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (bytescount > rtd->renderbytescount)
bytescount = bytescount - rtd->renderbytescount;
-   pos =  bytescount % buffersize;
} else {
if (bytescount > rtd->capturebytescount)
bytescount = bytescount - rtd->capturebytescount;
-   pos = bytescount % buffersize;
}
+   pos = do_div(bytescount, buffersize);
return bytes_to_frames(runtime, pos);
 }
 
-- 
2.13.6

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


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Christian König

Am 08.11.2017 um 18:37 schrieb Michel Dänzer:

On 08/11/17 05:41 PM, Christian König wrote:

Am 08.11.2017 um 17:36 schrieb Michel Dänzer:

On 08/11/17 03:59 PM, Christian König wrote:

Instead of having a pointless wrapper or call the underlying ww_mutex
function directly.

Not sure I can agree it's pointless, since it recently took me a while
to realize that unlocking bo->resv is essentially the same as
unreserving the BO.

Ok in this case let's call this confusing. But yeah that
__ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and
ww_mutex_unlock(>resv->lock) are essentially the same thing is
exactly what I want to fix here.

How about always using __ttm_bo_unreserve instead?


I actually want to get rid of __ttm_bo_reserve as well. Cause what is 
easier to understand:


__ttm_bo_reserve(bo, false, false, NULL) vs. 
reservation_object_lock(bo->resv);


__ttm_bo_reserve(bo, false, true, NULL) vs. 
reservation_object_trylock(bo->resv);


__ttm_bo_reserve(bo, true, false, NULL) vs. 
reservation_object_lock_interruptible(bo->resv);



The first piglit run with this series applied hit the BUG_ON in
ttm_bo_add_to_lru, see the attached dmesg excerpt. The machine hung,
couldn't reboot cleanly. Haven't been able to reproduce it in three more
attempts though, so I'm not sure it's caused by this series, but I don't
remember seeing it before.


It's most likely caused by this change, I will take another look tomorrow.


P.S. I just noticed I haven't had CONFIG_PROVE_LOCKING enabled in my
kernels for a while, I'll enable it again. Any other options that should
be enabled for testing?


kmemleak is quite nice to have available as well, but doesn't need to 
run automatically all the time.


Christian.

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


Re: [PATCH v2 2/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 12:24:03PM -0500, Alex Deucher wrote:

>   regmap_read(regmap, RT5645_VENDOR_ID2, );
>  
> + /*
> +  * Read after 400msec, as it is the interval required between
> +  * read and power On.
> +  */
> + msleep(TIME_TO_POWER_MS);
> + regmap_read(regmap, RT5645_VENDOR_ID2, );
> +

This leaves the original read in there so we've both got the early read
(which might upset things potentially) and the delayed read.  Shouldn't
we just be adding a msleep() before the existing read?


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


RE: [PATCH 1/3] ASoC: AMD: Make the driver name consistent across files

2017-11-08 Thread Deucher, Alexander
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Wednesday, November 08, 2017 1:09 PM
> To: Alex Deucher
> Cc: amd-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; dri-
> de...@lists.freedesktop.org; Mukunda, Vijendar; lgirdw...@gmail.com;
> ti...@suse.de; Agrawal, Akshu; Deucher, Alexander
> Subject: Re: [PATCH 1/3] ASoC: AMD: Make the driver name consistent
> across files
> 
> On Wed, Nov 08, 2017 at 12:24:02PM -0500, Alex Deucher wrote:
> > From: Akshu Agrawal 
> >
> > This fixes the issue of driver not getting auto loaded with
> > MODULE_ALIAS.
> 
> Please don't resubmit patches that have already been applied, you should
> submit patches against current code in the tree you're expecting things
> to be applied to.  If any updates are needed to a patch that's already
> been applied you should submit incremental patches which make those
> updates.  This avoids having to change published git commits which could
> cause problems for people working against git.

This didn't not appear to be in your tree yet and I never got any confirmation 
it being
applied.  Apologies.

Alex

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


Re: [PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Wed, Nov 08, 2017 at 12:45:16PM -0500, Alex Deucher wrote:
> On Wed, Nov 8, 2017 at 12:42 PM, Alex Deucher  wrote:

> > I'm not familiar with which are chromium specific (TEST, BUG, FIXUP,
> > FROMLIST I guess?). The info seems useful to have in the bug, but I
> > can respin if it's a big deal.

> s/bug/commit message/

All of those are Chrome specific.  If in doubt look at what other people
are using.


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


[PATCH xf86-video-amdgpu] Use correct ScrnInfoPtr in redisplay_dirty

2017-11-08 Thread Michel Dänzer
From: Michel Dänzer 

We used the destination pixmap's screen for flushing glamor. But when
we are the master screen, the destination pixmap is from the slave
screen.

Fixes crash when the slave screen isn't using glamor as well.

Bugzilla: https://bugs.freedesktop.org/103613
Fixes: e15b23663cd1 ("Adapt to PixmapDirtyUpdateRec::src being a
 DrawablePtr")
Signed-off-by: Michel Dänzer 
---
 src/amdgpu_kms.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/amdgpu_kms.c b/src/amdgpu_kms.c
index cb0fb3b57..a5f2040a8 100644
--- a/src/amdgpu_kms.c
+++ b/src/amdgpu_kms.c
@@ -479,7 +479,11 @@ dirty_region(PixmapDirtyUpdatePtr dirty)
 static void
 redisplay_dirty(PixmapDirtyUpdatePtr dirty, RegionPtr region)
 {
-   ScrnInfoPtr scrn = xf86ScreenToScrn(dirty->slave_dst->drawable.pScreen);
+#ifdef HAS_DIRTYTRACKING_DRAWABLE_SRC
+   ScrnInfoPtr src_scrn = xf86ScreenToScrn(dirty->src->pScreen);
+#else
+   ScrnInfoPtr src_scrn = xf86ScreenToScrn(dirty->src->drawable.pScreen);
+#endif
 
if (RegionNil(region))
goto out;
@@ -493,7 +497,7 @@ redisplay_dirty(PixmapDirtyUpdatePtr dirty, RegionPtr 
region)
PixmapSyncDirtyHelper(dirty, region);
 #endif
 
-   amdgpu_glamor_flush(scrn);
+   amdgpu_glamor_flush(src_scrn);
if (dirty->slave_dst->master_pixmap)
DamageRegionProcessPending(>slave_dst->drawable);
 
-- 
2.15.0

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


Re: [PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 12:42 PM, Alex Deucher  wrote:
> On Wed, Nov 8, 2017 at 12:29 PM, Guenter Roeck  wrote:
>> On Wed, Nov 8, 2017 at 9:24 AM, Alex Deucher  wrote:
>>>
>>> From: Guenter Roeck 
>>>
>>> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
>>>
>>> 64-bit divides require special operations to avoid build errors on 32-bit
>>> systems.
>>>
>>> BUG=b:63121716
>>> TEST="Build i386:allmodconfig"
>>>
>>
>> Is this an upstream submission ? Fine with me, but it should not include any
>> chromium specific tags, neither in the subject not in the description.
>
> I'm not familiar with which are chromium specific (TEST, BUG, FIXUP,
> FROMLIST I guess?). The info seems useful to have in the bug, but I
> can respin if it's a big deal.

s/bug/commit message/

Alex

>
> Alex
>
>>
>> Guenter
>>
>>>
>>> Signed-off-by: Guenter Roeck 
>>> Reviewed-on: https://chromium-review.googlesource.com/678919
>>> Reviewed-by: Jason Clinton 
>>> (cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
>>> Reviewed-on: https://chromium-review.googlesource.com/681618
>>> Signed-off-by: Alex Deucher 
>>> ---
>>>  sound/soc/amd/acp-pcm-dma.c | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
>>> index 13d040a4d26f..ef7e98ad960c 100644
>>> --- a/sound/soc/amd/acp-pcm-dma.c
>>> +++ b/sound/soc/amd/acp-pcm-dma.c
>>> @@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
>>> snd_pcm_substream *substream)
>>> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>>> if (bytescount > rtd->renderbytescount)
>>> bytescount = bytescount - rtd->renderbytescount;
>>> -   pos =  bytescount % buffersize;
>>> } else {
>>> if (bytescount > rtd->capturebytescount)
>>> bytescount = bytescount - rtd->capturebytescount;
>>> -   pos = bytescount % buffersize;
>>> }
>>> +   pos = do_div(bytescount, buffersize);
>>> return bytes_to_frames(runtime, pos);
>>>  }
>>>
>>> --
>>> 2.13.6
>>>
>>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 12:29 PM, Guenter Roeck  wrote:
> On Wed, Nov 8, 2017 at 9:24 AM, Alex Deucher  wrote:
>>
>> From: Guenter Roeck 
>>
>> ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!
>>
>> 64-bit divides require special operations to avoid build errors on 32-bit
>> systems.
>>
>> BUG=b:63121716
>> TEST="Build i386:allmodconfig"
>>
>
> Is this an upstream submission ? Fine with me, but it should not include any
> chromium specific tags, neither in the subject not in the description.

I'm not familiar with which are chromium specific (TEST, BUG, FIXUP,
FROMLIST I guess?). The info seems useful to have in the bug, but I
can respin if it's a big deal.

Alex

>
> Guenter
>
>>
>> Signed-off-by: Guenter Roeck 
>> Reviewed-on: https://chromium-review.googlesource.com/678919
>> Reviewed-by: Jason Clinton 
>> (cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
>> Reviewed-on: https://chromium-review.googlesource.com/681618
>> Signed-off-by: Alex Deucher 
>> ---
>>  sound/soc/amd/acp-pcm-dma.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
>> index 13d040a4d26f..ef7e98ad960c 100644
>> --- a/sound/soc/amd/acp-pcm-dma.c
>> +++ b/sound/soc/amd/acp-pcm-dma.c
>> @@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct
>> snd_pcm_substream *substream)
>> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>> if (bytescount > rtd->renderbytescount)
>> bytescount = bytescount - rtd->renderbytescount;
>> -   pos =  bytescount % buffersize;
>> } else {
>> if (bytescount > rtd->capturebytescount)
>> bytescount = bytescount - rtd->capturebytescount;
>> -   pos = bytescount % buffersize;
>> }
>> +   pos = do_div(bytescount, buffersize);
>> return bytes_to_frames(runtime, pos);
>>  }
>>
>> --
>> 2.13.6
>>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Michel Dänzer
On 08/11/17 05:41 PM, Christian König wrote:
> Am 08.11.2017 um 17:36 schrieb Michel Dänzer:
>> On 08/11/17 03:59 PM, Christian König wrote:
>>> Instead of having a pointless wrapper or call the underlying ww_mutex
>>> function directly.
>> Not sure I can agree it's pointless, since it recently took me a while
>> to realize that unlocking bo->resv is essentially the same as
>> unreserving the BO.
> 
> Ok in this case let's call this confusing. But yeah that
> __ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and
> ww_mutex_unlock(>resv->lock) are essentially the same thing is
> exactly what I want to fix here.

How about always using __ttm_bo_unreserve instead?


The first piglit run with this series applied hit the BUG_ON in
ttm_bo_add_to_lru, see the attached dmesg excerpt. The machine hung,
couldn't reboot cleanly. Haven't been able to reproduce it in three more
attempts though, so I'm not sure it's caused by this series, but I don't
remember seeing it before.


P.S. I just noticed I haven't had CONFIG_PROVE_LOCKING enabled in my
kernels for a while, I'll enable it again. Any other options that should
be enabled for testing?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
Nov  8 17:54:48 kaveri kernel: [ 1084.244694] [ cut here ]
Nov  8 17:54:48 kaveri kernel: [ 1084.244697] kernel BUG at drivers/gpu/drm//ttm/ttm_bo.c:172!
Nov  8 17:54:48 kaveri kernel: [ 1084.244703] invalid opcode:  [#1] SMP KASAN
Nov  8 17:54:48 kaveri kernel: [ 1084.244705] Modules linked in: lz4 lz4_compress cpufreq_powersave cpufreq_userspace cpufreq_conservative binfmt_misc nls_ascii nls_cp437 vfat fat edac_mce_amd amdgpu(O) amdkfd(O) radeon(O) kvm snd_hda_codec_realtek chash irqbypass snd_hda_codec_generic ttm(O) snd_hda_codec_hdmi crct10dif_pclmul crc32_pclmul drm_kms_helper(O) ghash_clmulni_intel efi_pstore snd_hda_intel pcbc snd_hda_codec drm(O) snd_hda_core snd_hwdep wmi_bmof snd_pcm snd_timer i2c_algo_bit fb_sys_fops snd aesni_intel syscopyarea ccp sysfillrect aes_x86_64 r8169 crypto_simd sp5100_tco ppdev glue_helper cryptd sg sysimgblt mfd_core mii soundcore rng_core pcspkr efivars i2c_piix4 parport_pc wmi parport i2c_designware_platform i2c_designware_core button acpi_cpufreq tcp_bbr sch_fq nct6775 hwmon_vid sunrpc efivarfs ip_tables x_tables
Nov  8 17:54:48 kaveri kernel: [ 1084.244743]  autofs4 ext4 crc16 mbcache jbd2 fscrypto dm_mod raid10 raid1 raid0 multipath linear md_mod sd_mod evdev hid_generic usbhid hid ahci xhci_pci libahci xhci_hcd libata crc32c_intel usbcore scsi_mod shpchp gpio_amdpt gpio_generic
Nov  8 17:54:48 kaveri kernel: [ 1084.244766] CPU: 13 PID: 4778 Comm: tex3d-maxsize Tainted: G   O4.14.0-rc3+ #32
Nov  8 17:54:48 kaveri kernel: [ 1084.244768] Hardware name: Micro-Star International Co., Ltd. MS-7A34/B350 TOMAHAWK (MS-7A34), BIOS 1.80 09/13/2017
Nov  8 17:54:48 kaveri kernel: [ 1084.244770] task: 880233de6c80 task.stack: 880225ce
Nov  8 17:54:48 kaveri kernel: [ 1084.244779] RIP: 0010:ttm_bo_add_to_lru+0x4fe/0x640 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244780] RSP: 0018:880225ce6d60 EFLAGS: 00010206
Nov  8 17:54:48 kaveri kernel: [ 1084.244783] RAX: dc00 RBX: 88038de24cd8 RCX: 
Nov  8 17:54:48 kaveri kernel: [ 1084.244784] RDX: 110044b9cdb4 RSI:  RDI: 88038de24ce0
Nov  8 17:54:48 kaveri kernel: [ 1084.244786] RBP: 110044b9cdb0 R08: 07cbd06c R09: 
Nov  8 17:54:48 kaveri kernel: [ 1084.244788] R10: 93daac8e R11: 00057de4 R12: 110044b9cdb4
Nov  8 17:54:48 kaveri kernel: [ 1084.244791] R13: 880388033c88 R14: 88038de24d88 R15: 88038a452718
Nov  8 17:54:48 kaveri kernel: [ 1084.244794] FS:  7fa01e650300() GS:8803ae74() knlGS:
Nov  8 17:54:48 kaveri kernel: [ 1084.244797] CS:  0010 DS:  ES:  CR0: 80050033
Nov  8 17:54:48 kaveri kernel: [ 1084.244799] CR2: 7faecd0f06f0 CR3: 00038b7d3000 CR4: 003406e0
Nov  8 17:54:48 kaveri kernel: [ 1084.244801] Call Trace:
Nov  8 17:54:48 kaveri kernel: [ 1084.244823]  ? drm_mm_init+0x4d0/0x4d0 [drm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244832]  ? ttm_bo_device_init+0x620/0x620 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244837]  ? __kernel_text_address+0xe/0x30
Nov  8 17:54:48 kaveri kernel: [ 1084.244841]  ? bpf_prog_alloc+0x2d0/0x2d0
Nov  8 17:54:48 kaveri kernel: [ 1084.244844]  ? deref_stack_reg+0x1f0/0x1f0
Nov  8 17:54:48 kaveri kernel: [ 1084.244851]  ttm_mem_evict_first+0x473/0x5c0 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244857]  ? ttm_bo_evict+0xc70/0xc70 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244863]  ttm_bo_mem_space+0x89d/0xed0 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244869]  ? ttm_bo_mem_compat+0x6b/0x130 [ttm]
Nov  8 17:54:48 kaveri kernel: [ 1084.244874]  ttm_bo_validate+0x301/0x530 [ttm]

[PATCH v2 2/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

2017-11-08 Thread Alex Deucher
From: Akshu Agrawal 

Minimum time required between power On of codec and read
of RT5645_VENDOR_ID2 is 400msec. We should wait that long
before reading the value.

TEST=Cold boot the device and check for sound device.

Signed-off-by: Akshu Agrawal 
Signed-off-by: Bard Liao 
Signed-off-by: Alex Deucher 
---

v2: rework the patch based on mailing list discussion.
Just wait before reading the register.

 sound/soc/codecs/rt5645.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 23cc2cb8393f..ce5d2c3c6976 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -55,6 +55,8 @@ MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
 
 #define RT5645_HWEQ_NUM 57
 
+#define TIME_TO_POWER_MS 400
+
 static const struct regmap_range_cfg rt5645_ranges[] = {
{
.name = "PR",
@@ -3786,6 +3788,13 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
}
regmap_read(regmap, RT5645_VENDOR_ID2, );
 
+   /*
+* Read after 400msec, as it is the interval required between
+* read and power On.
+*/
+   msleep(TIME_TO_POWER_MS);
+   regmap_read(regmap, RT5645_VENDOR_ID2, );
+
switch (val) {
case RT5645_DEVICE_ID:
rt5645->regmap = devm_regmap_init_i2c(i2c, _regmap);
-- 
2.13.6

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


[PATCH 3/3] FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Alex Deucher
From: Guenter Roeck 

ERROR: "__aeabi_uldivmod" [sound/soc/amd/snd-soc-acp-pcm.ko] undefined!

64-bit divides require special operations to avoid build errors on 32-bit
systems.

BUG=b:63121716
TEST="Build i386:allmodconfig"

Signed-off-by: Guenter Roeck 
Reviewed-on: https://chromium-review.googlesource.com/678919
Reviewed-by: Jason Clinton 
(cherry picked from commit 7ca726e80f21abdbaed9a5a70def1c33a26f8533)
Reviewed-on: https://chromium-review.googlesource.com/681618
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/acp-pcm-dma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 13d040a4d26f..ef7e98ad960c 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -856,12 +856,11 @@ static snd_pcm_uframes_t acp_dma_pointer(struct 
snd_pcm_substream *substream)
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
if (bytescount > rtd->renderbytescount)
bytescount = bytescount - rtd->renderbytescount;
-   pos =  bytescount % buffersize;
} else {
if (bytescount > rtd->capturebytescount)
bytescount = bytescount - rtd->capturebytescount;
-   pos = bytescount % buffersize;
}
+   pos = do_div(bytescount, buffersize);
return bytes_to_frames(runtime, pos);
 }
 
-- 
2.13.6

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


[PATCH v2 0/3] Fixes for AMD Stoney ACP audio

2017-11-08 Thread Alex Deucher
This patch set is just a couple fixes for the Audio CoProcessor (ACP)
on AMD Stoney platforms and a small general fix for the rt5645
codec driver.

The entire patch set can also be viewed here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=sound-for-next-stoney2

Thanks!

Alex

v2: - Add a fix for a 64 bit divide in hw_ptr patch
- rework rt5645 patch as per Mark's comments


Akshu Agrawal (2):
  ASoC: AMD: Make the driver name consistent across files
  ASoC: rt5645: Wait for 400msec before concluding on value of
RT5645_VENDOR_ID2

Guenter Roeck (1):
  FIXUP: FROMLIST: ASoC: amd: Report accurate hw_ptr during dma

 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 9 +
 sound/soc/codecs/rt5645.c   | 9 +
 3 files changed, 16 insertions(+), 6 deletions(-)

-- 
2.13.6

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


[PATCH 1/3] ASoC: AMD: Make the driver name consistent across files

2017-11-08 Thread Alex Deucher
From: Akshu Agrawal 

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci:00/:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

BUG=b:62103837
TEST=boot and check for device in lsmod

Signed-off-by: Akshu Agrawal 
Reviewed-on: https://chromium-review.googlesource.com/678278
Tested-by: Jason Clinton 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff6c73e..f07fd2e2870a 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e19f281afeaa..13d040a4d26f 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1189,7 +1191,7 @@ static struct platform_driver acp_dma_driver = {
.probe = acp_audio_probe,
.remove = acp_audio_remove,
.driver = {
-   .name = "acp_audio_dma",
+   .name = DRV_NAME,
.pm = _pm_ops,
},
 };
@@ -1200,4 +1202,4 @@ MODULE_AUTHOR("vijendar.muku...@amd.com");
 MODULE_AUTHOR("maruthi.bayyavar...@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.13.6

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


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Christian König

Am 08.11.2017 um 17:36 schrieb Michel Dänzer:

On 08/11/17 03:59 PM, Christian König wrote:

Instead of having a pointless wrapper or call the underlying ww_mutex
function directly.

Not sure I can agree it's pointless, since it recently took me a while
to realize that unlocking bo->resv is essentially the same as
unreserving the BO.


Ok in this case let's call this confusing. But yeah that 
__ttm_bo_unreserv(bo), reservation_object_unlock(bo->resv) and 
ww_mutex_unlock(>resv->lock) are essentially the same thing is 
exactly what I want to fix here.



Anyway, this breaks the qxl driver:

drivers/gpu/drm//qxl/qxl_release.c: In function 
‘qxl_release_fence_buffer_objects’:
drivers/gpu/drm//qxl/qxl_release.c:472:3: error: implicit declaration of 
function ‘__ttm_bo_unreserve’; did you mean ‘ttm_bo_unreserve’? 
[-Werror=implicit-function-declaration]
__ttm_bo_unreserve(bo);
^~
ttm_bo_unreserve


Thanks for pointing this out, going to respin.

Christian.

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


Re: [PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Michel Dänzer
On 08/11/17 03:59 PM, Christian König wrote:
> Instead of having a pointless wrapper or call the underlying ww_mutex
> function directly.

Not sure I can agree it's pointless, since it recently took me a while
to realize that unlocking bo->resv is essentially the same as
unreserving the BO.


Anyway, this breaks the qxl driver:

drivers/gpu/drm//qxl/qxl_release.c: In function 
‘qxl_release_fence_buffer_objects’:
drivers/gpu/drm//qxl/qxl_release.c:472:3: error: implicit declaration of 
function ‘__ttm_bo_unreserve’; did you mean ‘ttm_bo_unreserve’? 
[-Werror=implicit-function-declaration]
   __ttm_bo_unreserve(bo);
   ^~
   ttm_bo_unreserve


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Applied "ASoC: amd: Report accurate hw_ptr during dma" to the asoc tree

2017-11-08 Thread Mark Brown
The patch

   ASoC: amd: Report accurate hw_ptr during dma

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

From 61add8147942d23519b91f0edc30980d7c14482c Mon Sep 17 00:00:00 2001
From: Vijendar Mukunda 
Date: Fri, 3 Nov 2017 16:35:43 -0400
Subject: [PATCH] ASoC: amd: Report accurate hw_ptr during dma

Using hw register to read transmitted byte count and report
accordingly the hw pointer.

TEST=
modprobe snd-soc-acp-pcm.ko
modprobe snd-soc-acp-rt5645.ko
aplay 

Signed-off-by: Vijendar Mukunda 
Signed-off-by: Akshu Agrawal 
Tested-by: Akshu Agrawal 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
Signed-off-by: Mark Brown 
---
 sound/soc/amd/acp-pcm-dma.c | 71 -
 sound/soc/amd/acp.h | 10 +++
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 73b58ee00383..e19f281afeaa 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -817,39 +817,48 @@ static int acp_dma_hw_free(struct snd_pcm_substream 
*substream)
return snd_pcm_lib_free_pages(substream);
 }
 
+static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
+{
+   union acp_dma_count playback_dma_count;
+   union acp_dma_count capture_dma_count;
+   u64 bytescount = 0;
+
+   if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
+   mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
+   playback_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+   mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
+   bytescount = playback_dma_count.bytescount;
+   } else {
+   capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
+   mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
+   capture_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+   mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
+   bytescount = capture_dma_count.bytescount;
+   }
+   return bytescount;
+}
+
 static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream *substream)
 {
-   u16 dscr;
-   u32 mul, dma_config, period_bytes;
+   u32 buffersize;
u32 pos = 0;
+   u64 bytescount = 0;
 
struct snd_pcm_runtime *runtime = substream->runtime;
struct audio_substream_data *rtd = runtime->private_data;
 
-   period_bytes = frames_to_bytes(runtime, runtime->period_size);
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   dscr = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CUR_DSCR_13);
+   buffersize = frames_to_bytes(runtime, runtime->buffer_size);
+   bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
 
-   if (dscr == PLAYBACK_START_DMA_DESCR_CH13)
-   mul = 0;
-   else
-   mul = 1;
-   pos =  (mul * period_bytes);
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   if (bytescount > rtd->renderbytescount)
+   bytescount = bytescount - rtd->renderbytescount;
+   pos =  bytescount % buffersize;
} else {
-   dma_config = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CNTL_14);
-   if (dma_config != 0) {
-   dscr = acp_reg_read(rtd->acp_mmio,
-   mmACP_DMA_CUR_DSCR_14);
-   if (dscr == CAPTURE_START_DMA_DESCR_CH14)
-   mul = 1;
-   else
-   mul = 2;
-   pos = (mul * period_bytes);
-   }
-
-   if (pos >= (2 * period_bytes))
-   pos = 0;
-
+   if (bytescount > rtd->capturebytescount)
+   bytescount = bytescount - rtd->capturebytescount;

Re: [PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

2017-11-08 Thread Mark Brown
On Tue, Nov 07, 2017 at 09:34:35PM +0530, Agrawal, Akshu wrote:
> On 11/7/2017 5:07 PM, Mark Brown wrote:

> > > > These two URLs are different, what was being reviewed here?  What is
> > > > Commit-Ready supposed to mean?

> Same patch is reviewed, once on 4.4 kernel (659699) and then on 4.12 kernel
> (672267).
> Commit-ready is to get it merged on tree after receiving a +2.

OK, that's not unreasonable but probably best to mention if the review
was in the context of a very old kernel, sometimes upstream changes can
invalidate the review.


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


Re: [PATCH 0/3] Bunch of cleanups in DM and amdgpu_crtc

2017-11-08 Thread Andrey Grodzovsky

 Reviewed-by: Andrey Grodzovsky 


On 11/08/2017 10:33 AM, Harry Wentland wrote:

Just removing a couple unused things I noticed while going through
the code.

Harry Wentland (3):
   amdgpu/dm: Remove fb_location form fill_plane_attributes
   drm/amdgpu: Remove unused dc_stream from amdgpu_crtc
   amdgpu/dm: Remove unused forward declaration

  drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  2 --
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 --
  3 files changed, 17 deletions(-)



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


[PATCH 1/3] amdgpu/dm: Remove fb_location form fill_plane_attributes

2017-11-08 Thread Harry Wentland
We no longer set the framebuffer address here so this is now
dead code.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
 1 file changed, 13 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 86c39fc68b2f..ccfbf14c0f09 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1764,8 +1764,6 @@ static int fill_plane_attributes_from_fb(struct 
amdgpu_device *adev,
 const struct amdgpu_framebuffer 
*amdgpu_fb)
 {
uint64_t tiling_flags;
-   uint64_t fb_location = 0;
-   uint64_t chroma_addr = 0;
unsigned int awidth;
const struct drm_framebuffer *fb = _fb->base;
int ret = 0;
@@ -1811,8 +1809,6 @@ static int fill_plane_attributes_from_fb(struct 
amdgpu_device *adev,
 
if (plane_state->format < SURFACE_PIXEL_FORMAT_VIDEO_BEGIN) {
plane_state->address.type = PLN_ADDR_TYPE_GRAPHICS;
-   plane_state->address.grph.addr.low_part = 
lower_32_bits(fb_location);
-   plane_state->address.grph.addr.high_part = 
upper_32_bits(fb_location);
plane_state->plane_size.grph.surface_size.x = 0;
plane_state->plane_size.grph.surface_size.y = 0;
plane_state->plane_size.grph.surface_size.width = fb->width;
@@ -1825,15 +1821,6 @@ static int fill_plane_attributes_from_fb(struct 
amdgpu_device *adev,
} else {
awidth = ALIGN(fb->width, 64);
plane_state->address.type = PLN_ADDR_TYPE_VIDEO_PROGRESSIVE;
-   plane_state->address.video_progressive.luma_addr.low_part
-   = lower_32_bits(fb_location);
-   plane_state->address.video_progressive.luma_addr.high_part
-   = upper_32_bits(fb_location);
-   chroma_addr = fb_location + (u64)(awidth * fb->height);
-   plane_state->address.video_progressive.chroma_addr.low_part
-   = lower_32_bits(chroma_addr);
-   plane_state->address.video_progressive.chroma_addr.high_part
-   = upper_32_bits(chroma_addr);
plane_state->plane_size.video.luma_size.x = 0;
plane_state->plane_size.video.luma_size.y = 0;
plane_state->plane_size.video.luma_size.width = awidth;
-- 
2.14.1

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


[PATCH 2/3] drm/amdgpu: Remove unused dc_stream from amdgpu_crtc

2017-11-08 Thread Harry Wentland
It's no longer used. In fact, there is no more dc_stream object.

Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 4069a3b2f55f..dd9ecd3e40e8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -437,8 +437,6 @@ struct amdgpu_crtc {
enum amdgpu_interrupt_state vsync_timer_enabled;
 
int otg_inst;
-   /* After Set Mode stream will be non-NULL */
-   const struct dc_stream *stream;
struct drm_pending_vblank_event *event;
 };
 
-- 
2.14.1

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


[PATCH 0/3] Bunch of cleanups in DM and amdgpu_crtc

2017-11-08 Thread Harry Wentland
Just removing a couple unused things I noticed while going through
the code.

Harry Wentland (3):
  amdgpu/dm: Remove fb_location form fill_plane_attributes
  drm/amdgpu: Remove unused dc_stream from amdgpu_crtc
  amdgpu/dm: Remove unused forward declaration

 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  2 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 13 -
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 --
 3 files changed, 17 deletions(-)

-- 
2.14.1

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


[PATCH 3/3] amdgpu/dm: Remove unused forward declaration

2017-11-08 Thread Harry Wentland
dc_stream has long been renamed to dc_stream_state, so this
forward declaration hasn't been used at all.

Change-Id: I0c03cfe600f39eb1ec4f8015be340c62a7d22eb3
Signed-off-by: Harry Wentland 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index 82a7457d7f62..6b81e124ea57 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -199,8 +199,6 @@ struct amdgpu_framebuffer;
 struct amdgpu_display_manager;
 struct dc_validation_set;
 struct dc_plane_state;
-/* TODO rename to dc_stream_state */
-struct  dc_stream;
 
 struct dm_plane_state {
struct drm_plane_state base;
-- 
2.14.1

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


[PATCH 3/4] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

2017-11-08 Thread Christian König
Needed for the next patch.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 52 
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 6f55310a9d09..d23592cfe42e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -486,20 +486,21 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
 }
 
 /**
- * function ttm_bo_cleanup_refs_and_unlock
+ * function ttm_bo_cleanup_refs
  * If bo idle, remove from delayed- and lru lists, and unref.
  * If not idle, do nothing.
  *
  * Must be called with lru_lock and reservation held, this function
- * will drop both before returning.
+ * will drop the lru lock and optionally the reservation lock before returning.
  *
  * @interruptible Any sleeps should occur interruptibly.
  * @no_wait_gpu   Never wait for gpu. Return -EBUSY instead.
+ * @unlock_resv   Unlock the reservation lock as well.
  */
 
-static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
- bool interruptible,
- bool no_wait_gpu)
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+  bool interruptible, bool no_wait_gpu,
+  bool unlock_resv)
 {
struct ttm_bo_global *glob = bo->glob;
struct reservation_object *resv;
@@ -518,7 +519,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
if (ret && !no_wait_gpu) {
long lret;
 
-   reservation_object_unlock(bo->resv);
+   if (unlock_resv)
+   reservation_object_unlock(bo->resv);
spin_unlock(>lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true,
@@ -531,19 +533,22 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return -EBUSY;
 
spin_lock(>lru_lock);
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
-
-   /*
-* We raced, and lost, someone else holds the reservation now,
-* and is probably busy in ttm_bo_cleanup_memtype_use.
-*
-* Even if it's not the case, because we finished waiting any
-* delayed destruction would succeed, so just return success
-* here.
-*/
-   if (ret) {
-   spin_unlock(>lru_lock);
-   return 0;
+   if (unlock_resv) {
+   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   /*
+* We raced, and lost, someone else holds the 
reservation now,
+* and is probably busy in ttm_bo_cleanup_memtype_use.
+*
+* Even if it's not the case, because we finished 
waiting any
+* delayed destruction would succeed, so just return 
success
+* here.
+*/
+   if (ret) {
+   spin_unlock(>lru_lock);
+   return 0;
+   }
+   } else {
+   ret = 0;
}
}
 
@@ -600,8 +605,8 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
}
 
if (!ret)
-   ret = ttm_bo_cleanup_refs_and_unlock(entry, false,
-!remove_all);
+   ret = ttm_bo_cleanup_refs(entry, false, !remove_all,
+ true);
else
spin_unlock(>lru_lock);
 
@@ -770,8 +775,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
kref_get(>list_kref);
 
if (!list_empty(>ddestroy)) {
-   ret = ttm_bo_cleanup_refs_and_unlock(bo, interruptible,
-no_wait_gpu);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
}
@@ -1735,7 +1739,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
kref_get(>list_kref);
 
if (!list_empty(>ddestroy)) {
-   ret = ttm_bo_cleanup_refs_and_unlock(bo, false, false);
+   ret = ttm_bo_cleanup_refs(bo, false, false, true);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
}
-- 
2.11.0

___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org

[PATCH 4/4] drm/ttm: optimize ttm_mem_evict_first

2017-11-08 Thread Christian König
Deleted BOs with the same reservation object can be reaped even if they
can't be reserved.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 35 +++
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index d23592cfe42e..f486a484c70f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -735,20 +735,35 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
*bo,
 EXPORT_SYMBOL(ttm_bo_eviction_valuable);
 
 static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
-   uint32_t mem_type,
-   const struct ttm_place *place,
-   bool interruptible,
-   bool no_wait_gpu)
+  struct reservation_object *resv,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  bool interruptible,
+  bool no_wait_gpu)
 {
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+   bool locked;
unsigned i;
 
spin_lock(>lru_lock);
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
+   if (bo->resv == resv) {
+   if (list_empty(>ddestroy))
+   continue;
+
+   if (place &&
+   !bdev->driver->eviction_valuable(bo, place))
+   continue;
+
+   ret = 0;
+   locked = false;
+   break;
+   }
+
ret = __ttm_bo_reserve(bo, false, true, NULL);
if (ret)
continue;
@@ -760,6 +775,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
continue;
}
 
+   locked = true;
break;
}
 
@@ -775,7 +791,8 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
kref_get(>list_kref);
 
if (!list_empty(>ddestroy)) {
-   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu,
+ locked);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
}
@@ -786,7 +803,8 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
BUG_ON(ret != 0);
 
ret = ttm_bo_evict(bo, interruptible, no_wait_gpu);
-   ttm_bo_unreserve(bo);
+   if (locked)
+   ttm_bo_unreserve(bo);
 
kref_put(>list_kref, ttm_bo_release_list);
return ret;
@@ -850,7 +868,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type, place,
+   ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place,
  interruptible, no_wait_gpu);
if (unlikely(ret != 0))
return ret;
@@ -1353,7 +1371,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(>lru[i])) {
spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, 
false);
+   ret = ttm_mem_evict_first(bdev, NULL, mem_type, NULL,
+ false, false);
if (ret)
return ret;
spin_lock(>lru_lock);
-- 
2.11.0

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


[PATCH 2/4] drm/ttm: consistently use reservation_object_unlock

2017-11-08 Thread Christian König
Instead of having a pointless wrapper or call the underlying ww_mutex
function directly.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c   | 13 +++--
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |  8 
 include/drm/ttm/ttm_bo_driver.h| 14 +-
 3 files changed, 12 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9905cf41cba6..6f55310a9d09 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -471,7 +471,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
ttm_bo_add_to_lru(bo);
}
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
if (bo->resv != >ttm_resv)
reservation_object_unlock(>ttm_resv);
@@ -517,7 +517,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
 
if (ret && !no_wait_gpu) {
long lret;
-   ww_mutex_unlock(>resv->lock);
+
+   reservation_object_unlock(bo->resv);
spin_unlock(>lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true,
@@ -547,7 +548,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
}
 
if (ret || unlikely(list_empty(>ddestroy))) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
spin_unlock(>lru_lock);
return ret;
}
@@ -749,7 +750,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
 
if (place && !bdev->driver->eviction_valuable(bo,
  place)) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
ret = -EBUSY;
continue;
}
@@ -1788,7 +1789,7 @@ static int ttm_bo_swapout(struct ttm_mem_shrink *shrink)
 * already swapped buffer.
 */
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
 }
@@ -1825,7 +1826,7 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
ret = __ttm_bo_reserve(bo, true, false, NULL);
if (unlikely(ret != 0))
goto out_unlock;
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
 
 out_unlock:
mutex_unlock(>wu_mutex);
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 5e1bcabffef5..373ced0b2fc2 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -38,7 +38,7 @@ static void ttm_eu_backoff_reservation_reverse(struct 
list_head *list,
list_for_each_entry_continue_reverse(entry, list, head) {
struct ttm_buffer_object *bo = entry->bo;
 
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
 }
 
@@ -69,7 +69,7 @@ void ttm_eu_backoff_reservation(struct ww_acquire_ctx *ticket,
struct ttm_buffer_object *bo = entry->bo;
 
ttm_bo_add_to_lru(bo);
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
spin_unlock(>lru_lock);
 
@@ -112,7 +112,7 @@ int ttm_eu_reserve_buffers(struct ww_acquire_ctx *ticket,
 
ret = __ttm_bo_reserve(bo, intr, (ticket == NULL), ticket);
if (!ret && unlikely(atomic_read(>cpu_writers) > 0)) {
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
 
ret = -EBUSY;
 
@@ -203,7 +203,7 @@ void ttm_eu_fence_buffer_objects(struct ww_acquire_ctx 
*ticket,
else
reservation_object_add_excl_fence(bo->resv, fence);
ttm_bo_add_to_lru(bo);
-   __ttm_bo_unreserve(bo);
+   reservation_object_unlock(bo->resv);
}
spin_unlock(>lru_lock);
if (ticket)
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 5f821a9b3a1f..389359a0006b 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -941,18 +941,6 @@ static inline int ttm_bo_reserve_slowpath(struct 
ttm_buffer_object *bo,
 }
 
 /**
- * __ttm_bo_unreserve
- * @bo: A pointer to a struct ttm_buffer_object.
- *
- * Unreserve a previous reservation of @bo where the buffer object is
- * already on lru lists.
- */
-static inline void __ttm_bo_unreserve(struct ttm_buffer_object *bo)
-{
-   ww_mutex_unlock(>resv->lock);
-}
-
-/**
  * ttm_bo_unreserve
  *
  * @bo: A pointer to a struct ttm_buffer_object.
@@ -966,7 +954,7 

[PATCH 1/4] drm/ttm: move unlocking out of ttm_bo_cleanup_memtype_use

2017-11-08 Thread Christian König
Needed for the next patch and makes the code quite a bit easier to
understand.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c088703777e2..9905cf41cba6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -390,8 +390,6 @@ static void ttm_bo_cleanup_memtype_use(struct 
ttm_buffer_object *bo)
ttm_tt_destroy(bo->ttm);
bo->ttm = NULL;
ttm_bo_mem_put(bo, >mem);
-
-   ww_mutex_unlock (>resv->lock);
 }
 
 static int ttm_bo_individualize_resv(struct ttm_buffer_object *bo)
@@ -457,6 +455,7 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
reservation_object_unlock(>ttm_resv);
 
ttm_bo_cleanup_memtype_use(bo);
+   reservation_object_unlock(bo->resv);
return;
}
 
@@ -559,6 +558,7 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
 
spin_unlock(>lru_lock);
ttm_bo_cleanup_memtype_use(bo);
+   reservation_object_unlock(bo->resv);
 
return 0;
 }
-- 
2.11.0

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


Re: [PATCH] drm/amdgpu: Remove check which is not valid for certain VBIOS

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 1:49 AM,   wrote:
> From: Ken Wang 

What cases does this fix?  I'm guessing VFCT or some other platform
method for getting the vbios?

Acked-by: Alex Deucher 

>
> Signed-off-by: Ken Wang 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> index c21adf6..057e1ec 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c
> @@ -59,12 +59,6 @@ static bool check_atom_bios(uint8_t *bios, size_t size)
> return false;
> }
>
> -   tmp = bios[0x18] | (bios[0x19] << 8);
> -   if (bios[tmp + 0x14] != 0x0) {
> -   DRM_INFO("Not an x86 BIOS ROM\n");
> -   return false;
> -   }
> -
> bios_header_start = bios[0x48] | (bios[0x49] << 8);
> if (!bios_header_start) {
> DRM_INFO("Can't locate bios header\n");
> --
> 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] drm/amd/pp: fix dpm randomly failed on Vega10

2017-11-08 Thread Alex Deucher
On Wed, Nov 8, 2017 at 3:41 AM, Rex Zhu  wrote:
> Change-Id: I15e562ddff64cf73262ece75f08df60fedc1de1a
> Signed-off-by: Rex Zhu 

Acked-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 29 
> +++---
>  drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h |  1 +
>  2 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> index 7db3fbe..9d4955e 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> @@ -753,6 +753,7 @@ static int vega10_hwmgr_backend_init(struct pp_hwmgr 
> *hwmgr)
> uint32_t config_telemetry = 0;
> struct pp_atomfwctrl_voltage_table vol_table;
> struct cgs_system_info sys_info = {0};
> +   uint32_t reg;
>
> data = kzalloc(sizeof(struct vega10_hwmgr), GFP_KERNEL);
> if (data == NULL)
> @@ -859,6 +860,16 @@ static int vega10_hwmgr_backend_init(struct pp_hwmgr 
> *hwmgr)
> advanceFanControlParameters.usFanPWMMinLimit *
> hwmgr->thermal_controller.fanInfo.ulMaxRPM / 100;
>
> +   reg = soc15_get_register_offset(DF_HWID, 0,
> +   mmDF_CS_AON0_DramBaseAddress0_BASE_IDX,
> +   mmDF_CS_AON0_DramBaseAddress0);
> +   data->mem_channels = (cgs_read_register(hwmgr->device, reg) &
> +   DF_CS_AON0_DramBaseAddress0__IntLvNumChan_MASK) >>
> +   DF_CS_AON0_DramBaseAddress0__IntLvNumChan__SHIFT;
> +   PP_ASSERT_WITH_CODE(data->mem_channels < ARRAY_SIZE(channel_number),
> +   "Mem Channel Index Exceeded maximum!",
> +   return -EINVAL);
> +
> return result;
>  }
>
> @@ -1777,7 +1788,7 @@ static int vega10_populate_all_memory_levels(struct 
> pp_hwmgr *hwmgr)
> struct vega10_single_dpm_table *dpm_table =
> &(data->dpm_table.mem_table);
> int result = 0;
> -   uint32_t i, j, reg, mem_channels;
> +   uint32_t i, j;
>
> for (i = 0; i < dpm_table->count; i++) {
> result = vega10_populate_single_memory_level(hwmgr,
> @@ -1801,20 +1812,10 @@ static int vega10_populate_all_memory_levels(struct 
> pp_hwmgr *hwmgr)
> i++;
> }
>
> -   reg = soc15_get_register_offset(DF_HWID, 0,
> -   mmDF_CS_AON0_DramBaseAddress0_BASE_IDX,
> -   mmDF_CS_AON0_DramBaseAddress0);
> -   mem_channels = (cgs_read_register(hwmgr->device, reg) &
> -   DF_CS_AON0_DramBaseAddress0__IntLvNumChan_MASK) >>
> -   DF_CS_AON0_DramBaseAddress0__IntLvNumChan__SHIFT;
> -   PP_ASSERT_WITH_CODE(mem_channels < ARRAY_SIZE(channel_number),
> -   "Mem Channel Index Exceeded maximum!",
> -   return -1);
> -
> -   pp_table->NumMemoryChannels = cpu_to_le16(mem_channels);
> +   pp_table->NumMemoryChannels = (uint16_t)(data->mem_channels);
> pp_table->MemoryChannelWidth =
> -   cpu_to_le16(HBM_MEMORY_CHANNEL_WIDTH *
> -   channel_number[mem_channels]);
> +   (uint16_t)(HBM_MEMORY_CHANNEL_WIDTH *
> +   channel_number[data->mem_channels]);
>
> pp_table->LowestUclkReservedForUlv =
> (uint8_t)(data->lowest_uclk_reserved_for_ulv);
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
> index b4b461c3..8f7358c 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
> @@ -389,6 +389,7 @@ struct vega10_hwmgr {
> uint32_t   config_telemetry;
> uint32_t   smu_version;
> uint32_t   acg_loop_state;
> +   uint32_t   mem_channels;
>  };
>
>  #define VEGA10_DPM2_NEAR_TDP_DEC  10
> --
> 1.9.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: [PATCH] drm/amdgpu: revise retry init to fully cleanup driver

2017-11-08 Thread Christian König

Please put that as a comment above those two lines of code.

Apart from that the patch looks good to me.

Regards,
Christian.

Am 08.11.2017 um 10:46 schrieb Ding, Pixel:

When exclusive mode timeout happens, the VF is not active anymore. Exclusive 
requests will be ignored by host. Unload kms or device fini also request 
exclusive mode and it will get timeout again since no response received.

This only happens for exclusive mode timeout, so I didn’t put them in general 
SRIOV fini function.
—
Sincerely Yours,
Pixel








On 08/11/2017, 5:42 PM, "Christian König"  
wrote:


Am 08.11.2017 um 04:29 schrieb Pixel Ding:

Retry at drm_dev_register instead of amdgpu_device_init.

Signed-off-by: Pixel Ding 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 ++
   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 11 +--
   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 15 ++-
   3 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index bf2b008..4ef2b1b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2390,6 +2390,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
amdgpu_virt_mmio_blocked(adev) &&
!amdgpu_virt_wait_reset(adev)) {
dev_err(adev->dev, "VF exclusive mode timeout\n");
+   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
+   adev->virt.ops = NULL;

Why is that necessary? Maybe put this into some SRIOV specific fini
function?

Apart from that patch looks good to me and is Acked-by: Christian König
.

Regards,
Christian.


r = -EAGAIN;
goto failed;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6b11a75..eaccd4b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -565,12 +565,13 @@ static int amdgpu_kick_out_firmware_fb(struct pci_dev 
*pdev)
return 0;
   }
   
+

   static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
   {
struct drm_device *dev;
unsigned long flags = ent->driver_data;
-   int ret;
+   int ret, retry = 0;
   
   	if ((flags & AMD_EXP_HW_SUPPORT) && !amdgpu_exp_hw_support) {

DRM_INFO("This hardware requires experimental hardware 
support.\n"
@@ -603,8 +604,14 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
   
   	pci_set_drvdata(pdev, dev);
   
+retry_init:

ret = drm_dev_register(dev, ent->driver_data);
-   if (ret)
+   if (ret == -EAGAIN && ++retry <= 3) {
+   DRM_INFO("retry init %d\n", retry);
+   /* Don't request EX mode too frequently which is attacking */
+   msleep(5000);
+   goto retry_init;
+   } else if (ret)
goto err_pci;
   
   	return 0;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 1d56b5b..65360cd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -84,7 +84,7 @@ void amdgpu_driver_unload_kms(struct drm_device *dev)
   int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags)
   {
struct amdgpu_device *adev;
-   int r, acpi_status, retry = 0;
+   int r, acpi_status;
   
   #ifdef CONFIG_DRM_AMDGPU_SI

if (!amdgpu_si_support) {
@@ -120,7 +120,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
}
}
   #endif
-retry_init:
   
   	adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);

if (adev == NULL) {
@@ -143,17 +142,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
 * VRAM allocation
 */
r = amdgpu_device_init(adev, dev, dev->pdev, flags);
-   if (r == -EAGAIN && ++retry <= 3) {
-   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
-   adev->virt.ops = NULL;
-   amdgpu_device_fini(adev);
-   kfree(adev);
-   dev->dev_private = NULL;
-   /* Don't request EX mode too frequently which is attacking */
-   msleep(5000);
-   dev_err(>pdev->dev, "retry init %d\n", retry);
-   goto retry_init;
-   } else if (r) {
+   if (r) {
dev_err(>pdev->dev, "Fatal error during GPU init\n");
goto out;
}




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


Re: [PATCH] drm/amdgpu: revise retry init to fully cleanup driver

2017-11-08 Thread Ding, Pixel
When exclusive mode timeout happens, the VF is not active anymore. Exclusive 
requests will be ignored by host. Unload kms or device fini also request 
exclusive mode and it will get timeout again since no response received.

This only happens for exclusive mode timeout, so I didn’t put them in general 
SRIOV fini function.
— 
Sincerely Yours,
Pixel








On 08/11/2017, 5:42 PM, "Christian König"  
wrote:

>Am 08.11.2017 um 04:29 schrieb Pixel Ding:
>> Retry at drm_dev_register instead of amdgpu_device_init.
>>
>> Signed-off-by: Pixel Ding 
>> ---
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 ++
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 11 +--
>>   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 15 ++-
>>   3 files changed, 13 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index bf2b008..4ef2b1b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -2390,6 +2390,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
>>  amdgpu_virt_mmio_blocked(adev) &&
>>  !amdgpu_virt_wait_reset(adev)) {
>>  dev_err(adev->dev, "VF exclusive mode timeout\n");
>> +adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
>> +adev->virt.ops = NULL;
>
>Why is that necessary? Maybe put this into some SRIOV specific fini 
>function?
>
>Apart from that patch looks good to me and is Acked-by: Christian König 
>.
>
>Regards,
>Christian.
>
>>  r = -EAGAIN;
>>  goto failed;
>>  }
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> index 6b11a75..eaccd4b 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
>> @@ -565,12 +565,13 @@ static int amdgpu_kick_out_firmware_fb(struct pci_dev 
>> *pdev)
>>  return 0;
>>   }
>>   
>> +
>>   static int amdgpu_pci_probe(struct pci_dev *pdev,
>>  const struct pci_device_id *ent)
>>   {
>>  struct drm_device *dev;
>>  unsigned long flags = ent->driver_data;
>> -int ret;
>> +int ret, retry = 0;
>>   
>>  if ((flags & AMD_EXP_HW_SUPPORT) && !amdgpu_exp_hw_support) {
>>  DRM_INFO("This hardware requires experimental hardware 
>> support.\n"
>> @@ -603,8 +604,14 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
>>   
>>  pci_set_drvdata(pdev, dev);
>>   
>> +retry_init:
>>  ret = drm_dev_register(dev, ent->driver_data);
>> -if (ret)
>> +if (ret == -EAGAIN && ++retry <= 3) {
>> +DRM_INFO("retry init %d\n", retry);
>> +/* Don't request EX mode too frequently which is attacking */
>> +msleep(5000);
>> +goto retry_init;
>> +} else if (ret)
>>  goto err_pci;
>>   
>>  return 0;
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> index 1d56b5b..65360cd 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
>> @@ -84,7 +84,7 @@ void amdgpu_driver_unload_kms(struct drm_device *dev)
>>   int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags)
>>   {
>>  struct amdgpu_device *adev;
>> -int r, acpi_status, retry = 0;
>> +int r, acpi_status;
>>   
>>   #ifdef CONFIG_DRM_AMDGPU_SI
>>  if (!amdgpu_si_support) {
>> @@ -120,7 +120,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
>> unsigned long flags)
>>  }
>>  }
>>   #endif
>> -retry_init:
>>   
>>  adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);
>>  if (adev == NULL) {
>> @@ -143,17 +142,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
>> unsigned long flags)
>>   * VRAM allocation
>>   */
>>  r = amdgpu_device_init(adev, dev, dev->pdev, flags);
>> -if (r == -EAGAIN && ++retry <= 3) {
>> -adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
>> -adev->virt.ops = NULL;
>> -amdgpu_device_fini(adev);
>> -kfree(adev);
>> -dev->dev_private = NULL;
>> -/* Don't request EX mode too frequently which is attacking */
>> -msleep(5000);
>> -dev_err(>pdev->dev, "retry init %d\n", retry);
>> -goto retry_init;
>> -} else if (r) {
>> +if (r) {
>>  dev_err(>pdev->dev, "Fatal error during GPU init\n");
>>  goto out;
>>  }
>
>
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu:fix gpu recover missing skipping(v2)

2017-11-08 Thread Christian König

Am 08.11.2017 um 08:08 schrieb Monk Liu:

if app close CTX right after IB submit, gpu recover
will fail to find out the entity behind this guilty
job thus lead to no job skipping for this guilty job.

to fix this corner case just move the increasement of
job->karma out of the entity iteration.

v2:
only do karma increasment if bad->s_priority != KERNEL
because we always consider KERNEL job be correct and always
want to recover an unfinished kernel job (sometimes kernel
job is interrupted by VF FLR or other GPU hang event)


Good point, my rb still stands on that version.

Christian.



Change-Id: I33e9e959e182d7e002a2108e565cb898acac4f9c
Signed-off-by: Monk Liu 
---
  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
index 7aa6455..c999026 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
@@ -463,7 +463,8 @@ void amd_sched_hw_job_reset(struct amd_gpu_scheduler 
*sched, struct amd_sched_jo
}
spin_unlock(>job_list_lock);
  
-	if (bad) {

+   if (bad && bad->s_priority != AMD_SCHED_PRIORITY_KERNEL) {
+   atomic_inc(>karma);
/* don't increase @bad's karma if it's from KERNEL RQ,
 * becuase sometimes GPU hang would cause kernel jobs (like VM 
updating jobs)
 * corrupt but keep in mind that kernel jobs always considered 
good.
@@ -474,7 +475,7 @@ void amd_sched_hw_job_reset(struct amd_gpu_scheduler 
*sched, struct amd_sched_jo
spin_lock(>lock);
list_for_each_entry_safe(entity, tmp, >entities, 
list) {
if (bad->s_fence->scheduled.context == 
entity->fence_context) {
-   if (atomic_inc_return(>karma) > 
bad->sched->hang_limit)
+   if (atomic_read(>karma) > 
bad->sched->hang_limit)
if (entity->guilty)

atomic_set(entity->guilty, 1);
break;



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


Re: [PATCH 2/2] drm/amd/scheduler: add WARN_ON for s_fence->parent

2017-11-08 Thread Christian König

Am 08.11.2017 um 07:46 schrieb Chunming Zhou:

Change-Id: I1f6c81002fb2ba21c17cdc14fdde86579b28374e
Signed-off-by: Chunming Zhou 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
index bb8a28b8b993..2db66cb96e92 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
@@ -241,6 +241,7 @@ void amd_sched_entity_fini(struct amd_gpu_scheduler *sched,
amd_sched_fence_scheduled(s_fence);
dma_fence_set_error(_fence->finished, -ESRCH);
amd_sched_fence_finished(s_fence);
+   WARN_ON(s_fence->parent);
dma_fence_put(_fence->finished);
sched->ops->free_job(job);
}



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


Re: [PATCH] drm/amdgpu:fix gpu recover missing skipping

2017-11-08 Thread Christian König

Am 08.11.2017 um 07:39 schrieb Monk Liu:

if app close CTX right after IB submit, gpu recover
will failed to find out the entity/ctx behind the guilty
job thus lead to bad job skipping in scheduler failed

to fix this corner case just move the job->karma increasing
out of the condition that the backing entity was found
that way the job itself will be "guilty" anyway

Change-Id: Ia30f02df9297a343d6d8dace496e237827dd1548
Signed-off-by: Monk Liu 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/scheduler/gpu_scheduler.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
index 7aa6455..720fd1b 100644
--- a/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/amd/scheduler/gpu_scheduler.c
@@ -464,6 +464,7 @@ void amd_sched_hw_job_reset(struct amd_gpu_scheduler 
*sched, struct amd_sched_jo
spin_unlock(>job_list_lock);
  
  	if (bad) {

+   atomic_inc(>karma);
/* don't increase @bad's karma if it's from KERNEL RQ,
 * becuase sometimes GPU hang would cause kernel jobs (like VM 
updating jobs)
 * corrupt but keep in mind that kernel jobs always considered 
good.
@@ -474,7 +475,7 @@ void amd_sched_hw_job_reset(struct amd_gpu_scheduler 
*sched, struct amd_sched_jo
spin_lock(>lock);
list_for_each_entry_safe(entity, tmp, >entities, 
list) {
if (bad->s_fence->scheduled.context == 
entity->fence_context) {
-   if (atomic_inc_return(>karma) > 
bad->sched->hang_limit)
+   if (atomic_read(>karma) > 
bad->sched->hang_limit)
if (entity->guilty)

atomic_set(entity->guilty, 1);
break;



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


Re: [PATCH] drm/amdgpu: revise retry init to fully cleanup driver

2017-11-08 Thread Christian König

Am 08.11.2017 um 04:29 schrieb Pixel Ding:

Retry at drm_dev_register instead of amdgpu_device_init.

Signed-off-by: Pixel Ding 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 ++
  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 11 +--
  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c| 15 ++-
  3 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index bf2b008..4ef2b1b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2390,6 +2390,8 @@ int amdgpu_device_init(struct amdgpu_device *adev,
amdgpu_virt_mmio_blocked(adev) &&
!amdgpu_virt_wait_reset(adev)) {
dev_err(adev->dev, "VF exclusive mode timeout\n");
+   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
+   adev->virt.ops = NULL;


Why is that necessary? Maybe put this into some SRIOV specific fini 
function?


Apart from that patch looks good to me and is Acked-by: Christian König 
.


Regards,
Christian.


r = -EAGAIN;
goto failed;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6b11a75..eaccd4b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -565,12 +565,13 @@ static int amdgpu_kick_out_firmware_fb(struct pci_dev 
*pdev)
return 0;
  }
  
+

  static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
  {
struct drm_device *dev;
unsigned long flags = ent->driver_data;
-   int ret;
+   int ret, retry = 0;
  
  	if ((flags & AMD_EXP_HW_SUPPORT) && !amdgpu_exp_hw_support) {

DRM_INFO("This hardware requires experimental hardware 
support.\n"
@@ -603,8 +604,14 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
  
  	pci_set_drvdata(pdev, dev);
  
+retry_init:

ret = drm_dev_register(dev, ent->driver_data);
-   if (ret)
+   if (ret == -EAGAIN && ++retry <= 3) {
+   DRM_INFO("retry init %d\n", retry);
+   /* Don't request EX mode too frequently which is attacking */
+   msleep(5000);
+   goto retry_init;
+   } else if (ret)
goto err_pci;
  
  	return 0;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 1d56b5b..65360cd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -84,7 +84,7 @@ void amdgpu_driver_unload_kms(struct drm_device *dev)
  int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags)
  {
struct amdgpu_device *adev;
-   int r, acpi_status, retry = 0;
+   int r, acpi_status;
  
  #ifdef CONFIG_DRM_AMDGPU_SI

if (!amdgpu_si_support) {
@@ -120,7 +120,6 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
}
}
  #endif
-retry_init:
  
  	adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);

if (adev == NULL) {
@@ -143,17 +142,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
 * VRAM allocation
 */
r = amdgpu_device_init(adev, dev, dev->pdev, flags);
-   if (r == -EAGAIN && ++retry <= 3) {
-   adev->virt.caps &= ~AMDGPU_SRIOV_CAPS_RUNTIME;
-   adev->virt.ops = NULL;
-   amdgpu_device_fini(adev);
-   kfree(adev);
-   dev->dev_private = NULL;
-   /* Don't request EX mode too frequently which is attacking */
-   msleep(5000);
-   dev_err(>pdev->dev, "retry init %d\n", retry);
-   goto retry_init;
-   } else if (r) {
+   if (r) {
dev_err(>pdev->dev, "Fatal error during GPU init\n");
goto out;
}



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


Re: [PATCH] drm/amdgpu: bypass lru touch for KIQ ring submission

2017-11-08 Thread Christian König

Am 08.11.2017 um 03:30 schrieb Pixel Ding:

KIQ ring submission is used for register accessing on SRIOV
VF that could happen both in irq enabled and irq disabled cases.
Inversion lock could happen on adev->ring_lru_list_lock, while
this operation is useless and just adds overhead in this use
case.

Signed-off-by: Pixel Ding 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
index e5ece1f..a98fbbb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
@@ -136,7 +136,8 @@ void amdgpu_ring_commit(struct amdgpu_ring *ring)
if (ring->funcs->end_use)
ring->funcs->end_use(ring);
  
-	amdgpu_ring_lru_touch(ring->adev, ring);

+   if (ring->funcs->type != AMDGPU_RING_TYPE_KIQ)
+   amdgpu_ring_lru_touch(ring->adev, ring);
  }
  
  /**



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


[PATCH] drm/amd/pp: fix dpm randomly failed on Vega10

2017-11-08 Thread Rex Zhu
Change-Id: I15e562ddff64cf73262ece75f08df60fedc1de1a
Signed-off-by: Rex Zhu 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 29 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h |  1 +
 2 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 7db3fbe..9d4955e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -753,6 +753,7 @@ static int vega10_hwmgr_backend_init(struct pp_hwmgr *hwmgr)
uint32_t config_telemetry = 0;
struct pp_atomfwctrl_voltage_table vol_table;
struct cgs_system_info sys_info = {0};
+   uint32_t reg;
 
data = kzalloc(sizeof(struct vega10_hwmgr), GFP_KERNEL);
if (data == NULL)
@@ -859,6 +860,16 @@ static int vega10_hwmgr_backend_init(struct pp_hwmgr 
*hwmgr)
advanceFanControlParameters.usFanPWMMinLimit *
hwmgr->thermal_controller.fanInfo.ulMaxRPM / 100;
 
+   reg = soc15_get_register_offset(DF_HWID, 0,
+   mmDF_CS_AON0_DramBaseAddress0_BASE_IDX,
+   mmDF_CS_AON0_DramBaseAddress0);
+   data->mem_channels = (cgs_read_register(hwmgr->device, reg) &
+   DF_CS_AON0_DramBaseAddress0__IntLvNumChan_MASK) >>
+   DF_CS_AON0_DramBaseAddress0__IntLvNumChan__SHIFT;
+   PP_ASSERT_WITH_CODE(data->mem_channels < ARRAY_SIZE(channel_number),
+   "Mem Channel Index Exceeded maximum!",
+   return -EINVAL);
+
return result;
 }
 
@@ -1777,7 +1788,7 @@ static int vega10_populate_all_memory_levels(struct 
pp_hwmgr *hwmgr)
struct vega10_single_dpm_table *dpm_table =
&(data->dpm_table.mem_table);
int result = 0;
-   uint32_t i, j, reg, mem_channels;
+   uint32_t i, j;
 
for (i = 0; i < dpm_table->count; i++) {
result = vega10_populate_single_memory_level(hwmgr,
@@ -1801,20 +1812,10 @@ static int vega10_populate_all_memory_levels(struct 
pp_hwmgr *hwmgr)
i++;
}
 
-   reg = soc15_get_register_offset(DF_HWID, 0,
-   mmDF_CS_AON0_DramBaseAddress0_BASE_IDX,
-   mmDF_CS_AON0_DramBaseAddress0);
-   mem_channels = (cgs_read_register(hwmgr->device, reg) &
-   DF_CS_AON0_DramBaseAddress0__IntLvNumChan_MASK) >>
-   DF_CS_AON0_DramBaseAddress0__IntLvNumChan__SHIFT;
-   PP_ASSERT_WITH_CODE(mem_channels < ARRAY_SIZE(channel_number),
-   "Mem Channel Index Exceeded maximum!",
-   return -1);
-
-   pp_table->NumMemoryChannels = cpu_to_le16(mem_channels);
+   pp_table->NumMemoryChannels = (uint16_t)(data->mem_channels);
pp_table->MemoryChannelWidth =
-   cpu_to_le16(HBM_MEMORY_CHANNEL_WIDTH *
-   channel_number[mem_channels]);
+   (uint16_t)(HBM_MEMORY_CHANNEL_WIDTH *
+   channel_number[data->mem_channels]);
 
pp_table->LowestUclkReservedForUlv =
(uint8_t)(data->lowest_uclk_reserved_for_ulv);
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h 
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
index b4b461c3..8f7358c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.h
@@ -389,6 +389,7 @@ struct vega10_hwmgr {
uint32_t   config_telemetry;
uint32_t   smu_version;
uint32_t   acg_loop_state;
+   uint32_t   mem_channels;
 };
 
 #define VEGA10_DPM2_NEAR_TDP_DEC  10
-- 
1.9.1

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


Re: [PATCH] drm/amdgpu:remove debugfs file in amdgpu_device_finish

2017-11-08 Thread Christian König

It’s tested and proved working correctly.
Well testing doesn't prove anything. Please enable at least KASAN, 
lockdep and kmemleak and then try again.


I'm pretty sure that at least kmemlead and lockdep will bail out quite a 
bunch of warnings.


Regards,
Christian.

Am 08.11.2017 um 03:40 schrieb Ding, Pixel:

Hi Christian,

The retry_init only handles the failure caused by exclusive mode timeout. It 
checks the MMIO to see if there’s exclusive mode timeout, and retry init if 
there’s, otherwise just return error.

For exclusive timeout case, the host layer issues a FLR on this VF so driver 
needn't cleanup hardware status, amdgpu_device_fini here just is used to 
cleanup the software.

It’s tested and proved working correctly. Although the debugfs files are only 
the tip of the iceberg, it’s the only issue we found in this version of 
retry_init.

—
Sincerely Yours,
Pixel







On 07/11/2017, 5:56 PM, "Koenig, Christian"  wrote:


Hi Gary,

well that patch is nonsense to begin with.

amdgpu_device_init() does quite a bunch of other initialization which is
not cleaned up by amdgpu_device_fini(), so the debugfs files are only
the tip of the iceberg here.

Please revert 2316518efc459928ad1d3d2d3511ea5fbda19475 and then we can
try again from scratch.

What we need to do is return -EAGAIN from amdgpu_driver_load_kms. Then
in amdgpu_pci_probe() we can catch that error and call
drm_dev_register() multiple times if necessary.

This way we can also optionally pci_disable_device() /
pci_enable_device() between tries if appropriate.

Regards,
Christian.

Am 07.11.2017 um 09:02 schrieb Sun, Gary:

Hi Christian,

The feature is for GPU virtualization and has been checked in, you can refer to 
the following patch or commit 75b126427778218b36cfb68637e4f8d0e584b8ef.

  From 2316518efc459928ad1d3d2d3511ea5fbda19475 Mon Sep 17 00:00:00 2001
From: pding 
Date: Mon, 23 Oct 2017 17:22:09 +0800
Subject: [PATCH 001/121] drm/amdgpu: retry init if it fails due to exclusive 
mode timeout (v3)

The exclusive mode has real-time limitation in reality, such like being
done in 300ms. It's easy observed if running many VF/VMs in single host
with heavy CPU workload.

If we find the init fails due to exclusive mode timeout, try it again.

v2:
   - rewrite the condition for readable value.

v3:
   - fix typo, add comments for sleep

Acked-by: Alex Deucher 
Signed-off-by: pding 
Signed-off-by: Alex Deucher 
Signed-off-by: Gary Sun 
---
   drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |   10 ++
   drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c|   15 +--
   2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 125f77d..385b10e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2303,6 +2303,15 @@ int amdgpu_device_init(struct amdgpu_device *adev,
   
   	r = amdgpu_init(adev);

if (r) {
+   /* failed in exclusive mode due to timeout */
+   if (amdgpu_sriov_vf(adev) &&
+   !amdgpu_sriov_runtime(adev) &&
+   amdgpu_virt_mmio_blocked(adev) &&
+   !amdgpu_virt_wait_reset(adev)) {
+   dev_err(adev->dev, "VF exclusive mode timeout\n");
+   r = -EAGAIN;
+   goto failed;
+   }
dev_err(adev->dev, "amdgpu_init failed\n");
amdgpu_vf_error_put(adev, AMDGIM_ERROR_VF_AMDGPU_INIT_FAIL, 0, 
0);
amdgpu_fini(adev);
@@ -2390,6 +2399,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
amdgpu_vf_error_trans_all(adev);
if (runtime)
vga_switcheroo_fini_domain_pm_ops(adev->dev);
+
return r;
   }
   
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c

index 720139e..f313eee 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -86,7 +86,7 @@ void amdgpu_driver_unload_kms(struct drm_device *dev)
   int amdgpu_driver_load_kms(struct drm_device *dev, unsigned long flags)
   {
struct amdgpu_device *adev;
-   int r, acpi_status;
+   int r, acpi_status, retry = 0;
   
   #ifdef CONFIG_DRM_AMDGPU_SI

if (!amdgpu_si_support) {
@@ -122,6 +122,7 @@ int amdgpu_driver_load_kms(struct drm_device *dev, unsigned 
long flags)
}
}
   #endif
+retry_init:
   
   	adev = kzalloc(sizeof(struct amdgpu_device), GFP_KERNEL);

if (adev == NULL) {
@@ -144,7 +145,17 @@ int amdgpu_driver_load_kms(struct drm_device *dev, 
unsigned long flags)
 * VRAM allocation
 */
r = amdgpu_device_init(adev, dev, dev->pdev, flags);
-   if (r) {
+   if (r == -EAGAIN && ++retry <= 3)