Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

Sounds good! One thing to confirm, If the original location is already in the invisible, will the notifier callback to move the bo from invisible to visible? if it is true and the logic is already available in the kernel, can we use NO_CPU_ACCESS flag by default to accomplish the similar

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

On 30/06/17 10:55 AM, Mao, David wrote: > Vulkan allows the application to decide whether it wants the allocation > to be host visible and device local. > If we drop the flag, what will happen if we did not set the > NO_CPU_ACCESS flag? > Will it fail the map in case the allocation could be

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

Vulkan allows the application to decide whether it wants the allocation to be host visible and device local. If we drop the flag, what will happen if we did not set the NO_CPU_ACCESS flag? Will it fail the map in case the allocation could be placed in invisible heap then? Thanks. Best Regards,

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On 29/06/17 07:05 PM, Daniel Vetter wrote: > On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote: >> On 29/06/17 05:23 PM, Christian König wrote: >>> Am 29.06.2017 um 04:35 schrieb Michel Dänzer: On 29/06/17 08:26 AM, John Brooks wrote: > On Wed, Jun 28, 2017 at 03:05:32PM

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On 2017-06-29 09:56 PM, John Brooks wrote: On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote: On 29/06/17 08:26 AM, John Brooks wrote: On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: Am 28.06.2017 um 04:33 schrieb John Brooks: When the

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On Thu, Jun 29, 2017 at 11:35:53AM +0900, Michel Dänzer wrote: > On 29/06/17 08:26 AM, John Brooks wrote: > > On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: > >> Am 28.06.2017 um 04:33 schrieb John Brooks: > >>> When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

On 30/06/17 12:03 AM, Marek Olšák wrote: > Do you have any concern if we also stop using the CPU_ACCESS flag on radeon? No concern from my side for radeon. > On Thu, Jun 29, 2017 at 4:51 PM, Christian König > wrote: >> Yeah, I was thinking something similar. >> >> See

Re: [PATCH] drm/amdgpu: fix vblank_time when displays are off

On 30/06/17 05:16 AM, Alex Deucher wrote: > If the displays are off, set the vblank time to max to make > sure mclk switching is enabled. Avoid mclk getting set > to high when no displays are attached. > > bug: https://bugs.freedesktop.org/show_bug.cgi?id=101528 > fixes: 09be4a5219

Re: [PATCH] drm/amdgpu: Make KIQ read/write register routine be atomic

On 30/06/17 06:08 AM, Shaoyun Liu wrote: > 1. Use spin lock instead of mutex in KIQ > 2. Directly write to KIQ fence address instead of using fence_emit() > 3. Disable the interrupt for KIQ read/write and use CPU polling This list indicates that this patch should be split up in at least three

Re: Resizeable PCI BAR support V5

Hello Christian, I've running this since you've sent it on-top of amd-staging-4.11. But I think my poor little FUJITSU PRIMERGY TX150 S7, Xeon X3470 (Nehalem), PCIe 2.0, 24 GB is to old for this stuff... [1.066475] pci :05:00.0: VF(n) BAR0 space: [mem 0x-0x0003 64bit]

[PATCH] drm/amdgpu: Make KIQ read/write register routine be atomic

1. Use spin lock instead of mutex in KIQ 2. Directly write to KIQ fence address instead of using fence_emit() 3. Disable the interrupt for KIQ read/write and use CPU polling Change-Id: Id3693a2878ce1338f55aee3def6e7fc0f6b81996 Signed-off-by: Shaoyun Liu ---

Re: [PATCH] drm/radeon: add header comment for clarification to vce_v2_0_enable_mgcg()

Quoting Alex Deucher : On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva wrote: Add function header comment to make it clear that local variable sw_cg is used for debugging and it should not be removed. Addresses-Coverity-ID: 1198635 Cc:

Re: [PATCH] drm/radeon: add header comment for clarification to vce_v2_0_enable_mgcg()

On Thu, Jun 29, 2017 at 1:38 PM, Gustavo A. R. Silva wrote: > Add function header comment to make it clear that local variable sw_cg > is used for debugging and it should not be removed. > > Addresses-Coverity-ID: 1198635 > Cc: Alex Deucher >

[PATCH] drm/radeon: add header comment for clarification to vce_v2_0_enable_mgcg()

Add function header comment to make it clear that local variable sw_cg is used for debugging and it should not be removed. Addresses-Coverity-ID: 1198635 Cc: Alex Deucher Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/radeon/vce_v2_0.c |

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

Do you have any concern if we also stop using the CPU_ACCESS flag on radeon? Thanks, Marek On Thu, Jun 29, 2017 at 4:51 PM, Christian König wrote: > Yeah, I was thinking something similar. > > See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that CPU

Re: Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

Yeah, I was thinking something similar. See the intention behind CPU_ACCESS_REQUIRED is to always guarantee that CPU access is immediately possible. If you ask me that is not really useful for the UMD and was never meant to be used by Mesa (only the closed source UMD and some kernel internal

Deprecation of AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED

Hi, Given how our memory manager works and the guesswork that UMDs have to do to determine whether to set the flag, I think the flag isn't useful. I'm proposing that CPU_ACCESS_REQUIRED: - will be deprecated. - It will remain to be accepted by the kernel driver, but it will either not have any

RE: [PATCH v2] drm/amdgpu: fix the memory corruption on S3

> -Original Message- > From: Christian König [mailto:deathsim...@vodafone.de] > Sent: Thursday, June 29, 2017 4:17 AM > To: Huang, Ray; amd-gfx@lists.freedesktop.org; Deucher, Alexander; Koenig, > Christian > Cc: Huan, Alvin; Qiao, Joe(Markham); Jiang, Sonny; Wang, Ken; Yuan, Xiaojie >

RE: [PATCH 4/8] ASoC: AMD: added condition checks for CZ specific code

-Original Message- From: Mark Brown [mailto:broo...@kernel.org] Sent: Wednesday, June 28, 2017 11:36 PM To: Alex Deucher Cc: dri-de...@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org; airl...@gmail.com; Mukunda, Vijendar; rajeevkumar.li...@gmail.com;

Re: [gpu-drm-radeon] question about potential dead code in vce_v2_0_enable_mgcg()

On Wed, Jun 28, 2017 at 7:08 PM, Gustavo A. R. Silva wrote: > Hi Alex, > > Quoting "Deucher, Alexander" : > >>> -Original Message- >>> From: Gustavo A. R. Silva [mailto:garsi...@embeddedor.com] >>> Sent: Wednesday, June 28, 2017 10:22 AM

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On Thu, Jun 29, 2017 at 06:58:05PM +0900, Michel Dänzer wrote: > On 29/06/17 05:23 PM, Christian König wrote: > > Am 29.06.2017 um 04:35 schrieb Michel Dänzer: > >> On 29/06/17 08:26 AM, John Brooks wrote: > >>> On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: > > > >

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

On 29/06/17 05:23 PM, Christian König wrote: > Am 29.06.2017 um 04:35 schrieb Michel Dänzer: >> On 29/06/17 08:26 AM, John Brooks wrote: >>> On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: > > Instead of the flag being set in stone at BO creation, set the flag > when a

Re: [PATCH v2] drm/amdgpu: fix the memory corruption on S3

On Thu, Jun 29, 2017 at 04:16:53PM +0800, Christian König wrote: > Am 29.06.2017 um 10:09 schrieb Huang Rui: > > psp->cmd will be used on resume phase, so we can not free it on hw_init. > > Otherwise, a memory corruption will be triggered. > > > > Signed-off-by: Huang Rui > >

Re: [PATCH 4/5] drm/amdgpu: Set/clear CPU_ACCESS_REQUIRED flag on page fault and CS

Am 29.06.2017 um 04:35 schrieb Michel Dänzer: On 29/06/17 08:26 AM, John Brooks wrote: On Wed, Jun 28, 2017 at 03:05:32PM +0200, Christian König wrote: Am 28.06.2017 um 04:33 schrieb John Brooks: When the AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED flag is given by userspace, it should only be

Re: [PATCH v2] drm/amdgpu: fix the memory corruption on S3

Am 29.06.2017 um 10:09 schrieb Huang Rui: psp->cmd will be used on resume phase, so we can not free it on hw_init. Otherwise, a memory corruption will be triggered. Signed-off-by: Huang Rui --- V1 -> V2: - remove "cmd" variable. - fix typo of check. Alex, Christian, This

Re: [PATCH] drm/amdgpu: fix the memory corruption on S3

On Thu, Jun 29, 2017 at 04:07:33PM +0800, Michel Dänzer wrote: > On 29/06/17 04:59 PM, Huang Rui wrote: > > On Thu, Jun 29, 2017 at 03:34:57PM +0800, Michel Dänzer wrote: > >> On 29/06/17 04:03 PM, Huang Rui wrote: > >>> psp->cmd will be used on resume phase, so we can not free it on hw_init. >

Re: [PATCH 3/5] drm/amdgpu: Track time of last page fault and last CS move in struct amdgpu_bo

Am 29.06.2017 um 00:59 schrieb John Brooks: On Wed, Jun 28, 2017 at 03:06:47PM +0200, Christian König wrote: Am 28.06.2017 um 04:33 schrieb John Brooks: Signed-off-by: John Brooks --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 3 +++

[PATCH v2] drm/amdgpu: fix the memory corruption on S3

psp->cmd will be used on resume phase, so we can not free it on hw_init. Otherwise, a memory corruption will be triggered. Signed-off-by: Huang Rui --- V1 -> V2: - remove "cmd" variable. - fix typo of check. Alex, Christian, This is the final fix for vega10 S3. The random

Re: drm/amdgpu: Fix vram_page_split parameter description

Reviewed-by: Christian König . Regards, Christian. Am 28.06.2017 um 21:26 schrieb Kent Russell: The default was changed to 512 from 1024, but the default in the description wasn't updated. Kent ___ amd-gfx mailing list

Re: [PATCH] drm/amdgpu: fix the memory corruption on S3

On 29/06/17 04:59 PM, Huang Rui wrote: > On Thu, Jun 29, 2017 at 03:34:57PM +0800, Michel Dänzer wrote: >> On 29/06/17 04:03 PM, Huang Rui wrote: >>> psp->cmd will be used on resume phase, so we can not free it on hw_init. >>> Otherwise, a memory corruption will be triggered. >>> >>>

Re: [PATCH] drm/amdgpu: fix the memory corruption on S3

Indeed a nice catch. Just skimming over the PSP code, wouldn't it be simpler to temporary allocate the cmd buffer in psp_np_fw_load()? Doesn't looks like that is used outside that function. Might even be possible to just allocate the buffer on the stack. Regards, Christian. Am 29.06.2017

Re: [PATCH] drm/amdgpu: fix the memory corruption on S3

On Thu, Jun 29, 2017 at 03:34:57PM +0800, Michel Dänzer wrote: > On 29/06/17 04:03 PM, Huang Rui wrote: > > psp->cmd will be used on resume phase, so we can not free it on hw_init. > > Otherwise, a memory corruption will be triggered. > > > > Signed-off-by: Huang Rui > > --- >

Re: [PATCH] drm/amdgpu: fix the memory corruption on S3

On 29/06/17 04:03 PM, Huang Rui wrote: > psp->cmd will be used on resume phase, so we can not free it on hw_init. > Otherwise, a memory corruption will be triggered. > > Signed-off-by: Huang Rui > --- > > Alex, Christian, > > This is the final fix for vega10 S3. The random

[PATCH] drm/amdgpu: fix the memory corruption on S3

psp->cmd will be used on resume phase, so we can not free it on hw_init. Otherwise, a memory corruption will be triggered. Signed-off-by: Huang Rui --- Alex, Christian, This is the final fix for vega10 S3. The random memory corruption issue is root caused. Thanks, Ray ---