Hi John,
john.hubb...@gmail.com writes:
> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
> b/arch/powerpc/mm/book3s64/iommu_api.c
> index b056cae3388b..e126193ba295 100644
> --- a/arch/powerpc/mm/book3s64/iommu_api.c
> +++ b/arch/powerpc/mm/book3s64/iommu_api.c
> @@ -203,6 +202,7 @@ static
From: tiancyin
[why]
navi14 share same defination of smu interface version with navi10,
anyone of them update the version may break the other one's
version checking.
[how]
create different version defination, so that they can
update their version separately.
Signed-off-by: tiancyin
---
From: tiancyin
update the smu11_driver_if_navi10.h since navi14 smu fw
update to 53.12
Change-Id: If0f729ec87c98f24e1794f0847eac5ba23671e34
Reviewed-by: Evan Quan
Signed-off-by: tiancyin
---
.../drm/amd/powerplay/inc/smu11_driver_if_navi10.h | 25 +-
000
bfe0: 0013
Code: e59f00a0 e1a09003 e1a08002 eb176e54 (e5955018)
---[ end trace f503b374936886c5 ]---
Bisect log attached.
Guenter
---
# bad: [3880be629e26f6c407593602398c6651860d5fae] Add linux-next specific files
for 201
On 8/7/19 7:36 PM, Ira Weiny wrote:
On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
On Wed 07-08-19 10:37:26, Jan Kara wrote:
On Fri 02-08-19 12:14:09, John Hubbard wrote:
On 8/2/19 7:52 AM, Jan Kara wrote:
On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
On Fri, Aug 02, 2019
From: tiancyin
[why]
navi14 share same defination of smu interface version with navi10,
anyone of them update the version may break the other one's
version checking.
[how]
create different version defination, so that they can
update their version separately.
Signed-off-by: tiancyin
---
From: tiancyin
update the smu11_driver_if_navi10.h since navi14 smu fw
update to 53.12
Change-Id: If0f729ec87c98f24e1794f0847eac5ba23671e34
Reviewed-by: Evan Quan
Signed-off-by: tiancyin
---
.../drm/amd/powerplay/inc/smu11_driver_if_navi10.h | 26 +-
Reviewed-by: Xiaojie Yuan
BR,
Xiaojie
From: amd-gfx on behalf of Alex Deucher
Sent: Thursday, August 8, 2019 3:41 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] drm/amdgpu: add navi14 PCI ID
Add the navi14 PCI device id.
On Wed, Aug 7, 2019 at 10:45 AM Jason Gunthorpe wrote:
>
> On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> > There is only a single place where the pgmap is passed over a function
> > call, so replace it with local variables in the places where we deal
> > with the pgmap.
> >
Hi Dave, Daniel,
Fixes for 5.3. Nothing too major bug-wise. I'm reverting the kfd GWS ioctl
that was added this cycle. After working with it for a while the kfd team
decided it wasn't quite right. I should have been stricter with it in the
beginning. Revert it.
The following changes since
On Tue, Aug 06, 2019 at 07:05:38PM +0300, Christoph Hellwig wrote:
>
> Hi Jérôme, Ben, Felix and Jason,
>
> below is a series against the hmm tree which cleans up various minor
> bits and allows HMM_MIRROR to be built on all architectures.
>
> Diffstat:
>
> 11 files changed, 94
On Wed, Aug 7, 2019 at 9:03 AM Koenig, Christian
wrote:
>
> Am 07.08.19 um 15:00 schrieb Christoph Hellwig:
> > On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote:
> Essentially writeq/readq doesn't seems to be available on all
> architectures either.
> >>> writeq/readq
On Tue, Aug 06, 2019 at 07:05:47PM +0300, Christoph Hellwig wrote:
> pte_index is an internal arch helper in various architectures,
> without consistent semantics. Open code that calculation of a PMD
> index based on the virtual address instead.
>
> Signed-off-by: Christoph Hellwig
> ---
>
On Tue, Aug 06, 2019 at 07:05:45PM +0300, Christoph Hellwig wrote:
> All users pass PAGE_SIZE here, and if we wanted to support single
> entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE
> flag instead that uses the huge page size instead of having the
> caller calculate that
On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> There is only a single place where the pgmap is passed over a function
> call, so replace it with local variables in the places where we deal
> with the pgmap.
>
> Signed-off-by: Christoph Hellwig
> mm/hmm.c | 62
Hi Ray,
at 00:03, Huang, Ray wrote:
May I know the all firmware version in your system?
# cat amdgpu_firmware_info
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x
MC feature version: 0, firmware version: 0x
ME feature
On Tue, Aug 6, 2019 at 7:13 PM Will Deacon wrote:
>
> On Wed, Jul 24, 2019 at 03:20:59PM +0100, Will Deacon wrote:
> > On Wed, Jul 24, 2019 at 04:16:49PM +0200, Andrey Konovalov wrote:
> > > On Wed, Jul 24, 2019 at 4:02 PM Will Deacon wrote:
> > > > On Tue, Jul 23, 2019 at 08:03:29PM +0200,
On 2019-08-07 10:29 a.m., David Francis wrote:
> This file was accidentally added to the driver during
> Navi promotion
>
> Nothing includes it. No makefile attempts to compile it, and
> it would fail compilation if they tried
>
> Remove it
>
> Signed-off-by: David Francis
Reviewed-by: Harry
Acked-by: Oak Zeng
Regards,
Oak
-Original Message-
From: amd-gfx On Behalf Of Alex Deucher
Sent: Wednesday, August 7, 2019 11:01 AM
To: amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH] Revert "drm/amdkfd: New IOCTL to allocate queue GWS"
This reverts commit
Thanks. I realized I didn't read the code careful enough...The workaround is
only for navi10 and navi12 - I didn't read this correctly and was thinking
gfxhub tlb invalidation was done twice.
I understand the codes now. I think the HW SDMA bug has been fixed in navi14 so
we don't need that WA
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 the GPU page tables with the same access permissions
as the source CPU page table entries. This preserves copy on write
semantics.
This reverts commit 1a058c3376765ee31d65e28cbbb9d4ff15120056.
This interface is still in too much flux. Revert until
it's sorted out.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 28
include/uapi/linux/kfd_ioctl.h | 20
This file was accidentally added to the driver during
Navi promotion
Nothing includes it. No makefile attempts to compile it, and
it would fail compilation if they tried
Remove it
Signed-off-by: David Francis
---
.../gpu/drm/amd/display/dc/dsc/drm_dsc_dc.c | 453 --
1 file
On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote:
> >> Essentially writeq/readq doesn't seems to be available on all
> >> architectures either.
> > writeq/readq are provided whenever the CPU actually supports 64-bit
> > atomic loads and stores.
>
> Is there a config option which
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in
On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > > > On Fri 02-08-19 11:12:44, Michal Hocko wrote:
> > > > > On Thu 01-08-19 19:19:31,
On Wed, Aug 07, 2019 at 08:53:25AM +, Koenig, Christian wrote:
> Am 07.08.19 um 09:08 schrieb Christoph Hellwig:
> > On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote:
> >> readq/writeq are not supported on all architectures
> > NAK. You must not use atomic_* on __iomem (MMIO) memory.
On Wed, Aug 07, 2019 at 06:57:24AM +, Koenig, Christian wrote:
> Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> > On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
> >> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix
> >> wrote:
> >>> On 2019-08-06 13:44, Jason Gunthorpe wrote:
>
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in
On Wed, Aug 07, 2019 at 01:00:48PM +, Koenig, Christian wrote:
> Am 07.08.19 um 14:59 schrieb Mark Brown:
> > On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote:
> >> Am 07.08.19 um 12:41 schrieb Christoph Hellwig:
> >>> writeq/readq are provided whenever the CPU actually
On Tue, Aug 06, 2019 at 11:47:44PM +, Kuehling, Felix wrote:
> On 2019-08-06 19:15, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > The sequence of mmu_notifier_unregister_no_release(),
> > mmu_notifier_call_srcu() is identical to mmu_notifier_put() with the
> > free_notifier
On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote:
> Am 07.08.19 um 12:41 schrieb Christoph Hellwig:
> > writeq/readq are provided whenever the CPU actually supports 64-bit
> > atomic loads and stores.
> Is there a config option which we can make the driver depend on?
64BIT
Am 07.08.19 um 15:00 schrieb Christoph Hellwig:
> On Wed, Aug 07, 2019 at 10:55:01AM +, Koenig, Christian wrote:
Essentially writeq/readq doesn't seems to be available on all
architectures either.
>>> writeq/readq are provided whenever the CPU actually supports 64-bit
>>> atomic
Hi,
After commit 005440066f92 ("drm/amdgpu: enable gfxoff again on raven series
(v2)”), browsers on Raven Ridge systems cause serious corruption like this:
https://launchpadlibrarian.net/436319772/Screenshot%20from%202019-08-07%2004-20-34.png
Firmwares for Raven Ridge is up-to-date.
Am 07.08.19 um 12:41 schrieb Christoph Hellwig:
> On Wed, Aug 07, 2019 at 08:53:25AM +, Koenig, Christian wrote:
>> Am 07.08.19 um 09:08 schrieb Christoph Hellwig:
>>> On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote:
readq/writeq are not supported on all architectures
>>> NAK.
Am 07.08.19 um 09:40 schrieb Pelloux-prayer, Pierre-eric:
The SOC15_REG_OFFSET() macro wasn't used, making the soft recovery fail.
v2: use WREG32_SOC15 instead of WREG32 + SOC15_REG_OFFSET
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Alex Deucher
Reviewed-by: Christian König
Am 07.08.19 um 09:08 schrieb Christoph Hellwig:
> On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote:
>> readq/writeq are not supported on all architectures
> NAK. You must not use atomic_* on __iomem (MMIO) memory.
Well then what's the right thing to do here?
Essentially writeq/readq
Does the coded below invalidate TLB on both mm and gfx hub?
No, just the gfx hub. The VMHUBs on Navi are unfortunately really buggy,
so we had to do a lot of workarounds to get them into a state where they
actually did what was expected from them.
One major issue for example is that you can't
On Wed 07-08-19 10:37:26, Jan Kara wrote:
> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> > On 8/2/19 7:52 AM, Jan Kara wrote:
> > > On Fri 02-08-19 07:24:43, Matthew Wilcox wrote:
> > > > On Fri, Aug 02, 2019 at 02:41:46PM +0200, Jan Kara wrote:
> > > > > On Fri 02-08-19 11:12:44, Michal Hocko
Am 07.08.19 um 04:31 schrieb Zeng, Oak:
Add definition of all supported mtypes. The RW mtype
is recently introduced for arcturus. Also add definition
for the cachable/snoopable bit, which will be used later
in this series.
Change-Id: I96fc9bb4b6b1e62bdc10b600d8aaa6a802128d6d
Signed-off-by: Oak
Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Guchun Chen
Sent: 2019年8月7日 14:52
To: amd-gfx@lists.freedesktop.org; Zhang, Hawking ; Li,
Dennis ; Pan, Xinhui ; Zhou1, Tao
Cc: Chen, Guchun
Subject: [PATCH v2 libdrm 0/3] add ras inject test
The SOC15_REG_OFFSET() macro wasn't used, making the soft recovery fail.
v2: use WREG32_SOC15 instead of WREG32 + SOC15_REG_OFFSET
Signed-off-by: Pierre-Eric Pelloux-Prayer
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 +-
1 file changed, 1 insertion(+), 1
On Tue, Aug 06, 2019 at 06:33:10PM -0700, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide
On Wed, Aug 07, 2019 at 10:56:40AM +0800, Tao Zhou wrote:
> readq/writeq are not supported on all architectures
NAK. You must not use atomic_* on __iomem (MMIO) memory.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
The series is:
Reviewed-by: Tao Zhou
> -Original Message-
> From: amd-gfx On Behalf Of
> Guchun Chen
> Sent: 2019年8月7日 14:52
> To: amd-gfx@lists.freedesktop.org; Zhang, Hawking
> ; Li, Dennis ; Pan, Xinhui
> ; Zhou1, Tao
> Cc: Chen, Guchun
> Subject: [PATCH v2 libdrm 0/3] add ras
Am 06.08.19 um 22:03 schrieb Jason Gunthorpe:
> On Tue, Aug 06, 2019 at 02:58:58PM -0400, Alex Deucher wrote:
>> On Tue, Aug 6, 2019 at 1:51 PM Kuehling, Felix
>> wrote:
>>> On 2019-08-06 13:44, Jason Gunthorpe wrote:
On Tue, Aug 06, 2019 at 07:05:53PM +0300, Christoph Hellwig wrote:
>
Both umc single_correctable and multi_uncorrectable
inject types are added.
Change-Id: I779f2f4f59c69fb08fdc09b7adba5b36e3af20ce
Signed-off-by: Dennis Li
Signed-off-by: Guchun Chen
---
data/amdgpu_ras.json | 17 +
1 file changed, 17 insertions(+)
diff --git
These patches are to support ras inject test for gfx and umc modules.
Patch v2:
Correct "eject" in all commits to "inject".
Add more error checks and print when parsing configuration file.
Add umc multi_uncorrectable test in default configuration file.
Guchun Chen (3):
amdgpu: add gfx ras
This configuration file will be picked up when
running gfx ras inject tests by amdgpu_test tool.
For the time being, only add those tests that are
successfully trafficked. In addition, this file
can also be modified by user to add or delete ras
inject unit tests for different IP blocks/subblocks.
49 matches
Mail list logo