Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
> From: Christian König
>
> Try to resize BAR0 to let CPU access all of VRAM.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
> 4 files changed, 40 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index 3b81ded..905ded9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
> *adev, struct ttm_tt *ttm,
> struct ttm_mem_reg *mem);
> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
> u64 base);
> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
> int amdgpu_ttm_init(struct amdgpu_device *adev);
> void amdgpu_ttm_fini(struct amdgpu_device *adev);
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 118f4e6..92955fe 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
> struct amdgpu_mc *mc)
> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
> }
>
> +/**
> + * amdgpu_resize_bar0 - try to resize BAR0
> + *
> + * @adev: amdgpu_device pointer
> + *
> + * Try to resize BAR0 to make all VRAM CPU accessible.
> + */
> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> +{
> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> + int r;
> +
> + r = pci_resize_resource(adev->pdev, 0, size);
> +
> + if (r == -ENOTSUPP) {
> + /* The hardware don't support the extension. */
> + return;
> +
> + } else if (r == -ENOSPC) {
> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
> + } else if (r) {
> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> + }
> +
> + /* Reinit the doorbell mapping, it is most likely moved as well */
> + amdgpu_doorbell_fini(adev);
> + BUG_ON(amdgpu_doorbell_init(adev));
> +}
> +
> /*
> * GPU helpers function.
> */
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> index dc9b6d6..36a7aa5 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> - /* Could aper size report 0 ? */
> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
> 1024ULL;
>
> + if (!(adev->flags & AMD_IS_APU))
> + amdgpu_resize_bar0(adev);
> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
> #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index c087b00..7761ad3 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
> break;
> }
> adev->mc.vram_width = numchan * chansize;
> - /* Could aper size report 0 ? */
> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> /* size in MB on si */
> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
> 1024ULL;
>
> + if (!(adev->flags & AMD_IS_APU))
> + amdgpu_resize_bar0(adev);
> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> +
> #ifdef CONFIG_X86_64
> if (adev->flags & AMD_IS_APU) {
> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
> --
> 2.7.4
>
> _
Re: Linux 4.11: Reported regressions as of Tuesday, 20176-03-14
Am 15.03.2017 um 02:59 schrieb Michel Dänzer: [ Moving this sub-thread to the amd-gfx mailing list ] On 14/03/17 07:02 PM, Thorsten Leemhuis wrote: Hi! Find below my first regression report for Linux 4.11. It lists 9 regressions I'm currently aware of. [...] Desc: DRM BUG while initializing cape verde (2nd card) Repo: 2017-03-13 https://bugzilla.kernel.org/show_bug.cgi?id=194867 Stat: n/a Note: patch proposed by reporter I don't see any patch. Looks like the amdgpu driver has never fully initialized GDS support for SI family GPUs, and this now triggers the DRM_MM_BUG_ON which was added to drm_mm_init in 4.11. AMD folks, should this be addressed by fleshing out SI GDS support, or by completely disabling GDS initialization for SI? Uff, good question. IIRC GDS was significantly different between SI and CIK in the hardware and requires pinned buffers on SI (userspace needs to know the physical address of the buffer). So the current implementation most likely doesn't work as expected. I would say disable it for now, but keep any existing code for at least one release. If nobody finds time to fix it properly (which is likely) we can throw away that and move on. Christian. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: Linux 4.11: Reported regressions as of Tuesday, 20176-03-14
On 15/03/17 04:33 PM, Christian König wrote: > Am 15.03.2017 um 02:59 schrieb Michel Dänzer: >> [ Moving this sub-thread to the amd-gfx mailing list ] >> >> On 14/03/17 07:02 PM, Thorsten Leemhuis wrote: >>> Hi! Find below my first regression report for Linux 4.11. It lists 9 >>> regressions I'm currently aware of. >> [...] >> >>> Desc: DRM BUG while initializing cape verde (2nd card) >>> Repo: 2017-03-13 https://bugzilla.kernel.org/show_bug.cgi?id=194867 >>> Stat: n/a >>> Note: patch proposed by reporter >> I don't see any patch. >> >> Looks like the amdgpu driver has never fully initialized GDS support for >> SI family GPUs, and this now triggers the DRM_MM_BUG_ON which was added >> to drm_mm_init in 4.11. >> >> AMD folks, should this be addressed by fleshing out SI GDS support, or >> by completely disabling GDS initialization for SI? > Uff, good question. IIRC GDS was significantly different between SI and > CIK in the hardware and requires pinned buffers on SI (userspace needs > to know the physical address of the buffer). > > So the current implementation most likely doesn't work as expected. > > I would say disable it for now, but keep any existing code for at least > one release. If nobody finds time to fix it properly (which is likely) > we can throw away that and move on. Any takers for 4.11? :) -- 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
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all
Polaris variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well */
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc
[PATCH] drm/amdgpu: fix the clearing wb size
The clearing wb size should be the one that it is assigned.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b0ac610..b0e0471 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -550,7 +550,7 @@ static int amdgpu_wb_init(struct amdgpu_device *adev)
int r;
if (adev->wb.wb_obj == NULL) {
- r = amdgpu_bo_create_kernel(adev, AMDGPU_MAX_WB * 4,
+ r = amdgpu_bo_create_kernel(adev, AMDGPU_MAX_WB *
sizeof(uint32_t),
PAGE_SIZE, AMDGPU_GEM_DOMAIN_GTT,
&adev->wb.wb_obj,
&adev->wb.gpu_addr,
(void **)&adev->wb.wb);
@@ -564,7 +564,7 @@ static int amdgpu_wb_init(struct amdgpu_device *adev)
memset(&adev->wb.used, 0, sizeof(adev->wb.used));
/* clear wb memory */
- memset((char *)adev->wb.wb, 0, AMDGPU_GPU_PAGE_SIZE);
+ memset((char *)adev->wb.wb, 0, AMDGPU_MAX_WB *
sizeof(uint32_t));
}
return 0;
--
2.7.4
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Does that means we don't need invisible vram later?
David
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
amd-gfx@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-de...@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> Is it possible on Carrizo asics? Or only supports on newer asics?
>
> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> wrote:
>> From: Christian König
>>
>> Try to resize BAR0 to let CPU access all of VRAM.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
>> +
>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
>> 4 files changed, 40 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index 3b81ded..905ded9 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
>> *adev, struct ttm_tt *ttm,
>> struct ttm_mem_reg *mem);
>> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
>> *mc, u64 base);
>> void amdgpu_gtt_location(struct amdgpu_device *adev, struct
>> amdgpu_mc *mc);
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
>> int amdgpu_ttm_init(struct amdgpu_device *adev);
>> void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index 118f4e6..92955fe 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
>> struct amdgpu_mc *mc)
>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>> }
>>
>> +/**
>> + * amdgpu_resize_bar0 - try to resize BAR0
>> + *
>> + * @adev: amdgpu_device pointer
>> + *
>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>> + */
>> +void amdgpu_resize_bar0(struct amdgpu_device *adev) {
>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
>> + int r;
>> +
>> + r = pci_resize_resource(adev->pdev, 0, size);
>> +
>> + if (r == -ENOTSUPP) {
>> + /* The hardware don't support the extension. */
>> + return;
>> +
>> + } else if (r == -ENOSPC) {
>> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
>> + } else if (r) {
>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>> + }
>> +
>> + /* Reinit the doorbell mapping, it is most likely moved as well */
>> + amdgpu_doorbell_fini(adev);
>> + BUG_ON(amdgpu_doorbell_init(adev));
>> +}
>> +
>> /*
>>* GPU helpers function.
>>*/
>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> index dc9b6d6..36a7aa5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
>> break;
>> }
>> adev->mc.vram_width = numchan * chansize;
>> - /* Could aper size report 0 ? */
>> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>> /* size in MB on si */
>> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
>> 1024ULL;
>> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL
>> * 1024ULL;
>>
>> + if (!(adev->flags & AMD_IS_APU))
>> + amdgpu_resize_bar0(adev);
>> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>> +
>> #ifdef CONFIG_X86_64
>> if (adev->flags & AMD_IS_APU) {
>> adev->mc.aper_base =
>> ((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22; diff --git
>> a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> index c087b00..7761ad3 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>> @@ -459,13 +459,15 @
Re: [rfc] amdgpu/sync_file shared semaphores
On Wed, Mar 15, 2017 at 11:09:39AM +1000, Dave Airlie wrote: > On 14 March 2017 at 18:53, Daniel Vetter wrote: > > On Tue, Mar 14, 2017 at 10:50:49AM +1000, Dave Airlie wrote: > >> This contains one libdrm patch and 4 kernel patches. > >> > >> The goal is to implement the Vulkan KHR_external_semaphore_fd interface > >> for permanent semaphore behaviour for radv. > >> > >> This code tries to enhance sync file to add the required behaviour > >> (which is mostly being able to replace the fence backing the sync file), > >> it also introduces new API to amdgpu to create/destroy/export/import the > >> sync_files which we store in an idr there, rather than fds. > >> > >> There is a possibility we should share the amdgpu_sem object tracking > >> code for other drivers, maybe we should move that to sync_file as well, > >> but I'm open to suggestions for whether this is a useful approach for > >> other drivers. > > > > Yeah, makes sense. I couldn't google the spec and didn't bother to figure > > out where my intel khronos login went, so didn't double-check precise > > semantics, just dropped a question. Few more things on the actual > > sync_file stuff itself. > > > > Really big wish here is for some igts using the debug/testing fence stuff > > we have in vgem so that we can validate the corner-cases of fence > > replacement and make sure nothing falls over. Especially with all the rcu > > dancing sync_file/dma_fence have become non-trival, exhaustive testing is > > needed here imo. > > We'd have to add vgem specific interfaces to trigger the replacement > path though, > since the replacement path is only going to be used for the semaphore > sematics. > > Suggestions on how to test better welcome! Yeah, vgem semaphore replacement ioctl is what I had in mind. And I guess if you don't get around to it, we will when we do the i915 side of this :-) -Daniel > > > > > Also, NULL sync_file->fence is probably what we want for the future fences > > (which android wants to keep tilers well-fed by essentially looping the > > entire render pipeline on itself), so this goes into the right direction > > for sure. I think, but coffee kicked in already :-) > > Dave. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores
On Wed, Mar 15, 2017 at 01:01:19AM +0100, Marek Olšák wrote: > While it's nice that you are all having fun here, I don't think that's > the way to communicate this. > > The truth is, if AMD had an open source driver using the semaphores > (e.g. Vulkan) and if the libdrm semaphore code was merged, Dave > wouldn't be able to change it, ever. If a dependent open source > project relies on some libdrm interface, that interface is set in > stone. So AMD wouldn't be able to change it either. Unfortunately, > such an open source project doesn't exist, so the community can assume > that this libdrm code is still in the "initial design phase". Dave has > an upper hand here, because he actually has an open source project > that will use this, while AMD doesn't (yet). However, AMD can still > negotiate some details here, i.e. do a proper review. Fully agreed, that's why there was this "internal" qualifier. If you do this internally, then it's not final, if you discuss it here on the m-l, it actually matters. So drag your internal teams into the public, and it's all fine. -Daniel > > Marek > > > On Tue, Mar 14, 2017 at 7:10 PM, Christian König > wrote: > > Am 14.03.2017 um 18:45 schrieb Harry Wentland: > >> > >> On 2017-03-14 06:04 AM, zhoucm1 wrote: > >>> > >>> > >>> > >>> On 2017年03月14日 17:20, Christian König wrote: > > Am 14.03.2017 um 09:54 schrieb Daniel Vetter: > > > > On Tue, Mar 14, 2017 at 11:30:40AM +0800, zhoucm1 wrote: > >> > >> > >> On 2017年03月14日 10:52, Dave Airlie wrote: > >>> > >>> On 14 March 2017 at 12:00, zhoucm1 wrote: > > Hi Dave, > > Could you tell me why you create your new one patch? I remember I > send out > our the whole implementation, Why not directly review our patches? > >>> > >>> This is patch review, I'm not sure what you are expecting in terms of > >>> direct review. > >>> > >>> The patches you sent out were reviewed by Christian, he stated he > >>> thinks this should > >>> use sync_file, I was interested to see if this was actually possible, > >>> so I just adapted > >>> the patches to check if it was possible to avoid adding a lot of amd > >>> specific code > >>> for something that isn't required to be. Hence why I've sent this as > >>> an rfc, as I want > >>> to see if others think using sync_file is a good or bad idea. We may > >>> end up going > >>> back to the non-sync_file based patches if this proves to be a bad > >>> idea, so far it > >>> doesn't look like one. > >>> > >>> I also reviewed the patches and noted it shouldn't add the > >>> wait/signal > >>> interfaces, > >>> that it should use the chunks on command submission, so while I was > >>> in > >>> there I re > >>> wrote that as well. > >> > >> Yeah, then I'm ok with this, just our internal team has used this > >> implementation, they find some gaps between yours and previous, they > >> could > >> need to change their's again, they are annoyance for this. > > > > This is why you _must_ get anything you're doing discussed in upstream > > first. Your internal teams simply do not have design authority on stuff > > like that. And yes it takes forever to get formerly proprietary > > internal-only teams to understand this, speaking from years of > > experience > > implement a proper upstream-design-first approach to feature > > development > > here at intel. > > > "internal teams simply do not have design authority on stuff like that" > > Can I print that on a t-shirt and start to sell it? > >>> > >>> I guess you cannot dress it to go to office..:) > >>> > >> > >> I'd wear it to the office. > >> > >> https://www.customink.com/lab?cid=hkp0-00ay-6vjg > > > > > > I'm only at an AMD office every few years, so that's probably not worth it. > > > > Anyway it's really something we should keep in mind if we want to upstream > > things. > > > > Christian. > > > > > >> > >> Harry > >> > >>> David Zhou > > > Christian. > > > -Daniel > > > > >>> > >>> ___ > >>> 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/4] sync_file: add replace and export some functionality
On Wed, Mar 15, 2017 at 02:19:16PM +1000, Dave Airlie wrote:
> >
> > uabi semantics question: Should we wake up everyone when the fence gets
> > replaced? What's the khr semaphore expectation here?
>
> There are no real semantics for this case, you either wait the semaphore and
> replace it with NULL, or signal it where you replace the fence with a new
> fence.
>
> Nobody should be using the sync_fence interfaces to poll on these fence fds.
>
> So not crashing for non-vulkan behaviour is what we need.
>
> The spec doesn't know anything other than this is an opaque fd,
> it shouldn't be doing operations on it, execpt importing it.
>
> >> static int sync_file_set_fence(struct sync_file *sync_file,
> >> struct dma_fence **fences, int num_fences)
> >> {
> >> @@ -292,8 +328,10 @@ static void sync_file_free(struct kref *kref)
> >> struct sync_file *sync_file = container_of(kref, struct sync_file,
> >>kref);
> >>
> >> - if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
> >> - dma_fence_remove_callback(sync_file->fence, &sync_file->cb);
> >> + if (sync_file->fence) {
> >> + if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
> >> + dma_fence_remove_callback(sync_file->fence,
> >> &sync_file->cb);
> >> + }
> >> dma_fence_put(sync_file->fence);
> >> kfree(sync_file);
> >> }
> >
> > I think you've missed _poll, won't that oops now?
>
> I don't think it will, all the stuff do inside the poll handler is
> protected by the mutex
> or do you think we should hook the new fence if the old fence has poll
> enabled?
Yeah, or at least wake them up somehow and restart it. Or well at least
think what would happen when that does, and whether we care. If vk says
you get undefined behaviour when you replace the fence of a semaphore when
the old one hasn't signalled yet, then we don't need to do anything.
But if they spec some behaviour poll returning "ready" way after you've
replaced the fence and the new one is definitely not ready is a bit
confusing semantics. Or maybe that's exactly the semantics vulkan once,
but then we need to be careful with restarts and stuff.
wrt the oops I think there's a possibility of a use-after-free: Thus far
the wait inherited the fence reference from the sync_file (since poll
stops before the file ref is gone), but now the fence could disappear
underneath it. add_callback itself doesn't grab a reference on its own.
So either we need synchronous replacement for poll or grab a reference
there. I think at least ... coffee not yet entirely working. In any case,
this kind of nasty corner case is perfect for some vgem testing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/4] amdgpu: use sync file for shared semaphores
On Tue, Mar 14, 2017 at 10:50:54AM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This creates a new interface for amdgpu with ioctls to
> create/destroy/import and export shared semaphores using
> sem object backed by the sync_file code. The semaphores
> are not installed as fd (except for export), but rather
> like other driver internal objects in an idr. The idr
> holds the initial reference on the sync file.
>
> The command submission interface is enhanced with two new
> chunks, one for semaphore waiting, one for semaphore signalling
> and just takes a list of handles for each.
>
> This is based on work originally done by David Zhou at AMD,
> with input from Christian Konig on what things should look like.
>
> NOTE: this interface addition needs a version bump to expose
> it to userspace.
>
> Signed-off-by: Dave Airlie
Another uapi corner case: Since you allow semaphores to be created before
they have a first fence attached, that essentially creates future fences.
I.e. sync_file fd with no fence yet attached. We want that anyway, but
maybe not together with semaphores (since there's some more implications).
I think it'd be good to attach a dummy fence which already starts out as
signalled to sync_file->fence for semaphores. That way userspace can't go
evil, create a semaphore, then pass it to a driver which then promptly
oopses or worse because it assumes then when it has a sync_file, it also
has a fence. And the dummy fence could be globally shared, so not really
overhead.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 70 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 8 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c | 204
>
> include/uapi/drm/amdgpu_drm.h | 28 +
> 6 files changed, 322 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> b/drivers/gpu/drm/amd/amdgpu/Makefile
> index 2814aad..404bcba 100644
> --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> @@ -24,7 +24,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
> amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> - amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
> + amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_sem.o
>
> # add asic specific block
> amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index c1b9135..4ed8811 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -702,6 +702,8 @@ struct amdgpu_fpriv {
> struct mutexbo_list_lock;
> struct idr bo_list_handles;
> struct amdgpu_ctx_mgr ctx_mgr;
> + spinlock_t sem_handles_lock;
> + struct idr sem_handles;
> };
>
> /*
> @@ -1814,5 +1816,15 @@ amdgpu_cs_find_mapping(struct amdgpu_cs_parser *parser,
> uint64_t addr, struct amdgpu_bo **bo);
> int amdgpu_cs_sysvm_access_required(struct amdgpu_cs_parser *parser);
>
> +int amdgpu_sem_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *filp);
> +void amdgpu_sem_destroy(struct amdgpu_fpriv *fpriv, u32 handle);
> +int amdgpu_sem_lookup_and_signal(struct amdgpu_fpriv *fpriv,
> + uint32_t handle,
> + struct dma_fence *fence);
> +int amdgpu_sem_lookup_and_sync(struct amdgpu_device *adev,
> +struct amdgpu_fpriv *fpriv,
> +struct amdgpu_sync *sync,
> +uint32_t handle);
> #include "amdgpu_object.h"
> #endif
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index 4671432..80fc94b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -217,6 +217,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p,
> void *data)
> break;
>
> case AMDGPU_CHUNK_ID_DEPENDENCIES:
> + case AMDGPU_CHUNK_ID_SEM_WAIT:
> + case AMDGPU_CHUNK_ID_SEM_SIGNAL:
> break;
>
> default:
> @@ -1009,6 +1011,28 @@ static int amdgpu_process_fence_dep(struct
> amdgpu_device *adev,
> return 0;
> }
>
> +static int amdgpu_process_sem_wait_dep(struct amdgpu_device *adev,
> +struct amdgpu_cs_parser *p,
> +struct amdgpu_cs_chunk *chunk)
> +{
> + struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
> + unsigne
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Yes, exactly that.
Christian.
Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
Does that means we don't need invisible vram later?
David
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Christian K?nig
Sent: Wednesday, March 15, 2017 3:38 PM
To: Ayyappa Ch
Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
amd-gfx@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
helg...@kernel.org; dri-de...@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Carizzo is an APU and resizing BARs isn't needed nor supported there.
The CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29 +
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct amdgpu_device
*adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc *mc,
u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct
amdgpu_mc *mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64 size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev) {
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well */
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL * 1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL
* 1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base =
((u64)RREG32(mmMC_VM_FB_OFFSET)) << 22; diff --git
a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device *adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper
[PATCH] drm/amd/amdgpu: Fix debugfs reg read/write address width
The MMIO space is wider now so we mask the lower 22 bits
instead of 18.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 47d1dcc85b18..89504a883791 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2944,7 +2944,7 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f,
char __user *buf,
use_bank = 0;
}
- *pos &= 0x3;
+ *pos &= (1UL << 22) - 1;
if (use_bank) {
if ((sh_bank != 0x && sh_bank >=
adev->gfx.config.max_sh_per_se) ||
@@ -3020,7 +3020,7 @@ static ssize_t amdgpu_debugfs_regs_write(struct file *f,
const char __user *buf,
use_bank = 0;
}
- *pos &= 0x3;
+ *pos &= (1UL << 22) - 1;
if (use_bank) {
if ((sh_bank != 0x && sh_bank >=
adev->gfx.config.max_sh_per_se) ||
--
2.12.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores
Am 15.03.2017 um 09:48 schrieb Daniel Vetter: On Wed, Mar 15, 2017 at 01:01:19AM +0100, Marek Olšák wrote: While it's nice that you are all having fun here, I don't think that's the way to communicate this. The truth is, if AMD had an open source driver using the semaphores (e.g. Vulkan) and if the libdrm semaphore code was merged, Dave wouldn't be able to change it, ever. If a dependent open source project relies on some libdrm interface, that interface is set in stone. So AMD wouldn't be able to change it either. Unfortunately, such an open source project doesn't exist, so the community can assume that this libdrm code is still in the "initial design phase". Dave has an upper hand here, because he actually has an open source project that will use this, while AMD doesn't (yet). However, AMD can still negotiate some details here, i.e. do a proper review. Fully agreed, that's why there was this "internal" qualifier. If you do this internally, then it's not final, if you discuss it here on the m-l, it actually matters. So drag your internal teams into the public, and it's all fine. Unfortunately it's not done with that. You also need to raise company wide awareness of changed needs. For example the concept that changes aren't allowed to break older upstream components is completely new to most teams inside AMD. It's a rather painful learning curve when you want to move projects from closed source to open source. Christian. -Daniel Marek On Tue, Mar 14, 2017 at 7:10 PM, Christian König wrote: Am 14.03.2017 um 18:45 schrieb Harry Wentland: On 2017-03-14 06:04 AM, zhoucm1 wrote: On 2017年03月14日 17:20, Christian König wrote: Am 14.03.2017 um 09:54 schrieb Daniel Vetter: On Tue, Mar 14, 2017 at 11:30:40AM +0800, zhoucm1 wrote: On 2017年03月14日 10:52, Dave Airlie wrote: On 14 March 2017 at 12:00, zhoucm1 wrote: Hi Dave, Could you tell me why you create your new one patch? I remember I send out our the whole implementation, Why not directly review our patches? This is patch review, I'm not sure what you are expecting in terms of direct review. The patches you sent out were reviewed by Christian, he stated he thinks this should use sync_file, I was interested to see if this was actually possible, so I just adapted the patches to check if it was possible to avoid adding a lot of amd specific code for something that isn't required to be. Hence why I've sent this as an rfc, as I want to see if others think using sync_file is a good or bad idea. We may end up going back to the non-sync_file based patches if this proves to be a bad idea, so far it doesn't look like one. I also reviewed the patches and noted it shouldn't add the wait/signal interfaces, that it should use the chunks on command submission, so while I was in there I re wrote that as well. Yeah, then I'm ok with this, just our internal team has used this implementation, they find some gaps between yours and previous, they could need to change their's again, they are annoyance for this. This is why you _must_ get anything you're doing discussed in upstream first. Your internal teams simply do not have design authority on stuff like that. And yes it takes forever to get formerly proprietary internal-only teams to understand this, speaking from years of experience implement a proper upstream-design-first approach to feature development here at intel. "internal teams simply do not have design authority on stuff like that" Can I print that on a t-shirt and start to sell it? I guess you cannot dress it to go to office..:) I'd wear it to the office. https://www.customink.com/lab?cid=hkp0-00ay-6vjg I'm only at an AMD office every few years, so that's probably not worth it. Anyway it's really something we should keep in mind if we want to upstream things. Christian. Harry David Zhou Christian. -Daniel ___ 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] drm/amd/amdgpu: Fix debugfs reg read/write address width
Am 15.03.2017 um 10:35 schrieb Tom St Denis:
The MMIO space is wider now so we mask the lower 22 bits
instead of 18.
Signed-off-by: Tom St Denis
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 47d1dcc85b18..89504a883791 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2944,7 +2944,7 @@ static ssize_t amdgpu_debugfs_regs_read(struct file *f,
char __user *buf,
use_bank = 0;
}
- *pos &= 0x3;
+ *pos &= (1UL << 22) - 1;
if (use_bank) {
if ((sh_bank != 0x && sh_bank >=
adev->gfx.config.max_sh_per_se) ||
@@ -3020,7 +3020,7 @@ static ssize_t amdgpu_debugfs_regs_write(struct file *f,
const char __user *buf,
use_bank = 0;
}
- *pos &= 0x3;
+ *pos &= (1UL << 22) - 1;
if (use_bank) {
if ((sh_bank != 0x && sh_bank >=
adev->gfx.config.max_sh_per_se) ||
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/4] amdgpu: use sync file for shared semaphores
Am 15.03.2017 um 10:01 schrieb Daniel Vetter:
On Tue, Mar 14, 2017 at 10:50:54AM +1000, Dave Airlie wrote:
From: Dave Airlie
This creates a new interface for amdgpu with ioctls to
create/destroy/import and export shared semaphores using
sem object backed by the sync_file code. The semaphores
are not installed as fd (except for export), but rather
like other driver internal objects in an idr. The idr
holds the initial reference on the sync file.
The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for semaphore signalling
and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.
NOTE: this interface addition needs a version bump to expose
it to userspace.
Signed-off-by: Dave Airlie
Another uapi corner case: Since you allow semaphores to be created before
they have a first fence attached, that essentially creates future fences.
I.e. sync_file fd with no fence yet attached. We want that anyway, but
maybe not together with semaphores (since there's some more implications).
I think it'd be good to attach a dummy fence which already starts out as
signalled to sync_file->fence for semaphores. That way userspace can't go
evil, create a semaphore, then pass it to a driver which then promptly
oopses or worse because it assumes then when it has a sync_file, it also
has a fence. And the dummy fence could be globally shared, so not really
overhead.
Sounds fishy to me, what happens in case of a race condition and the
receiver sometimes waits on the dummy and sometimes on the real fence?
I would rather teach the users of sync_file to return a proper error
code when you want to wait on a sync_file which doesn't have a fence yet.
Christian.
-Daniel
---
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 70 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 8 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c | 204
include/uapi/drm/amdgpu_drm.h | 28 +
6 files changed, 322 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c
diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
b/drivers/gpu/drm/amd/amdgpu/Makefile
index 2814aad..404bcba 100644
--- a/drivers/gpu/drm/amd/amdgpu/Makefile
+++ b/drivers/gpu/drm/amd/amdgpu/Makefile
@@ -24,7 +24,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
- amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
+ amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_sem.o
# add asic specific block
amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c1b9135..4ed8811 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -702,6 +702,8 @@ struct amdgpu_fpriv {
struct mutexbo_list_lock;
struct idr bo_list_handles;
struct amdgpu_ctx_mgr ctx_mgr;
+ spinlock_t sem_handles_lock;
+ struct idr sem_handles;
};
/*
@@ -1814,5 +1816,15 @@ amdgpu_cs_find_mapping(struct amdgpu_cs_parser *parser,
uint64_t addr, struct amdgpu_bo **bo);
int amdgpu_cs_sysvm_access_required(struct amdgpu_cs_parser *parser);
+int amdgpu_sem_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
+void amdgpu_sem_destroy(struct amdgpu_fpriv *fpriv, u32 handle);
+int amdgpu_sem_lookup_and_signal(struct amdgpu_fpriv *fpriv,
+uint32_t handle,
+struct dma_fence *fence);
+int amdgpu_sem_lookup_and_sync(struct amdgpu_device *adev,
+ struct amdgpu_fpriv *fpriv,
+ struct amdgpu_sync *sync,
+ uint32_t handle);
#include "amdgpu_object.h"
#endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4671432..80fc94b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -217,6 +217,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void
*data)
break;
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+ case AMDGPU_CHUNK_ID_SEM_WAIT:
+ case AMDGPU_CHUNK_ID_SEM_SIGNAL:
break;
default:
@@ -1009,6 +1011,28 @@ static int amdgpu_process_fence_dep(struct amdgpu_device
*adev,
return 0;
}
+static int amdgpu_process_sem_wait_dep(struct amdgpu_device *adev,
+
Re: [PATCH] drm/amdgpu: fix the clearing wb size
Am 15.03.2017 um 08:30 schrieb Huang Rui:
The clearing wb size should be the one that it is assigned.
Signed-off-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b0ac610..b0e0471 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -550,7 +550,7 @@ static int amdgpu_wb_init(struct amdgpu_device *adev)
int r;
if (adev->wb.wb_obj == NULL) {
- r = amdgpu_bo_create_kernel(adev, AMDGPU_MAX_WB * 4,
+ r = amdgpu_bo_create_kernel(adev, AMDGPU_MAX_WB *
sizeof(uint32_t),
PAGE_SIZE, AMDGPU_GEM_DOMAIN_GTT,
&adev->wb.wb_obj,
&adev->wb.gpu_addr,
(void **)&adev->wb.wb);
@@ -564,7 +564,7 @@ static int amdgpu_wb_init(struct amdgpu_device *adev)
memset(&adev->wb.used, 0, sizeof(adev->wb.used));
/* clear wb memory */
- memset((char *)adev->wb.wb, 0, AMDGPU_GPU_PAGE_SIZE);
+ memset((char *)adev->wb.wb, 0, AMDGPU_MAX_WB *
sizeof(uint32_t));
}
return 0;
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/4] amdgpu: use sync file for shared semaphores
On Wed, Mar 15, 2017 at 10:43:01AM +0100, Christian König wrote:
> Am 15.03.2017 um 10:01 schrieb Daniel Vetter:
> > On Tue, Mar 14, 2017 at 10:50:54AM +1000, Dave Airlie wrote:
> > > From: Dave Airlie
> > >
> > > This creates a new interface for amdgpu with ioctls to
> > > create/destroy/import and export shared semaphores using
> > > sem object backed by the sync_file code. The semaphores
> > > are not installed as fd (except for export), but rather
> > > like other driver internal objects in an idr. The idr
> > > holds the initial reference on the sync file.
> > >
> > > The command submission interface is enhanced with two new
> > > chunks, one for semaphore waiting, one for semaphore signalling
> > > and just takes a list of handles for each.
> > >
> > > This is based on work originally done by David Zhou at AMD,
> > > with input from Christian Konig on what things should look like.
> > >
> > > NOTE: this interface addition needs a version bump to expose
> > > it to userspace.
> > >
> > > Signed-off-by: Dave Airlie
> > Another uapi corner case: Since you allow semaphores to be created before
> > they have a first fence attached, that essentially creates future fences.
> > I.e. sync_file fd with no fence yet attached. We want that anyway, but
> > maybe not together with semaphores (since there's some more implications).
> >
> > I think it'd be good to attach a dummy fence which already starts out as
> > signalled to sync_file->fence for semaphores. That way userspace can't go
> > evil, create a semaphore, then pass it to a driver which then promptly
> > oopses or worse because it assumes then when it has a sync_file, it also
> > has a fence. And the dummy fence could be globally shared, so not really
> > overhead.
>
> Sounds fishy to me, what happens in case of a race condition and the
> receiver sometimes waits on the dummy and sometimes on the real fence?
>
> I would rather teach the users of sync_file to return a proper error code
> when you want to wait on a sync_file which doesn't have a fence yet.
Races in userspace are races in userspace :-) And it's only a problem
initially when you use a semaphore for the first time. After that you
still have the same race, but because there's always a fence attached,
your userspace won't ever notice the fail. It will simply complete
immediately (because most likely the old fence has completed already).
And it also doesn't mesh with the rough future fence plan, where the idea
is that sync_file_get_fence blocks until the fence is there, and only
drivers who can handle the risk of a fence loop (through hangcheck and
hang recovery) will use a __get_fence function to peek at the future
fence. I think the assumption that a sync_file always comes with a fence
is a good principle for code robustness in the kernel.
If you really want the userspace debugging, we can make it a module
option, or even better, sprinkle a pile of tracepoints all over fences to
make it easier to watch. But when the tradeoff is between userspace
debugging and kernel robustness, I think we need to go with kernel
robustness, for security reasons and all that.
-Daniel
>
> Christian.
>
> > -Daniel
> >
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 12 ++
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 70 ++-
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 8 ++
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c | 204
> > >
> > > include/uapi/drm/amdgpu_drm.h | 28 +
> > > 6 files changed, 322 insertions(+), 2 deletions(-)
> > > create mode 100644 drivers/gpu/drm/amd/amdgpu/amdgpu_sem.c
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/Makefile
> > > b/drivers/gpu/drm/amd/amdgpu/Makefile
> > > index 2814aad..404bcba 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/Makefile
> > > +++ b/drivers/gpu/drm/amd/amdgpu/Makefile
> > > @@ -24,7 +24,7 @@ amdgpu-y += amdgpu_device.o amdgpu_kms.o \
> > > atombios_encoders.o amdgpu_sa.o atombios_i2c.o \
> > > amdgpu_prime.o amdgpu_vm.o amdgpu_ib.o amdgpu_pll.o \
> > > amdgpu_ucode.o amdgpu_bo_list.o amdgpu_ctx.o amdgpu_sync.o \
> > > - amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o
> > > + amdgpu_gtt_mgr.o amdgpu_vram_mgr.o amdgpu_virt.o amdgpu_sem.o
> > > # add asic specific block
> > > amdgpu-$(CONFIG_DRM_AMDGPU_CIK)+= cik.o cik_ih.o kv_smc.o kv_dpm.o \
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > index c1b9135..4ed8811 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> > > @@ -702,6 +702,8 @@ struct amdgpu_fpriv {
> > > struct mutexbo_list_lock;
> > > struct idr bo_list_handles;
> > > struct amdgpu_ctx_mgr ctx_mgr;
> > > + spinlock_t sem_handles_lock;
> > > + struct idr sem_handl
Re: [PATCH libdrm] libdrm/amdgpu: add interface for kernel semaphores
Hi Dave,
Barring the other discussions, allow me to put a couple of trivial suggestions:
Please re-wrap the long lines to follow existing code style.
On 14 March 2017 at 00:50, Dave Airlie wrote:
> @@ -882,6 +894,12 @@ int amdgpu_cs_submit(amdgpu_context_handle context,
> struct amdgpu_cs_request *ibs_request,
> uint32_t number_of_requests);
>
> +int amdgpu_cs_submit_sem(amdgpu_context_handle context,
> +uint64_t flags,
> +struct amdgpu_cs_request *ibs_request,
> +struct amdgpu_cs_request_sem *ibs_sem,
> +uint32_t number_of_requests);
> +
> /**
> * Query status of Command Buffer Submission
> *
> @@ -1255,4 +1273,14 @@ int
> amdgpu_cs_destroy_semaphore(amdgpu_semaphore_handle sem);
> */
> const char *amdgpu_get_marketing_name(amdgpu_device_handle dev);
>
> +int amdgpu_cs_create_sem(amdgpu_device_handle dev,
> +amdgpu_sem_handle *sem);
> +int amdgpu_cs_export_sem(amdgpu_device_handle dev,
> + amdgpu_sem_handle sem,
> +int *shared_handle);
> +int amdgpu_cs_import_sem(amdgpu_device_handle dev,
> + int shared_handle,
> +amdgpu_sem_handle *sem);
> +int amdgpu_cs_destroy_sem(amdgpu_device_handle dev,
> + amdgpu_sem_handle sem);
The new symbols should be added to the amdgpu-symbol-check test.
If in doubt - run `make -C amdgpu check'
> --- a/include/drm/amdgpu_drm.h
> +++ b/include/drm/amdgpu_drm.h
Please sync this as PATCH 1/2 via "make headers_install" + cp + git
commit -asm "Generated using make headers_install.\nGenerated from
$tree/branch commit $sha."
There's a handful of other changes that are missing/should be merged.
> @@ -50,6 +50,7 @@ extern "C" {
> +struct drm_amdgpu_cs_chunk_sem {
> + uint32_t handle;
> +};
> +
Seems unused in the UAPI header - might what to add a note ?
Also sizeof(struct drm_amdgpu_cs_chunk_sem) is not multiple of 64bit -
worth mentioning that it's safe and/or why ?
Thanks
Emil
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
It also needs any support from VBIOS side ? I mean PCIe large bar support?
Thanks,
Ayyappa.
On Wed, Mar 15, 2017 at 1:07 PM, Christian König
wrote:
> Carizzo is an APU and resizing BARs isn't needed nor supported there. The
> CPU can access the full stolen VRAM directly on that hardware.
>
> As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
> variants.
>
> Christian.
>
>
> Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
>>
>> Is it possible on Carrizo asics? Or only supports on newer asics?
>>
>> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
>> wrote:
>>>
>>> From: Christian König
>>>
>>> Try to resize BAR0 to let CPU access all of VRAM.
>>>
>>> Signed-off-by: Christian König
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
>>> +
>>> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
>>> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
>>> 4 files changed, 40 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> index 3b81ded..905ded9 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
>>> amdgpu_device *adev, struct ttm_tt *ttm,
>>> struct ttm_mem_reg *mem);
>>> void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc, u64 base);
>>> void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
>>> *mc);
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>>> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
>>> size);
>>> int amdgpu_ttm_init(struct amdgpu_device *adev);
>>> void amdgpu_ttm_fini(struct amdgpu_device *adev);
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index 118f4e6..92955fe 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
>>> struct amdgpu_mc *mc)
>>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
>>> }
>>>
>>> +/**
>>> + * amdgpu_resize_bar0 - try to resize BAR0
>>> + *
>>> + * @adev: amdgpu_device pointer
>>> + *
>>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>>> + */
>>> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
>>> +{
>>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
>>> + int r;
>>> +
>>> + r = pci_resize_resource(adev->pdev, 0, size);
>>> +
>>> + if (r == -ENOTSUPP) {
>>> + /* The hardware don't support the extension. */
>>> + return;
>>> +
>>> + } else if (r == -ENOSPC) {
>>> + DRM_INFO("Not enoigh PCI address space for a large
>>> BAR.");
>>> + } else if (r) {
>>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>>> + }
>>> +
>>> + /* Reinit the doorbell mapping, it is most likely moved as well
>>> */
>>> + amdgpu_doorbell_fini(adev);
>>> + BUG_ON(amdgpu_doorbell_init(adev));
>>> +}
>>> +
>>> /*
>>>* GPU helpers function.
>>>*/
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> index dc9b6d6..36a7aa5 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
>>> *adev)
>>> break;
>>> }
>>> adev->mc.vram_width = numchan * chansize;
>>> - /* Could aper size report 0 ? */
>>> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>>> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>>> /* size in MB on si */
>>> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
>>> 1024ULL;
>>> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
>>> 1024ULL;
>>>
>>> + if (!(adev->flags & AMD_IS_APU))
>>> + amdgpu_resize_bar0(adev);
>>> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
>>> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
>>> +
>>> #ifdef CONFIG_X86_64
>>> if (adev->flags & AMD_IS_APU) {
>>> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) <<
>>> 22;
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> index c087b00..7761ad3 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
>>> @@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device
>>> *adev)
>>> break;
>>> }
>>> adev->mc.vram_width = numchan * chansize;
>>> - /* Could aper size report 0 ? */
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
No, we resize the BAR on the fly during driver load without help from
the BIOS or VBIOS.
Christian.
Am 15.03.2017 um 11:42 schrieb Ayyappa Ch:
It also needs any support from VBIOS side ? I mean PCIe large bar support?
Thanks,
Ayyappa.
On Wed, Mar 15, 2017 at 1:07 PM, Christian König
wrote:
Carizzo is an APU and resizing BARs isn't needed nor supported there. The
CPU can access the full stolen VRAM directly on that hardware.
As far as I know ASICs with support for this are Tonga, Fiji and all Polaris
variants.
Christian.
Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
Is it possible on Carrizo asics? Or only supports on newer asics?
On Mon, Mar 13, 2017 at 6:11 PM, Christian König
wrote:
From: Christian König
Try to resize BAR0 to let CPU access all of VRAM.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
+
drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
4 files changed, 40 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 3b81ded..905ded9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
amdgpu_device *adev, struct ttm_tt *ttm,
struct ttm_mem_reg *mem);
void amdgpu_vram_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc, u64 base);
void amdgpu_gtt_location(struct amdgpu_device *adev, struct amdgpu_mc
*mc);
+void amdgpu_resize_bar0(struct amdgpu_device *adev);
void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev, u64
size);
int amdgpu_ttm_init(struct amdgpu_device *adev);
void amdgpu_ttm_fini(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 118f4e6..92955fe 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device *adev,
struct amdgpu_mc *mc)
mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
}
+/**
+ * amdgpu_resize_bar0 - try to resize BAR0
+ *
+ * @adev: amdgpu_device pointer
+ *
+ * Try to resize BAR0 to make all VRAM CPU accessible.
+ */
+void amdgpu_resize_bar0(struct amdgpu_device *adev)
+{
+ u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
+ int r;
+
+ r = pci_resize_resource(adev->pdev, 0, size);
+
+ if (r == -ENOTSUPP) {
+ /* The hardware don't support the extension. */
+ return;
+
+ } else if (r == -ENOSPC) {
+ DRM_INFO("Not enoigh PCI address space for a large
BAR.");
+ } else if (r) {
+ DRM_ERROR("Problem resizing BAR0 (%d).", r);
+ }
+
+ /* Reinit the doorbell mapping, it is most likely moved as well
*/
+ amdgpu_doorbell_fini(adev);
+ BUG_ON(amdgpu_doorbell_init(adev));
+}
+
/*
* GPU helpers function.
*/
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
index dc9b6d6..36a7aa5 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
@@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
*adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
1024ULL;
+ if (!(adev->flags & AMD_IS_APU))
+ amdgpu_resize_bar0(adev);
+ adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
+ adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
+
#ifdef CONFIG_X86_64
if (adev->flags & AMD_IS_APU) {
adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET)) <<
22;
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
index c087b00..7761ad3 100644
--- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
@@ -459,13 +459,15 @@ static int gmc_v8_0_mc_init(struct amdgpu_device
*adev)
break;
}
adev->mc.vram_width = numchan * chansize;
- /* Could aper size report 0 ? */
- adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
- adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
/* size in MB on si */
adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) * 1024ULL *
1024ULL;
adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) *
[PATCH 1/2] drm/radeon/si: add dpm quirk for Oland
OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems
with higher sclks.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/si_dpm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index d12b897..72e1588 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2984,6 +2984,12 @@ static void si_apply_state_adjust_rules(struct
radeon_device *rdev,
(rdev->pdev->device == 0x6667)) {
max_sclk = 75000;
}
+ } else if (rdev->family == CHIP_OLAND) {
+ if ((rdev->pdev->device == 0x6604) &&
+ (rdev->pdev->subsystem_vendor == 0x1028) &&
+ (rdev->pdev->subsystem_device == 0x066F)) {
+ max_sclk = 75000;
+ }
}
if (rps->vce_active) {
--
2.5.5
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amdgpu/si: add dpm quirk for Oland
OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems
with higher sclks.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 42e95ee..74dedf7 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3464,6 +3464,12 @@ static void si_apply_state_adjust_rules(struct
amdgpu_device *adev,
(adev->pdev->device == 0x6667)) {
max_sclk = 75000;
}
+ } else if (adev->asic_type == CHIP_OLAND) {
+ if ((adev->pdev->device == 0x6604) &&
+ (adev->pdev->subsystem_vendor == 0x1028) &&
+ (adev->pdev->subsystem_device == 0x066F)) {
+ max_sclk = 75000;
+ }
}
if (rps->vce_active) {
--
2.5.5
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/radeon/si: add dpm quirk for Oland
Am 15.03.2017 um 14:01 schrieb Alex Deucher:
OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems
with higher sclks.
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
Acked-by: Christian König for both patches.
---
drivers/gpu/drm/radeon/si_dpm.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index d12b897..72e1588 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2984,6 +2984,12 @@ static void si_apply_state_adjust_rules(struct
radeon_device *rdev,
(rdev->pdev->device == 0x6667)) {
max_sclk = 75000;
}
+ } else if (rdev->family == CHIP_OLAND) {
+ if ((rdev->pdev->device == 0x6604) &&
+ (rdev->pdev->subsystem_vendor == 0x1028) &&
+ (rdev->pdev->subsystem_device == 0x066F)) {
+ max_sclk = 75000;
+ }
}
if (rps->vce_active) {
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH umr] Add ability to write registers by address
Signed-off-by: Tom St Denis
---
src/app/main.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/app/main.c b/src/app/main.c
index 88b4feaf0058..72c29d6a26d4 100644
--- a/src/app/main.c
+++ b/src/app/main.c
@@ -216,9 +216,14 @@ int main(int argc, char **argv)
}
} else if (!strcmp(argv[i], "--write") || !strcmp(argv[i],
"-w")) {
if (i + 2 < argc) {
+ uint32_t reg, val;
+
if (!asic)
asic = get_asic();
- umr_set_register(asic, argv[i+1], argv[i+2]);
+ if (sscanf(argv[i+1], "%"SCNx32, ®) == 1 &&
sscanf(argv[i+2], "%"SCNx32, &val) == 1)
+ umr_write_reg(asic, reg * 4, val);
+ else
+ umr_set_register(asic, argv[i+1],
argv[i+2]);
i += 2;
options.need_scan = 0;
} else {
--
2.12.0
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/2] drm/amdgpu/gfx6: drop gds unrefs
Leftover from gfx7 code. gfx6 never sets up the gds buffers in the first place. Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 7259ded..4c4874f 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -3308,10 +3308,6 @@ static int gfx_v6_0_sw_fini(void *handle) int i; struct amdgpu_device *adev = (struct amdgpu_device *)handle; - amdgpu_bo_unref(&adev->gds.oa_gfx_bo); - amdgpu_bo_unref(&adev->gds.gws_gfx_bo); - amdgpu_bo_unref(&adev->gds.gds_gfx_bo); - for (i = 0; i < adev->gfx.num_gfx_rings; i++) amdgpu_ring_fini(&adev->gfx.gfx_ring[i]); for (i = 0; i < adev->gfx.num_compute_rings; i++) -- 2.5.5 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amdgpu: don't init GDS pool if GDS size is 0
SI cards don't expose GDS as a separate pool. The CP manages
GDS and the UMDs use special CP packets to allocate GDS memory.
bug: https://bugzilla.kernel.org/show_bug.cgi?id=194867
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 47 -
1 file changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 987f8f0..c20174d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1148,6 +1148,7 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
DRM_INFO("amdgpu: %uM of GTT memory ready.\n",
(unsigned)(adev->mc.gtt_size / (1024 * 1024)));
+
adev->gds.mem.total_size = adev->gds.mem.total_size << AMDGPU_GDS_SHIFT;
adev->gds.mem.gfx_partition_size = adev->gds.mem.gfx_partition_size <<
AMDGPU_GDS_SHIFT;
adev->gds.mem.cs_partition_size = adev->gds.mem.cs_partition_size <<
AMDGPU_GDS_SHIFT;
@@ -1157,28 +1158,35 @@ int amdgpu_ttm_init(struct amdgpu_device *adev)
adev->gds.oa.total_size = adev->gds.oa.total_size << AMDGPU_OA_SHIFT;
adev->gds.oa.gfx_partition_size = adev->gds.oa.gfx_partition_size <<
AMDGPU_OA_SHIFT;
adev->gds.oa.cs_partition_size = adev->gds.oa.cs_partition_size <<
AMDGPU_OA_SHIFT;
+
/* GDS Memory */
- r = ttm_bo_init_mm(&adev->mman.bdev, AMDGPU_PL_GDS,
- adev->gds.mem.total_size >> PAGE_SHIFT);
- if (r) {
- DRM_ERROR("Failed initializing GDS heap.\n");
- return r;
+ if (adev->gds.mem.total_size) {
+ r = ttm_bo_init_mm(&adev->mman.bdev, AMDGPU_PL_GDS,
+ adev->gds.mem.total_size >> PAGE_SHIFT);
+ if (r) {
+ DRM_ERROR("Failed initializing GDS heap.\n");
+ return r;
+ }
}
/* GWS */
- r = ttm_bo_init_mm(&adev->mman.bdev, AMDGPU_PL_GWS,
- adev->gds.gws.total_size >> PAGE_SHIFT);
- if (r) {
- DRM_ERROR("Failed initializing gws heap.\n");
- return r;
+ if (adev->gds.gws.total_size) {
+ r = ttm_bo_init_mm(&adev->mman.bdev, AMDGPU_PL_GWS,
+ adev->gds.gws.total_size >> PAGE_SHIFT);
+ if (r) {
+ DRM_ERROR("Failed initializing gws heap.\n");
+ return r;
+ }
}
/* OA */
- r = ttm_bo_init_mm(&adev->mman.bdev, AMDGPU_PL_OA,
- adev->gds.oa.total_size >> PAGE_SHIFT);
- if (r) {
- DRM_ERROR("Failed initializing oa heap.\n");
- return r;
+ if (adev->gds.oa.total_size) {
+ r = ttm_bo_init_mm(&adev->mman.bdev, AMDGPU_PL_OA,
+ adev->gds.oa.total_size >> PAGE_SHIFT);
+ if (r) {
+ DRM_ERROR("Failed initializing oa heap.\n");
+ return r;
+ }
}
r = amdgpu_ttm_debugfs_init(adev);
@@ -1206,9 +1214,12 @@ void amdgpu_ttm_fini(struct amdgpu_device *adev)
}
ttm_bo_clean_mm(&adev->mman.bdev, TTM_PL_VRAM);
ttm_bo_clean_mm(&adev->mman.bdev, TTM_PL_TT);
- ttm_bo_clean_mm(&adev->mman.bdev, AMDGPU_PL_GDS);
- ttm_bo_clean_mm(&adev->mman.bdev, AMDGPU_PL_GWS);
- ttm_bo_clean_mm(&adev->mman.bdev, AMDGPU_PL_OA);
+ if (adev->gds.mem.total_size)
+ ttm_bo_clean_mm(&adev->mman.bdev, AMDGPU_PL_GDS);
+ if (adev->gds.gws.total_size)
+ ttm_bo_clean_mm(&adev->mman.bdev, AMDGPU_PL_GWS);
+ if (adev->gds.oa.total_size)
+ ttm_bo_clean_mm(&adev->mman.bdev, AMDGPU_PL_OA);
ttm_bo_device_release(&adev->mman.bdev);
amdgpu_gart_fini(adev);
amdgpu_ttm_global_fini(adev);
--
2.5.5
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [RESEND PATCH] drm: amd: remove broken include path
On Tue, Mar 14, 2017 at 5:27 PM, Arnd Bergmann wrote: > The AMD ACP driver adds "-I../acp -I../acp/include" to the gcc command > line, which makes no sense, since these are evaluated relative to the > build directory. When we build with "make W=1", they instead cause > a warning: > > cc1: error: ../acp/: No such file or directory [-Werror=missing-include-dirs] > cc1: error: ../acp/include: No such file or directory > [-Werror=missing-include-dirs] > cc1: all warnings being treated as errors > ../scripts/Makefile.build:289: recipe for target > 'drivers/gpu/drm/amd/amdgpu/amdgpu_drv.o' failed > ../scripts/Makefile.build:289: recipe for target > 'drivers/gpu/drm/amd/amdgpu/amdgpu_device.o' failed > ../scripts/Makefile.build:289: recipe for target > 'drivers/gpu/drm/amd/amdgpu/amdgpu_kms.o' failed > > This removes the subdir-ccflags variable that evidently did not > serve any purpose here. > > Signed-off-by: Arnd Bergmann Applied. thanks! Alex > --- > Originally submitted in June 2016. All other patches for this warning got > merged, once this gets in we can turn on the warning flag for everyone. > --- > drivers/gpu/drm/amd/acp/Makefile | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/amd/acp/Makefile > b/drivers/gpu/drm/amd/acp/Makefile > index 8363cb57915b..8a08e81ee90d 100644 > --- a/drivers/gpu/drm/amd/acp/Makefile > +++ b/drivers/gpu/drm/amd/acp/Makefile > @@ -3,6 +3,4 @@ > # of AMDSOC/AMDGPU drm driver. > # It provides the HW control for ACP related functionalities. > > -subdir-ccflags-y += -I$(AMDACPPATH)/ -I$(AMDACPPATH)/include > - > AMD_ACP_FILES := $(AMDACPPATH)/acp_hw.o > -- > 2.9.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 1/2] drm/amdgpu/gfx6: drop gds unrefs
Am 15.03.2017 um 14:56 schrieb Alex Deucher: Leftover from gfx7 code. gfx6 never sets up the gds buffers in the first place. Signed-off-by: Alex Deucher Reviewed-by: Christian König for the series. --- drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c index 7259ded..4c4874f 100644 --- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c @@ -3308,10 +3308,6 @@ static int gfx_v6_0_sw_fini(void *handle) int i; struct amdgpu_device *adev = (struct amdgpu_device *)handle; - amdgpu_bo_unref(&adev->gds.oa_gfx_bo); - amdgpu_bo_unref(&adev->gds.gws_gfx_bo); - amdgpu_bo_unref(&adev->gds.gds_gfx_bo); - for (i = 0; i < adev->gfx.num_gfx_rings; i++) amdgpu_ring_fini(&adev->gfx.gfx_ring[i]); for (i = 0; i < adev->gfx.num_compute_rings; i++) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Wednesday, March 15, 2017 3:38 AM
> To: Ayyappa Ch
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> helg...@kernel.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
>
> Carizzo is an APU and resizing BARs isn't needed nor supported there.
> The CPU can access the full stolen VRAM directly on that hardware.
>
> As far as I know ASICs with support for this are Tonga, Fiji and all
> Polaris variants.
I think resizable BARs are supported as far back as evergreen or NI.
Alex
>
> Christian.
>
> Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> > Is it possible on Carrizo asics? Or only supports on newer asics?
> >
> > On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> > wrote:
> >> From: Christian König
> >>
> >> Try to resize BAR0 to let CPU access all of VRAM.
> >>
> >> Signed-off-by: Christian König
> >> ---
> >> drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> >> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
> +
> >> drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
> >> drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
> >> 4 files changed, 40 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> index 3b81ded..905ded9 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> amdgpu_device *adev, struct ttm_tt *ttm,
> >> struct ttm_mem_reg *mem);
> >> void amdgpu_vram_location(struct amdgpu_device *adev, struct
> amdgpu_mc *mc, u64 base);
> >> void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> amdgpu_mc *mc);
> >> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> >> void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev,
> u64 size);
> >> int amdgpu_ttm_init(struct amdgpu_device *adev);
> >> void amdgpu_ttm_fini(struct amdgpu_device *adev);
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> index 118f4e6..92955fe 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device
> *adev, struct amdgpu_mc *mc)
> >> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
> >> }
> >>
> >> +/**
> >> + * amdgpu_resize_bar0 - try to resize BAR0
> >> + *
> >> + * @adev: amdgpu_device pointer
> >> + *
> >> + * Try to resize BAR0 to make all VRAM CPU accessible.
> >> + */
> >> +void amdgpu_resize_bar0(struct amdgpu_device *adev)
> >> +{
> >> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> >> + int r;
> >> +
> >> + r = pci_resize_resource(adev->pdev, 0, size);
> >> +
> >> + if (r == -ENOTSUPP) {
> >> + /* The hardware don't support the extension. */
> >> + return;
> >> +
> >> + } else if (r == -ENOSPC) {
> >> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
> >> + } else if (r) {
> >> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> >> + }
> >> +
> >> + /* Reinit the doorbell mapping, it is most likely moved as well */
> >> + amdgpu_doorbell_fini(adev);
> >> + BUG_ON(amdgpu_doorbell_init(adev));
> >> +}
> >> +
> >> /*
> >>* GPU helpers function.
> >>*/
> >> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >> index dc9b6d6..36a7aa5 100644
> >> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct
> amdgpu_device *adev)
> >> break;
> >> }
> >> adev->mc.vram_width = numchan * chansize;
> >> - /* Could aper size report 0 ? */
> >> - adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> >> - adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> >> /* size in MB on si */
> >> adev->mc.mc_vram_size = RREG32(mmCONFIG_MEMSIZE) *
> 1024ULL * 1024ULL;
> >> adev->mc.real_vram_size = RREG32(mmCONFIG_MEMSIZE) *
> 1024ULL * 1024ULL;
> >>
> >> + if (!(adev->flags & AMD_IS_APU))
> >> + amdgpu_resize_bar0(adev);
> >> + adev->mc.aper_base = pci_resource_start(adev->pdev, 0);
> >> + adev->mc.aper_size = pci_resource_len(adev->pdev, 0);
> >> +
> >> #ifdef CONFIG_X86_64
> >> if (adev->flags & AMD_IS_APU) {
> >> adev->mc.aper_base = ((u64)RREG32(mmMC_VM_FB_OFFSET))
> << 22;
> >> diff --git a/drivers/gpu/drm/am
[PATCH] drm/amdgpu: increase IH ring buffer size to avoid overflow
From: "Roger.He" We originally limited the IH to 4k on tonga since it uses bus addresses directly rather than GPU MC addresses, so it needs contigous physical memory. This brings it inline with other asics. Signed-off-by: Roger.He Acked-by: Alex Deucher Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c index 2053220..3a5097a 100644 --- a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c +++ b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c @@ -289,7 +289,7 @@ static int tonga_ih_sw_init(void *handle) int r; struct amdgpu_device *adev = (struct amdgpu_device *)handle; - r = amdgpu_ih_ring_init(adev, 4 * 1024, true); + r = amdgpu_ih_ring_init(adev, 64 * 1024, true); if (r) return r; -- 2.5.5 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: increase IH ring buffer size to avoid overflow
Hey Alex, Christian, On a slightly unrelated note. Have you also considered using system_highpri_wq instead of system_wq for the delayed interrupt work? There is a potential for multi-ms latency for systems under high CPU load. And that is usually the case when users are running games. Regards, Andres On Wed, Mar 15, 2017 at 4:18 PM, Alex Deucher wrote: > From: "Roger.He" > > We originally limited the IH to 4k on tonga since it > uses bus addresses directly rather than GPU MC addresses, > so it needs contigous physical memory. This brings it > inline with other asics. > > Signed-off-by: Roger.He > Acked-by: Alex Deucher > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c > b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c > index 2053220..3a5097a 100644 > --- a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c > +++ b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c > @@ -289,7 +289,7 @@ static int tonga_ih_sw_init(void *handle) > int r; > struct amdgpu_device *adev = (struct amdgpu_device *)handle; > > - r = amdgpu_ih_ring_init(adev, 4 * 1024, true); > + r = amdgpu_ih_ring_init(adev, 64 * 1024, true); > if (r) > return r; > > -- > 2.5.5 > > ___ > 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] radeon and amdgpu drm-fixes-4.11
Hi Dave, A few fixes for 4.11. The following changes since commit 3f81e1340706e9a7f854808e2f580c3106805d0c: drm: mxsfb: Implement drm_panel handling (2017-03-10 11:11:14 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.11 for you to fetch changes up to 801a6aa9a63c90724e8899982ad8c7f16be1e2cd: drm/amd/amdgpu: Fix debugfs reg read/write address width (2017-03-15 16:21:34 -0400) Alex Deucher (2): drm/radeon/si: add dpm quirk for Oland drm/amdgpu/si: add dpm quirk for Oland Arnd Bergmann (1): drm: amd: remove broken include path Dave Airlie (1): drm/amdgpu: fix parser init error path to avoid crash in parser fini Rex Zhu (1): drm/amd/powerplay: fix copy error in smu7_clockpoweragting.c Tom St Denis (2): drm/amd/amdgpu: Disable GFX_PG on Carrizo until compute issues solved drm/amd/amdgpu: Fix debugfs reg read/write address width drivers/gpu/drm/amd/acp/Makefile| 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 ++-- drivers/gpu/drm/amd/amdgpu/si_dpm.c | 6 ++ drivers/gpu/drm/amd/amdgpu/vi.c | 2 +- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_clockpowergating.c | 2 +- drivers/gpu/drm/radeon/si_dpm.c | 6 ++ 7 files changed, 18 insertions(+), 6 deletions(-) ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: add macro to retrieve timeline name v2
On Sat, Mar 11, 2017 at 11:18 AM, Christian König wrote: > Am 11.03.2017 um 16:50 schrieb Andres Rodriguez: >> >> This helps de-duplicate a long expression and removes overly long lines. >> >> v2: Rename macro and undef it >> >> Signed-off-by: Andres Rodriguez > > > Reviewed-by: Christian König Applied along with the previous trace series. Thanks! Alex > > >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 12 >> 1 file changed, 8 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h >> b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h >> index 88e1704..08ccb3d 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h >> @@ -11,6 +11,9 @@ >> #define TRACE_SYSTEM amdgpu >> #define TRACE_INCLUDE_FILE amdgpu_trace >> +#define AMDGPU_JOB_GET_TIMELINE_NAME(job) \ >> + >> job->base.s_fence->finished.ops->get_timeline_name(&job->base.s_fence->finished) >> + >> TRACE_EVENT(amdgpu_mm_rreg, >> TP_PROTO(unsigned did, uint32_t reg, uint32_t value), >> TP_ARGS(did, reg, value), >> @@ -102,7 +105,7 @@ TRACE_EVENT(amdgpu_cs_ioctl, >> TP_ARGS(job), >> TP_STRUCT__entry( >> __field(uint64_t, sched_job_id) >> -__string(timeline, >> job->base.s_fence->finished.ops->get_timeline_name(&job->base.s_fence->finished)) >> +__string(timeline, >> AMDGPU_JOB_GET_TIMELINE_NAME(job)) >> __field(unsigned int, context) >> __field(unsigned int, seqno) >> __field(struct dma_fence *, fence) >> @@ -112,7 +115,7 @@ TRACE_EVENT(amdgpu_cs_ioctl, >> TP_fast_assign( >>__entry->sched_job_id = job->base.id; >> - __assign_str(timeline, >> job->base.s_fence->finished.ops->get_timeline_name(&job->base.s_fence->finished)) >> + __assign_str(timeline, >> AMDGPU_JOB_GET_TIMELINE_NAME(job)) >>__entry->context = >> job->base.s_fence->finished.context; >>__entry->seqno = >> job->base.s_fence->finished.seqno; >>__entry->ring_name = job->ring->name; >> @@ -128,7 +131,7 @@ TRACE_EVENT(amdgpu_sched_run_job, >> TP_ARGS(job), >> TP_STRUCT__entry( >> __field(uint64_t, sched_job_id) >> -__string(timeline, >> job->base.s_fence->finished.ops->get_timeline_name(&job->base.s_fence->finished)) >> +__string(timeline, >> AMDGPU_JOB_GET_TIMELINE_NAME(job)) >> __field(unsigned int, context) >> __field(unsigned int, seqno) >> __field(char *, ring_name) >> @@ -137,7 +140,7 @@ TRACE_EVENT(amdgpu_sched_run_job, >> TP_fast_assign( >>__entry->sched_job_id = job->base.id; >> - __assign_str(timeline, >> job->base.s_fence->finished.ops->get_timeline_name(&job->base.s_fence->finished)) >> + __assign_str(timeline, >> AMDGPU_JOB_GET_TIMELINE_NAME(job)) >>__entry->context = >> job->base.s_fence->finished.context; >>__entry->seqno = >> job->base.s_fence->finished.seqno; >>__entry->ring_name = job->ring->name; >> @@ -365,6 +368,7 @@ TRACE_EVENT(amdgpu_ttm_bo_move, >> __entry->new_placement, __entry->bo_size) >> ); >> +#undef AMDGPU_JOB_GET_TIMELINE_NAME >> #endif >> /* This part must be outside protection */ > > > > ___ > 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 1/2] drm/radeon: reinstate oland workaround for sclk
Higher sclks seem to be unstable on some boards.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/si_dpm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 72e1588..c7af9fd 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -2985,9 +2985,13 @@ static void si_apply_state_adjust_rules(struct
radeon_device *rdev,
max_sclk = 75000;
}
} else if (rdev->family == CHIP_OLAND) {
- if ((rdev->pdev->device == 0x6604) &&
- (rdev->pdev->subsystem_vendor == 0x1028) &&
- (rdev->pdev->subsystem_device == 0x066F)) {
+ if ((rdev->pdev->revision == 0xC7) ||
+ (rdev->pdev->revision == 0x80) ||
+ (rdev->pdev->revision == 0x81) ||
+ (rdev->pdev->revision == 0x83) ||
+ (rdev->pdev->revision == 0x87) ||
+ (rdev->pdev->device == 0x6604) ||
+ (rdev->pdev->device == 0x6605)) {
max_sclk = 75000;
}
}
--
2.5.5
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amdgpu: reinstate oland workaround for sclk
Higher sclks seem to be unstable on some boards.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/amd/amdgpu/si_dpm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
index 33b504b..c5dec21 100644
--- a/drivers/gpu/drm/amd/amdgpu/si_dpm.c
+++ b/drivers/gpu/drm/amd/amdgpu/si_dpm.c
@@ -3465,9 +3465,13 @@ static void si_apply_state_adjust_rules(struct
amdgpu_device *adev,
max_sclk = 75000;
}
} else if (adev->asic_type == CHIP_OLAND) {
- if ((adev->pdev->device == 0x6604) &&
- (adev->pdev->subsystem_vendor == 0x1028) &&
- (adev->pdev->subsystem_device == 0x066F)) {
+ if ((adev->pdev->revision == 0xC7) ||
+ (adev->pdev->revision == 0x80) ||
+ (adev->pdev->revision == 0x81) ||
+ (adev->pdev->revision == 0x83) ||
+ (adev->pdev->revision == 0x87) ||
+ (adev->pdev->device == 0x6604) ||
+ (adev->pdev->device == 0x6605)) {
max_sclk = 75000;
}
}
--
2.5.5
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH] drm/amdgpu: increase IH ring buffer size to avoid overflow
On Wed, Mar 15, 2017 at 5:05 PM, Andres Rodriguez wrote: > Hey Alex, Christian, > > On a slightly unrelated note. > > Have you also considered using system_highpri_wq instead of system_wq > for the delayed interrupt work? > > There is a potential for multi-ms latency for systems under high CPU > load. And that is usually the case when users are running games. I vaguely recall some discussion about this last year on the amd-gfx or dri-devel list, but beyond that, not that I know of. Alex > > Regards, > Andres > > > On Wed, Mar 15, 2017 at 4:18 PM, Alex Deucher wrote: >> From: "Roger.He" >> >> We originally limited the IH to 4k on tonga since it >> uses bus addresses directly rather than GPU MC addresses, >> so it needs contigous physical memory. This brings it >> inline with other asics. >> >> Signed-off-by: Roger.He >> Acked-by: Alex Deucher >> Signed-off-by: Alex Deucher >> --- >> drivers/gpu/drm/amd/amdgpu/tonga_ih.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c >> b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c >> index 2053220..3a5097a 100644 >> --- a/drivers/gpu/drm/amd/amdgpu/tonga_ih.c >> +++ b/drivers/gpu/drm/amd/amdgpu/tonga_ih.c >> @@ -289,7 +289,7 @@ static int tonga_ih_sw_init(void *handle) >> int r; >> struct amdgpu_device *adev = (struct amdgpu_device *)handle; >> >> - r = amdgpu_ih_ring_init(adev, 4 * 1024, true); >> + r = amdgpu_ih_ring_init(adev, 64 * 1024, true); >> if (r) >> return r; >> >> -- >> 2.5.5 >> >> ___ >> 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 1/2] drm/amdgpu/vi: remove duplicate CG flags
GFX_MGLS was added twice. Noticed-by: David Binderman Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/vi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c index fca85f8..28385b8 100644 --- a/drivers/gpu/drm/amd/amdgpu/vi.c +++ b/drivers/gpu/drm/amd/amdgpu/vi.c @@ -1044,7 +1044,6 @@ static int vi_common_early_init(void *handle) AMD_CG_SUPPORT_GFX_RLC_LS | AMD_CG_SUPPORT_GFX_CP_LS | AMD_CG_SUPPORT_GFX_CGTS | - AMD_CG_SUPPORT_GFX_MGLS | AMD_CG_SUPPORT_GFX_CGTS_LS | AMD_CG_SUPPORT_GFX_CGCG | AMD_CG_SUPPORT_GFX_CGLS | @@ -1073,7 +1072,6 @@ static int vi_common_early_init(void *handle) AMD_CG_SUPPORT_GFX_RLC_LS | AMD_CG_SUPPORT_GFX_CP_LS | AMD_CG_SUPPORT_GFX_CGTS | - AMD_CG_SUPPORT_GFX_MGLS | AMD_CG_SUPPORT_GFX_CGTS_LS | AMD_CG_SUPPORT_GFX_CGCG | AMD_CG_SUPPORT_GFX_CGLS | -- 2.5.5 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amdgpu/vi: add missing error handling when setting uvd dclk
Noticed-by: David Binderman Signed-off-by: Alex Deucher --- drivers/gpu/drm/amd/amdgpu/vi.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c index 28385b8..eff123b 100644 --- a/drivers/gpu/drm/amd/amdgpu/vi.c +++ b/drivers/gpu/drm/amd/amdgpu/vi.c @@ -795,6 +795,8 @@ static int vi_set_uvd_clocks(struct amdgpu_device *adev, u32 vclk, u32 dclk) return r; r = vi_set_uvd_clock(adev, dclk, ixCG_DCLK_CNTL, ixCG_DCLK_STATUS); + if (r) + return r; return 0; } -- 2.5.5 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: linux-4.11-rc1/drivers/gpu/drm/amd/amdgpu/vi.c: 3 bugs
On Mon, Mar 6, 2017 at 4:40 AM, David Binderman wrote: > > Hello there, > 1 > > [linux-4.11-rc1/drivers/gpu/drm/amd/amdgpu/vi.c:1041] -> > [linux-4.11-rc1/drivers/gpu/drm/amd/amdgpu/vi.c:1037]: (style) Same > expression on both sides of '|'. > > Maybe the macro AMD_CG_SUPPORT_GFX_MGLS is used twice ? > > 2. > > [linux-4.11-rc1/drivers/gpu/drm/amd/amdgpu/vi.c:1070] -> > [linux-4.11-rc1/drivers/gpu/drm/amd/amdgpu/vi.c:1066]: (style) Same > expression on both sides of '|'. > > Duplicate. > > In the same file: > > linux-4.11-rc1/drivers/gpu/drm/amd/amdgpu/vi.c:792]: (style) Variable 'r' is > assigned a value that is never used. > > Source code is > > r = vi_set_uvd_clock(adev, dclk, ixCG_DCLK_CNTL, ixCG_DCLK_STATUS); > > return 0; Thanks, patches sent. Alex > > Regards > > David Binderman > ___ > 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 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> Christian K?nig
> Sent: Wednesday, March 15, 2017 17:29
> To: Zhou, David(ChunMing); Ayyappa Ch
> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> helg...@kernel.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
>
> Yes, exactly that.
(I'm not familiar with PCI too much.)
Is there any restrict for PCI device?
I'm concerning if any PCI couldn't support it on some motherboard.
>
> Christian.
>
> Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
> > Does that means we don't need invisible vram later?
> >
> > David
> >
> > -Original Message-
> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> > Behalf Of Christian K?nig
> > Sent: Wednesday, March 15, 2017 3:38 PM
> > To: Ayyappa Ch
> > Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > amd-gfx@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> > helg...@kernel.org; dri-de...@lists.freedesktop.org
> > Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >
> > Carizzo is an APU and resizing BARs isn't needed nor supported there.
> > The CPU can access the full stolen VRAM directly on that hardware.
> >
> > As far as I know ASICs with support for this are Tonga, Fiji and all
> > Polaris variants.
> >
> > Christian.
> >
> > Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> >> Is it possible on Carrizo asics? Or only supports on newer asics?
> >>
> >> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> >> wrote:
> >>> From: Christian König
> >>>
> >>> Try to resize BAR0 to let CPU access all of VRAM.
> >>>
> >>> Signed-off-by: Christian König
> >>> ---
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
> +
> >>>drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
> >>>drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
> >>>4 files changed, 40 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> index 3b81ded..905ded9 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> amdgpu_device *adev, struct ttm_tt *ttm,
> >>>struct ttm_mem_reg *mem);
> >>>void amdgpu_vram_location(struct amdgpu_device *adev, struct
> amdgpu_mc *mc, u64 base);
> >>>void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> >>> amdgpu_mc *mc);
> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> >>>void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev,
> u64 size);
> >>>int amdgpu_ttm_init(struct amdgpu_device *adev);
> >>>void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
> >>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> index 118f4e6..92955fe 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device
> *adev, struct amdgpu_mc *mc)
> >>> mc->gtt_size >> 20, mc->gtt_start, mc->gtt_end);
> >>>}
> >>>
> >>> +/**
> >>> + * amdgpu_resize_bar0 - try to resize BAR0
> >>> + *
> >>> + * @adev: amdgpu_device pointer
> >>> + *
> >>> + * Try to resize BAR0 to make all VRAM CPU accessible.
> >>> + */
> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev) {
> >>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
> >>> + int r;
> >>> +
> >>> + r = pci_resize_resource(adev->pdev, 0, size);
> >>> +
> >>> + if (r == -ENOTSUPP) {
> >>> + /* The hardware don't support the extension. */
> >>> + return;
> >>> +
> >>> + } else if (r == -ENOSPC) {
> >>> + DRM_INFO("Not enoigh PCI address space for a large BAR.");
> >>> + } else if (r) {
> >>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
> >>> + }
> >>> +
> >>> + /* Reinit the doorbell mapping, it is most likely moved as well */
> >>> + amdgpu_doorbell_fini(adev);
> >>> + BUG_ON(amdgpu_doorbell_init(adev));
> >>> +}
> >>> +
> >>>/*
> >>> * GPU helpers function.
> >>> */
> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >>> b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >>> index dc9b6d6..36a7aa5 100644
> >>> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >>> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
> >>> @@ -367,13 +367,15 @@ static int gmc_v7_0_mc_init(struct amdgpu_device
> *adev)
> >>> break;
> >>> }
> >>> adev->mc.vram_width =
Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
On Wed, Mar 15, 2017 at 10:19 PM, Zhang, Jerry wrote:
>> -Original Message-
>> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>> Christian K?nig
>> Sent: Wednesday, March 15, 2017 17:29
>> To: Zhou, David(ChunMing); Ayyappa Ch
>> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
>> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
>> helg...@kernel.org; dri-de...@lists.freedesktop.org
>> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
>>
>> Yes, exactly that.
>
> (I'm not familiar with PCI too much.)
> Is there any restrict for PCI device?
> I'm concerning if any PCI couldn't support it on some motherboard.
It depends on the PCI root bridge. This patch set only implements
support for AMD root bridges. Intel and other vendors would need
similar code.
Alex
>
>>
>> Christian.
>>
>> Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
>> > Does that means we don't need invisible vram later?
>> >
>> > David
>> >
>> > -Original Message-
>> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
>> > Behalf Of Christian K?nig
>> > Sent: Wednesday, March 15, 2017 3:38 PM
>> > To: Ayyappa Ch
>> > Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
>> > amd-gfx@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
>> > helg...@kernel.org; dri-de...@lists.freedesktop.org
>> > Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
>> >
>> > Carizzo is an APU and resizing BARs isn't needed nor supported there.
>> > The CPU can access the full stolen VRAM directly on that hardware.
>> >
>> > As far as I know ASICs with support for this are Tonga, Fiji and all
>> > Polaris variants.
>> >
>> > Christian.
>> >
>> > Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
>> >> Is it possible on Carrizo asics? Or only supports on newer asics?
>> >>
>> >> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
>> >> wrote:
>> >>> From: Christian König
>> >>>
>> >>> Try to resize BAR0 to let CPU access all of VRAM.
>> >>>
>> >>> Signed-off-by: Christian König
>> >>> ---
>> >>>drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
>> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
>> +
>> >>>drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
>> >>>drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
>> >>>4 files changed, 40 insertions(+), 6 deletions(-)
>> >>>
>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> >>> index 3b81ded..905ded9 100644
>> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> >>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
>> amdgpu_device *adev, struct ttm_tt *ttm,
>> >>>struct ttm_mem_reg *mem);
>> >>>void amdgpu_vram_location(struct amdgpu_device *adev, struct
>> amdgpu_mc *mc, u64 base);
>> >>>void amdgpu_gtt_location(struct amdgpu_device *adev, struct
>> >>> amdgpu_mc *mc);
>> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
>> >>>void amdgpu_ttm_set_active_vram_size(struct amdgpu_device *adev,
>> u64 size);
>> >>>int amdgpu_ttm_init(struct amdgpu_device *adev);
>> >>>void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
>> >>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >>> index 118f4e6..92955fe 100644
>> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> >>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct amdgpu_device
>> *adev, struct amdgpu_mc *mc)
>> >>> mc->gtt_size >> 20, mc->gtt_start,
>> >>> mc->gtt_end);
>> >>>}
>> >>>
>> >>> +/**
>> >>> + * amdgpu_resize_bar0 - try to resize BAR0
>> >>> + *
>> >>> + * @adev: amdgpu_device pointer
>> >>> + *
>> >>> + * Try to resize BAR0 to make all VRAM CPU accessible.
>> >>> + */
>> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev) {
>> >>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) - 20;
>> >>> + int r;
>> >>> +
>> >>> + r = pci_resize_resource(adev->pdev, 0, size);
>> >>> +
>> >>> + if (r == -ENOTSUPP) {
>> >>> + /* The hardware don't support the extension. */
>> >>> + return;
>> >>> +
>> >>> + } else if (r == -ENOSPC) {
>> >>> + DRM_INFO("Not enoigh PCI address space for a large
>> >>> BAR.");
>> >>> + } else if (r) {
>> >>> + DRM_ERROR("Problem resizing BAR0 (%d).", r);
>> >>> + }
>> >>> +
>> >>> + /* Reinit the doorbell mapping, it is most likely moved as well
>> >>> */
>> >>> + amdgpu_doorbell_fini(adev);
>> >>> + BUG_ON(amdgpu_doorbell_init(adev));
>> >>> +}
>> >>> +
>> >>>/*
>> >>> * GPU helpers function.
>> >>> */
>> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c
>>
RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
Thanks for your info.
I see.
Regards,
Jerry (Junwei Zhang)
Linux Base Graphics
SRDC Software Development
_
> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Thursday, March 16, 2017 10:25
> To: Zhang, Jerry
> Cc: Christian König; Zhou, David(ChunMing); Ayyappa Ch; linux-
> p...@vger.kernel.org; linux-ker...@vger.kernel.org; dri-
> de...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> helg...@kernel.org; amd-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
>
> On Wed, Mar 15, 2017 at 10:19 PM, Zhang, Jerry wrote:
> >> -Original Message-
> >> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> Behalf Of Christian K?nig
> >> Sent: Wednesday, March 15, 2017 17:29
> >> To: Zhou, David(ChunMing); Ayyappa Ch
> >> Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; amd-
> >> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> helg...@kernel.org; dri-de...@lists.freedesktop.org
> >> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >>
> >> Yes, exactly that.
> >
> > (I'm not familiar with PCI too much.)
> > Is there any restrict for PCI device?
> > I'm concerning if any PCI couldn't support it on some motherboard.
>
> It depends on the PCI root bridge. This patch set only implements support for
> AMD root bridges. Intel and other vendors would need similar code.
>
> Alex
>
> >
> >>
> >> Christian.
> >>
> >> Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
> >> > Does that means we don't need invisible vram later?
> >> >
> >> > David
> >> >
> >> > -Original Message-
> >> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> > Behalf Of Christian K?nig
> >> > Sent: Wednesday, March 15, 2017 3:38 PM
> >> > To: Ayyappa Ch
> >> > Cc: linux-...@vger.kernel.org; linux-ker...@vger.kernel.org;
> >> > amd-gfx@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> > helg...@kernel.org; dri-de...@lists.freedesktop.org
> >> > Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >> >
> >> > Carizzo is an APU and resizing BARs isn't needed nor supported there.
> >> > The CPU can access the full stolen VRAM directly on that hardware.
> >> >
> >> > As far as I know ASICs with support for this are Tonga, Fiji and all
> >> > Polaris
> variants.
> >> >
> >> > Christian.
> >> >
> >> > Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> >> >> Is it possible on Carrizo asics? Or only supports on newer asics?
> >> >>
> >> >> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> >> >> wrote:
> >> >>> From: Christian König
> >> >>>
> >> >>> Try to resize BAR0 to let CPU access all of VRAM.
> >> >>>
> >> >>> Signed-off-by: Christian König
> >> >>> ---
> >> >>>drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 +
> >> >>>drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
> >> +
> >> >>>drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c | 8 +---
> >> >>>drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 8 +---
> >> >>>4 files changed, 40 insertions(+), 6 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> index 3b81ded..905ded9 100644
> >> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> >> amdgpu_device *adev, struct ttm_tt *ttm,
> >> >>>struct ttm_mem_reg *mem);
> >> >>>void amdgpu_vram_location(struct amdgpu_device *adev, struct
> >> amdgpu_mc *mc, u64 base);
> >> >>>void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> >> >>> amdgpu_mc *mc);
> >> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> >> >>>void amdgpu_ttm_set_active_vram_size(struct amdgpu_device
> >> >>> *adev,
> >> u64 size);
> >> >>>int amdgpu_ttm_init(struct amdgpu_device *adev);
> >> >>>void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
> >> >>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> >>> index 118f4e6..92955fe 100644
> >> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> >>> @@ -692,6 +692,35 @@ void amdgpu_gtt_location(struct
> >> >>> amdgpu_device
> >> *adev, struct amdgpu_mc *mc)
> >> >>> mc->gtt_size >> 20, mc->gtt_start,
> >> >>> mc->gtt_end);
> >> >>>}
> >> >>>
> >> >>> +/**
> >> >>> + * amdgpu_resize_bar0 - try to resize BAR0
> >> >>> + *
> >> >>> + * @adev: amdgpu_device pointer
> >> >>> + *
> >> >>> + * Try to resize BAR0 to make all VRAM CPU accessible.
> >> >>> + */
> >> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev) {
> >> >>> + u32 size = max(ilog2(adev->mc.real_vram_size - 1) + 1, 20) -
> >
Re: [PATCH 2/2] drm/amdgpu/vi: add missing error handling when setting uvd dclk
Hi Alex, On 16 March 2017 at 02:06, Alex Deucher wrote: > Noticed-by: David Binderman In case it matters - Reported-by or Suggested-by are the more common tags. Quick search in kernel history [since 2007] shows less than ~60 instances of the above with ~20 from yourself. > Signed-off-by: Alex Deucher > --- > drivers/gpu/drm/amd/amdgpu/vi.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c > index 28385b8..eff123b 100644 > --- a/drivers/gpu/drm/amd/amdgpu/vi.c > +++ b/drivers/gpu/drm/amd/amdgpu/vi.c > @@ -795,6 +795,8 @@ static int vi_set_uvd_clocks(struct amdgpu_device *adev, > u32 vclk, u32 dclk) > return r; > > r = vi_set_uvd_clock(adev, dclk, ixCG_DCLK_CNTL, ixCG_DCLK_STATUS); > + if (r) > + return r; > > return 0; One can drop the intermediate "r" here return vi_set_uvd_clock(adev, dclk, ixCG_DCLK_CNTL, ixCG_DCLK_STATUS); Either way both patches are correct. so FWIW Reviewed-by: Emil Velikov -Emil ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/2] drm/amdgpu: insert partial mappings before and after directly
Currently it may miss one page before or after the target mapping
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index f7c02a9..511c6c9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1767,7 +1767,11 @@ int amdgpu_vm_bo_clear_mappings(struct amdgpu_device
*adev,
before->it.last = saddr - 1;
before->offset = tmp->offset;
before->flags = tmp->flags;
+
list_add(&before->list, &tmp->list);
+ interval_tree_insert(&before->it, &vm->va);
+ if (before->flags & AMDGPU_PTE_PRT)
+ amdgpu_vm_prt_get(adev);
}
/* Remember mapping split at the end */
@@ -1777,7 +1781,11 @@ int amdgpu_vm_bo_clear_mappings(struct amdgpu_device
*adev,
after->offset = tmp->offset;
after->offset += after->it.start - tmp->it.start;
after->flags = tmp->flags;
+
list_add(&after->list, &tmp->list);
+ interval_tree_insert(&after->it, &vm->va);
+ if (after->flags & AMDGPU_PTE_PRT)
+ amdgpu_vm_prt_get(adev);
}
list_del(&tmp->list);
@@ -1799,24 +1807,6 @@ int amdgpu_vm_bo_clear_mappings(struct amdgpu_device
*adev,
trace_amdgpu_vm_bo_unmap(NULL, tmp);
}
- /* Insert partial mapping before the range*/
- if (before->it.start != before->it.last) {
- interval_tree_insert(&before->it, &vm->va);
- if (before->flags & AMDGPU_PTE_PRT)
- amdgpu_vm_prt_get(adev);
- } else {
- kfree(before);
- }
-
- /* Insert partial mapping after the range */
- if (after->it.start != after->it.last) {
- interval_tree_insert(&after->it, &vm->va);
- if (after->flags & AMDGPU_PTE_PRT)
- amdgpu_vm_prt_get(adev);
- } else {
- kfree(after);
- }
-
return 0;
}
--
1.9.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/2] drm/amdgpu: fix bo_va tracing for bo unmap
Signed-off-by: Junwei Zhang --- drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h index d5a00f7..c3182e4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h @@ -245,7 +245,7 @@ ), TP_fast_assign( - __entry->bo = bo_va->bo; + __entry->bo = bo_va ? bo_va->bo : NULL; __entry->start = mapping->it.start; __entry->last = mapping->it.last; __entry->offset = mapping->offset; -- 1.9.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 0/4] [libdrm] support PRT and replace interface
* add PRT flag and new VA op * fix flag setting for current VA op function * Why don't we set flag for current VA op function? * [RFC] implement new VA fun to support NULL bo Junwei Zhang (4): amdgpu: add new VA operations CLEAR and REPLACE amdgpu: set va flag with input parameter amdgpu: add PRT page attribute amdgpu: add a new bo va function to support NULL bo amdgpu/amdgpu.h | 7 +++ amdgpu/amdgpu_bo.c | 42 -- include/drm/amdgpu_drm.h | 4 3 files changed, 51 insertions(+), 2 deletions(-) -- 1.9.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 1/4] amdgpu: add new VA operations CLEAR and REPLACE
Signed-off-by: Junwei Zhang
---
include/drm/amdgpu_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 69a7340..34f8282 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -410,6 +410,8 @@ struct drm_amdgpu_gem_op {
#define AMDGPU_VA_OP_MAP 1
#define AMDGPU_VA_OP_UNMAP 2
+#define AMDGPU_VA_OP_CLEAR 3
+#define AMDGPU_VA_OP_REPLACE 4
/* Delay the page table update till the next CS */
#define AMDGPU_VM_DELAY_UPDATE (1 << 0)
--
1.9.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 2/4] amdgpu: set va flag with input parameter
Signed-off-by: Junwei Zhang --- amdgpu/amdgpu_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c index 6189e5a..800b77a 100644 --- a/amdgpu/amdgpu_bo.c +++ b/amdgpu/amdgpu_bo.c @@ -941,7 +941,7 @@ int amdgpu_bo_va_op(amdgpu_bo_handle bo, memset(&va, 0, sizeof(va)); va.handle = bo->handle; va.operation = ops; - va.flags = AMDGPU_VM_PAGE_READABLE | + va.flags = flags | AMDGPU_VM_PAGE_READABLE | AMDGPU_VM_PAGE_WRITEABLE | AMDGPU_VM_PAGE_EXECUTABLE; va.va_address = addr; -- 1.9.1 ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 3/4] amdgpu: add PRT page attribute
Signed-off-by: Junwei Zhang
---
include/drm/amdgpu_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index 34f8282..a73b40a 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -423,6 +423,8 @@ struct drm_amdgpu_gem_op {
#define AMDGPU_VM_PAGE_WRITEABLE (1 << 2)
/* executable mapping, new for VI */
#define AMDGPU_VM_PAGE_EXECUTABLE (1 << 3)
+/* partially resident texture */
+#define AMDGPU_VM_PAGE_PRT (1 << 4)
struct drm_amdgpu_gem_va {
/** GEM object handle */
--
1.9.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
[PATCH 4/4] amdgpu: add a new bo va function to support NULL bo
Signed-off-by: Junwei Zhang
---
amdgpu/amdgpu.h| 7 +++
amdgpu/amdgpu_bo.c | 40 +++-
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index 84ab688..a9fddd6 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1429,6 +1429,13 @@ int amdgpu_bo_va_op(amdgpu_bo_handle bo,
uint64_t flags,
uint32_t ops);
+int amdgpu_bo_va_op2(amdgpu_device_handle dev,
+amdgpu_bo_handle bo,
+uint64_t offset,
+uint64_t size,
+uint64_t addr,
+uint64_t flags,
+uint32_t ops);
/**
* VA mapping/unmapping for the buffer object
*
diff --git a/amdgpu/amdgpu_bo.c b/amdgpu/amdgpu_bo.c
index 800b77a..421e440 100644
--- a/amdgpu/amdgpu_bo.c
+++ b/amdgpu/amdgpu_bo.c
@@ -924,13 +924,51 @@ int amdgpu_bo_list_update(amdgpu_bo_list_handle handle,
return r;
}
-int amdgpu_bo_va_op(amdgpu_bo_handle bo,
+int amdgpu_bo_va_op2(amdgpu_device_handle dev,
+amdgpu_bo_handle bo,
uint64_t offset,
uint64_t size,
uint64_t addr,
uint64_t flags,
uint32_t ops)
{
+ struct drm_amdgpu_gem_va va;
+ int r;
+
+ if (ops != AMDGPU_VA_OP_MAP && ops != AMDGPU_VA_OP_UNMAP &&
+ ops != AMDGPU_VA_OP_REPLACE &&
+ ops != AMDGPU_VA_OP_CLEAR)
+ return -EINVAL;
+
+ memset(&va, 0, sizeof(va));
+ if (bo)
+ va.handle = bo->handle;
+ else
+ va.handle = NULL;
+ if (flags & AMDGPU_VM_PAGE_PRT)
+ flags &= AMDGPU_VM_PAGE_PRT;
+ else
+ flags |= AMDGPU_VM_PAGE_READABLE | AMDGPU_VM_PAGE_WRITEABLE |
+ AMDGPU_VM_PAGE_EXECUTABLE;
+
+ va.operation = ops;
+ va.flags = flags;
+ va.va_address = addr;
+ va.offset_in_bo = offset;
+ va.map_size = ALIGN(size, getpagesize());
+
+ r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_GEM_VA, &va, sizeof(va));
+
+ return r;
+}
+
+int amdgpu_bo_va_op(amdgpu_bo_handle bo,
+ uint64_t offset,
+ uint64_t size,
+ uint64_t addr,
+ uint64_t flags,
+ uint32_t ops)
+{
amdgpu_device_handle dev = bo->dev;
struct drm_amdgpu_gem_va va;
int r;
--
1.9.1
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: [PATCH 2/4] sync_file: add replace and export some functionality
On 15 March 2017 at 18:55, Daniel Vetter wrote:
> On Wed, Mar 15, 2017 at 02:19:16PM +1000, Dave Airlie wrote:
>> >
>> > uabi semantics question: Should we wake up everyone when the fence gets
>> > replaced? What's the khr semaphore expectation here?
>>
>> There are no real semantics for this case, you either wait the semaphore and
>> replace it with NULL, or signal it where you replace the fence with a new
>> fence.
>>
>> Nobody should be using the sync_fence interfaces to poll on these fence fds.
>>
>> So not crashing for non-vulkan behaviour is what we need.
>>
>> The spec doesn't know anything other than this is an opaque fd,
>> it shouldn't be doing operations on it, execpt importing it.
>>
>> >> static int sync_file_set_fence(struct sync_file *sync_file,
>> >> struct dma_fence **fences, int num_fences)
>> >> {
>> >> @@ -292,8 +328,10 @@ static void sync_file_free(struct kref *kref)
>> >> struct sync_file *sync_file = container_of(kref, struct sync_file,
>> >>kref);
>> >>
>> >> - if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
>> >> - dma_fence_remove_callback(sync_file->fence, &sync_file->cb);
>> >> + if (sync_file->fence) {
>> >> + if (test_bit(POLL_ENABLED, &sync_file->fence->flags))
>> >> + dma_fence_remove_callback(sync_file->fence,
>> >> &sync_file->cb);
>> >> + }
>> >> dma_fence_put(sync_file->fence);
>> >> kfree(sync_file);
>> >> }
>> >
>> > I think you've missed _poll, won't that oops now?
>>
>> I don't think it will, all the stuff do inside the poll handler is
>> protected by the mutex
>> or do you think we should hook the new fence if the old fence has poll
>> enabled?
>
> Yeah, or at least wake them up somehow and restart it. Or well at least
> think what would happen when that does, and whether we care. If vk says
> you get undefined behaviour when you replace the fence of a semaphore when
> the old one hasn't signalled yet, then we don't need to do anything.
In VK a semaphore is an object, there is no operations on it to touch the fence,
the sync_file implementation is there to support passing the fd
backing the semaphore
between vulkan processes and maybe later GL processes. Nothing else is defined,
and is left as an implementation detail. We just need to protect
against someone doing
something stupid with the sync_file fd, currently however replacing is
a kernel internal
operation only happens when you signal or wait. So I expect yes you could export
a sem, import it, poll it, when it has never been signaled, which is undefined,
export it, import, signal it, then poll on it, and if someone waits on
it then the poll
is probably going to have issues, this behaviour is totally outside
the vulkan spec.
Dave.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Does amdgpu driver supports if CONFIG_PREEMPT is enabled
Hello, Can amdgpu driver supports if we enable CONFIG_PREEMPT in configuration? Thanks, Ayyappa ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
