Reviewed-by: Kevin Wang
Best Regards,
Kevin
From: amd-gfx on behalf of Evan Quan
Sent: Friday, August 16, 2019 2:08 PM
To: amd-gfx@lists.freedesktop.org
Cc: Quan, Evan
Subject: [PATCH 1/4] drm/amd/powerplay: update Arcturus smc fw and driver
interface header
The corresponding pointer has been checked at the early
stage of each function.
Change-Id: Id8e264b4ba3734f91a33b6f0f408884453ea74fa
Signed-off-by: Guchun Chen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gp
This is available with firmwareinfo table v3.2 or later.
Change-Id: I223edf3c616b9e3e2527c752214fef5ab53d1cea
Signed-off-by: Evan Quan
---
.../gpu/drm/amd/powerplay/inc/amdgpu_smu.h| 3 +++
drivers/gpu/drm/amd/powerplay/smu_v11_0.c | 21 +++
2 files changed, 24 insertion
On fclk dpm disabled, the default dpm table will be setup with only one
level and clock frequency as bootup value.
Change-Id: Iecf74aa5bd10c9aa7839bc32877cfa99bcbef4b3
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/arcturus_ppt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-
Update smc fw and driver interface header.
Change-Id: If4ac09c41b1309f746b757f78880fffb491d50f8
Signed-off-by: Evan Quan
---
.../powerplay/inc/smu11_driver_if_arcturus.h| 17 +++--
drivers/gpu/drm/amd/powerplay/inc/smu_v11_0.h | 2 +-
2 files changed, 12 insertions(+), 7 delet
Do not expose those unsupported clock domains through sysfs on
Arcturus.
Change-Id: I526e7bd457fdcd8c79d4581bb9b77e5cb57f5844
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drive
On Fri, Aug 16, 2019 at 12:43:07AM +, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
>
> > struct page. In this case any way we can update the
> > nouveau_dmem_page() to check that page page->pgmap == the
> > expected pgmap.
>
> I was also wondering if
On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> So nor HMM nor driver should dereference the struct page (i do not
> think any iommu driver would either),
Both current hmm drivers convert the hmm pfn back to a page and
eventually call dma_map_page on it. As do the ODP patches fro
On Thu, Aug 15, 2019 at 5:41 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 01:47:12PM -0700, Dan Williams wrote:
> > On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote:
> > >
> > > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> > >
> > > > So nor HMM nor driver should
Reviewed-by: changzhu
-Original Message-
From: amd-gfx On Behalf Of Feifei Xu
Sent: Friday, August 16, 2019 11:22 AM
To: amd-gfx@lists.freedesktop.org
Cc: Xu, Feifei ; Li, Candice
Subject: [PATCH] drm/amdgpu: Set no-retry as default.
This is to improve performance.
Signed-off-by: Feif
This is to improve performance.
Signed-off-by: Feifei Xu
Tested-by: Candice Li
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 153705848cc
On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse wrote:
>
> On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote:
> > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
> > >
> > > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > > > On Wed, Aug 14, 2019 at 6:28 AM Jason
On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote:
>
> On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
>
> > So nor HMM nor driver should dereference the struct page (i do not
> > think any iommu driver would either),
>
> Er, they do technically deref the struct page:
>
> nouvea
On Thu, Aug 15, 2019 at 04:51:33PM -0400, Jerome Glisse wrote:
> struct page. In this case any way we can update the
> nouveau_dmem_page() to check that page page->pgmap == the
> expected pgmap.
I was also wondering if that is a problem.. just blindly doing a
container_of on the page->pgmap does
On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> So nor HMM nor driver should dereference the struct page (i do not
> think any iommu driver would either),
Er, they do technically deref the struct page:
nouveau_dmem_convert_pfn(struct nouveau_drm *drm,
st
On Thu, Aug 15, 2019 at 08:52:56PM +, Yang, Philip wrote:
> hmm_range_fault may return NULL pages because some of pfns are equal to
> HMM_PFN_NONE. This happens randomly under memory pressure. The reason is
> for swapped out page pte path, hmm_vma_handle_pte doesn't update fault
> variable from
On Thu, Aug 15, 2019 at 01:47:12PM -0700, Dan Williams wrote:
> On Thu, Aug 15, 2019 at 1:41 PM Jason Gunthorpe wrote:
> >
> > On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
> >
> > > So nor HMM nor driver should dereference the struct page (i do not
> > > think any iommu driver wo
On 2019-08-13 17:21, Zhao, Yong wrote:
> The name field in node topology has not been used. We re-purpose it to
> hold the asic name, which can be queried by user space applications
> through sysfs.
>
> Change-Id: I74f4f5487db169004a9d27ea15abe99261c86220
> Signed-off-by: Yong Zhao
Reviewed-by: F
On Thu, Aug 15, 2019 at 08:52:56PM +, Yang, Philip wrote:
> hmm_range_fault may return NULL pages because some of pfns are equal to
> HMM_PFN_NONE. This happens randomly under memory pressure. The reason is
> for swapped out page pte path, hmm_vma_handle_pte doesn't update fault
> variable from
hmm_range_fault may return NULL pages because some of pfns are equal to
HMM_PFN_NONE. This happens randomly under memory pressure. The reason is
for swapped out page pte path, hmm_vma_handle_pte doesn't update fault
variable from cpu_flags, so it failed to call hmm_vam_do_fault to swap
the page in.
On Thu, Aug 15, 2019 at 08:41:33PM +, Jason Gunthorpe wrote:
> On Thu, Aug 15, 2019 at 04:33:06PM -0400, Jerome Glisse wrote:
>
> > So nor HMM nor driver should dereference the struct page (i do not
> > think any iommu driver would either),
>
> Er, they do technically deref the struct page:
>
On Thu, Aug 15, 2019 at 01:12:22PM -0700, Dan Williams wrote:
> On Thu, Aug 15, 2019 at 12:44 PM Jerome Glisse wrote:
> >
> > On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote:
> > > On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
> > > >
> > > > On Wed, Aug 14, 2019 at 07:48:28A
On Thu, Aug 15, 2019 at 10:28:21AM +0200, Christian König wrote:
> Am 07.08.19 um 01:15 schrieb Jason Gunthorpe:
> > From: Jason Gunthorpe
> >
> > radeon is using a device global hash table to track what mmu_notifiers
> > have been registered on struct mm. This is better served with the new
> > g
On Thu, Aug 15, 2019 at 12:36:58PM -0700, Dan Williams wrote:
> On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
> >
> > On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> > > >
> > > > On Wed, Aug 14, 2019 at 09:38:54
On Thu, Aug 15, 2019 at 02:03:25PM -0400, Jerome Glisse wrote:
> On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> > > > On Tue, Aug 13, 2019 at 0
On Thu, Aug 15, 2019 at 11:07 AM Jerome Glisse wrote:
>
> On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> > On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> > >
> > > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> > > > On Tue, Aug 13, 2019 at 06:36:3
On 2019-08-15 2:19 p.m., Thai, Thong wrote:
> Enable VCN Dynamic Powergating on Renoir devices.
>
> This will also enable indirect SRAM loading of VCN firmware on Renoir.
This will enable indirect SRAM loading for VCN DPG mode initialization.
With that fixed, the patch is:
Reviewed-by: Leo Liu
This patch is:
Reviewed-by: Leo Liu
On 2019-08-15 2:19 p.m., Thai, Thong wrote:
> This reverts commit 69fcd7347f6fb11edc7eaea7c7b9cff0044ce17e.
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 9 +++--
> drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 9 +++--
> 2 files changed, 6 inserti
This reverts commit 69fcd7347f6fb11edc7eaea7c7b9cff0044ce17e.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c | 9 +++--
drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c | 9 +++--
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vcn.c
b/drivers/gpu/drm
Enable VCN Dynamic Powergating on Renoir devices.
This will also enable indirect SRAM loading of VCN firmware on Renoir.
Signed-off-by: Thong Thai
---
drivers/gpu/drm/amd/amdgpu/soc15.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c
b/
Reviewed-by: Lyude Paul
On Wed, 2019-08-14 at 12:44 +0200, Dariusz Marcinkiewicz wrote:
> Pass the connector info to the CEC adapter. This makes it possible
> to associate the CEC adapter with the corresponding drm connector.
>
> Signed-off-by: Dariusz Marcinkiewicz
> Signed-off-by: Hans Verkui
On Wed, Aug 14, 2019 at 07:48:28AM -0700, Dan Williams wrote:
> On Wed, Aug 14, 2019 at 6:28 AM Jason Gunthorpe wrote:
> >
> > On Wed, Aug 14, 2019 at 09:38:54AM +0200, Christoph Hellwig wrote:
> > > On Tue, Aug 13, 2019 at 06:36:33PM -0700, Dan Williams wrote:
> > > > Section alignment constraint
On Tue, Aug 13, 2019 at 05:58:52PM -0400, Jerome Glisse wrote:
> On Wed, Aug 07, 2019 at 08:02:14AM -0700, Ralph Campbell wrote:
> > When memory is migrated to the GPU it is likely to be accessed by GPU
> > code soon afterwards. Instead of waiting for a GPU fault, map the
> > migrated memory into t
We need to set certain power gating flags after we determine
if the firmware version is sufficient to support gfxoff.
Previously we set the pg flags in early init, but we later
we might have disabled gfxoff if the firmware versions didn't
support it. Move adding the additional pg flags after we
de
On Thu, Aug 15, 2019 at 10:59 AM Kai-Heng Feng
wrote:
>
> at 21:33, Deucher, Alexander wrote:
>
> > Thanks for finding this! I think the attached patch should fix the issue
> > and it's much less invasive.
>
> Yes it also fix the issue, please add by tested-by:
> Tested-by: Kai-Heng Feng
>
Tha
at 21:33, Deucher, Alexander wrote:
Thanks for finding this! I think the attached patch should fix the issue
and it's much less invasive.
Yes it also fix the issue, please add by tested-by:
Tested-by: Kai-Heng Feng
I took this more or less future proof approach because I think this won’t
Am 15.08.19 um 16:15 schrieb Alex Deucher:
> On Thu, Aug 15, 2019 at 4:34 AM Koenig, Christian
> wrote:
>> Am 15.08.19 um 09:27 schrieb Christoph Hellwig:
>>> radeon uses a need_dma32 flag to indicate to the drm core that some
>>> allocations need to be done using GFP_DMA32, but it only checks the
On Thu, Aug 15, 2019 at 4:34 AM Koenig, Christian
wrote:
>
> Am 15.08.19 um 09:27 schrieb Christoph Hellwig:
> > radeon uses a need_dma32 flag to indicate to the drm core that some
> > allocations need to be done using GFP_DMA32, but it only checks the
> > device addressing capabilities to make th
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: Yuan, Xiaojie
Sent: 2019年8月15日 16:44
To: amd-gfx@lists.freedesktop.org
Cc: Zhang, Hawking ; Xiao, Jack ;
Yuan, Xiaojie
Subject: [PATCH] drm/amdgpu: remove special autoload handling for navi12
s/r list in rlc firmwar
Series is:
Reviewed-by: Alex Deucher
From: amd-gfx on behalf of Yuan,
Xiaojie
Sent: Thursday, August 15, 2019 5:48 AM
To: amd-gfx@lists.freedesktop.org
Cc: Xiao, Jack ; Huang, Ray ; Yuan,
Xiaojie ; Zhang, Hawking
Subject: [PATCH 2/2] drm/amdgpu: add firmware
On Thu, Aug 15, 2019 at 4:43 AM Yuan, Xiaojie wrote:
>
> s/r list in rlc firmware is ready, so remove the special autoload handling
>
> Signed-off-by: Xiaojie Yuan
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
On Thu, Aug 15, 2019 at 08:34:10AM +, Koenig, Christian wrote:
> Looks sane to me. Reviewed-by: Christian König .
>
> Should we merge this through our normal amdgpu/radeon branches or do you
> want to send this upstream somehow else?
This is intended for your trees.
firmware header information is printed for direct fw loading but not
added for psp fw loading yet
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 54 +
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/driv
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 35fd46bdfc53..82f6b413718b 100644
--- a/drivers/gpu/drm/am
Am 14.08.19 um 21:48 schrieb Andrey Grodzovsky:
Double defintion of 'i'
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
I think in the long term we could as well remove
CONFIG_DRM_AMDGPU_GART_DEBUGFS and drop the extra debug functionality.
Christian.
---
drivers/gpu/drm
s/r list in rlc firmware is ready, so remove the special autoload handling
Signed-off-by: Xiaojie Yuan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ps
Am 15.08.19 um 09:27 schrieb Christoph Hellwig:
> radeon uses a need_dma32 flag to indicate to the drm core that some
> allocations need to be done using GFP_DMA32, but it only checks the
> device addressing capabilities to make that decision. Unfortunately
> PCIe root ports that have limited addr
Am 07.08.19 um 01:15 schrieb Jason Gunthorpe:
From: Jason Gunthorpe
radeon is using a device global hash table to track what mmu_notifiers
have been registered on struct mm. This is better served with the new
get/put scheme instead.
radeon has a bug where it was not blocking notifier release()
radeon uses a need_dma32 flag to indicate to the drm core that some
allocations need to be done using GFP_DMA32, but it only checks the
device addressing capabilities to make that decision. Unfortunately
PCIe root ports that have limited addressing exist as well. Use the
dma_addressing_limited in
amdgpu uses a need_dma32 flag to indicate to the drm core that some
allocations need to be done using GFP_DMA32, but it only checks the
device addressing capabilities to make that decision. Unfortunately
PCIe root ports that have limited addressing exist as well. Use the
dma_addressing_limited in
Hi AMD graphics maintainers,
this series fixes a problem in the radeon driver for systems where the
PCIe root port only supports limited (32-bit) addressing as reported
by Atish. I then also fixed the same issue in amdgpu as the code was
copy and pasted there, and cleaned up the dma mask setting
Use dma_set_mask_and_coherent to set both masks in one go, and remove
the no longer required fallback, as the kernel now always accepts
larger than required DMA masks. Fail the driver probe if we can't
set the DMA mask, as that means the system can only support a larger
mask.
Signed-off-by: Chris
Use dma_set_mask_and_coherent to set both masks in one go, and remove
the no longer required fallback, as the kernel now always accepts
larger than required DMA masks. Fail the driver probe if we can't
set the DMA mask, as that means the system can only support a larger
mask.
Signed-off-by: Chris
53 matches
Mail list logo
