Ping ..
Best wishes
Emily Deng
>-Original Message-
>From: amd-gfx On Behalf Of Deng,
>Emily
>Sent: Friday, May 24, 2019 10:29 AM
>To: Alex Deucher
>Cc: amd-gfx list
>Subject: RE: [PATCH] drm/amdgpu: Need to set the baco cap before baco
>reset
>
>[CAUTION: External Email]
>
>>-Or
Am 24.05.19 um 00:41 schrieb Zeng, Oak:
TTM doesn't support CPU mapping of sg type bo (under which
mmio bo is created). Switch mmaping of mmio page to kfd
device file.
Change-Id: I1a1a24f2ac0662be3783d460c137731ade007b83
Signed-off-by: Oak Zeng
Acked-by: Christian König
---
drivers/gpu/d
Yeah, that shouldn't be a problem. We just need to make sure we don't
busy wait for the BOs to become available.
Christian.
Am 24.05.19 um 07:35 schrieb Liang, Prike:
Use Abaqus torturing the amdgpu driver more times will running into locking
first busy BO deadlock .Then the caller will
retur
dc_destroy should be called amdgpu_cgs_destroy_device,
as it will use cgs context to read or write registers.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amd
On Thu, May 23, 2019 at 03:49:05PM -0600, Khalid Aziz wrote:
> On 5/23/19 2:11 PM, Catalin Marinas wrote:
> > On Thu, May 23, 2019 at 11:51:40AM -0600, Khalid Aziz wrote:
> >> On 5/21/19 6:04 PM, Kees Cook wrote:
> >>> As an aside: I think Sparc ADI support in Linux actually side-stepped
> >>> this
Am 24.05.19 um 11:52 schrieb Emily Deng:
dc_destroy should be called amdgpu_cgs_destroy_device,
as it will use cgs context to read or write registers.
Signed-off-by: Emily Deng
Acked-by: Christian König
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ---
1 file changed, 4
As it will destory clear_state_obj, and also will
unpin it in the gfx_v9_0_sw_fini, so don't need to
call csb_vram unpin in gfx_v9_0_hw_fini, or it will
have unpin warning.
Signed-off-by: Emily Deng
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 16
1 file changed, 16 deletions(-)
On Thu, May 23, 2019 at 02:31:16PM -0700, Kees Cook wrote:
> On Thu, May 23, 2019 at 06:43:46PM +0100, Catalin Marinas wrote:
> > On Thu, May 23, 2019 at 09:38:19AM -0700, Kees Cook wrote:
> > > What about testing tools that intentionally insert high bits for syscalls
> > > and are _expecting_ them
Em Mon, 6 May 2019 18:31:00 +0200
Andrey Konovalov escreveu:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> videobuf_dma_contig_user_get() uses provide
Signed-off-by: Tom St Denis
---
Documentation/gpu/amdgpu.rst| 11 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 4 ++--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index cacfcfad2356..86138798128f
Signed-off-by: Tom St Denis
---
Documentation/gpu/amdgpu.rst | 9
drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 28
2 files changed, 37 insertions(+)
diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst
index a740e491dfcc..cacfcfad2
On Thu, May 23, 2019 at 05:57:09PM +0100, Catalin Marinas wrote:
> On Thu, May 23, 2019 at 11:42:57AM +0100, Dave P Martin wrote:
> > On Wed, May 22, 2019 at 09:20:52PM -0300, Jason Gunthorpe wrote:
> > > On Wed, May 22, 2019 at 02:49:28PM +0100, Dave Martin wrote:
> > > > If multiple people will c
On 5/24/19 4:11 AM, Catalin Marinas wrote:
> On Thu, May 23, 2019 at 03:49:05PM -0600, Khalid Aziz wrote:
>> On 5/23/19 2:11 PM, Catalin Marinas wrote:
>>> On Thu, May 23, 2019 at 11:51:40AM -0600, Khalid Aziz wrote:
On 5/21/19 6:04 PM, Kees Cook wrote:
> As an aside: I think Sparc ADI sup
Acked-by: Slava Abramov
From: amd-gfx on behalf of StDenis, Tom
Sent: Friday, May 24, 2019 9:23:50 AM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH 2/2] drm/amd/doc: Add RAS documentation to guide
[CAUTION: External Email]
Signed-off-by:
Acked-by: Slava Abramov
From: amd-gfx on behalf of StDenis, Tom
Sent: Friday, May 24, 2019 9:23:49 AM
To: amd-gfx@lists.freedesktop.org
Cc: StDenis, Tom
Subject: [PATCH 1/2] drm/amd/doc: Add XGMI sysfs documentation
[CAUTION: External Email]
Signed-off-by: To
From: Harry Wentland
[WHY]
Some early Raven boards had a bad SBIOS that doesn't play nicely with
the DMCU FW. We thought the issues were fixed by ignoring errors on DMCU
load but that doesn't seem to be the case. We've still seen reports of
users unable to boot their systems at all.
[HOW]
Disabl
On Fri, May 24, 2019 at 9:23 AM StDenis, Tom wrote:
>
> Signed-off-by: Tom St Denis
Series is:
Reviewed-by: Alex Deucher
> ---
> Documentation/gpu/amdgpu.rst | 9
> drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c | 28
> 2 files changed, 37 insertions(+
On Mon, May 06, 2019 at 06:30:51PM +0200, Andrey Konovalov wrote:
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> This patch allows tagged pointers to be p
Hi
Curious to know what this means for folk that have newer Raven1 boards
that didn't have issues loading the firmware
Cheers
Mike
On Fri, 24 May 2019 at 16:34, Alex Deucher wrote:
>
> From: Harry Wentland
>
> [WHY]
> Some early Raven boards had a bad SBIOS that doesn't play nicely with
> the
On Fri, May 24, 2019 at 12:09 PM Mike Lothian wrote:
>
> Hi
>
> Curious to know what this means for folk that have newer Raven1 boards
> that didn't have issues loading the firmware
You won't get ABM I think. ABM is the automatic backlight management.
Alex
>
> Cheers
>
> Mike
>
> On Fri, 24 Ma
I realise you don't want to enable this as it's breaking some people's
systems, but could we add a new boot parameter to force it for working
systems? Or check against a black list maybe?
On Fri, 24 May 2019 at 17:20, Alex Deucher wrote:
>
> On Fri, May 24, 2019 at 12:09 PM Mike Lothian wrote:
>
On Fri, May 24, 2019 at 12:32 PM Mike Lothian wrote:
>
> I realise you don't want to enable this as it's breaking some people's
> systems, but could we add a new boot parameter to force it for working
> systems? Or check against a black list maybe?
We could probably add a whitelist. I'm not sure
On Thu, May 23, 2019 at 10:29 PM Deng, Emily wrote:
>
>
>
> >-Original Message-
> >From: Alex Deucher
> >Sent: Friday, May 24, 2019 12:09 AM
> >To: Deng, Emily
> >Cc: amd-gfx list
> >Subject: Re: [PATCH] drm/amdgpu: Need to set the baco cap before baco
> >reset
> >
> >[CAUTION: External
Hi Oak,
I'm not sure why this is part of the GWS patch series. It's unrelated to
GWS. Anyway, see one comment inline.
On 2019-05-23 6:41 p.m., Zeng, Oak wrote:
> TTM doesn't support CPU mapping of sg type bo (under which
> mmio bo is created). Switch mmaping of mmio page to kfd
> device file.
>
add pmu counters to monitor amdgpu device performance
Change-Id: I8449f4ea824c411ee24a5b783ac066189b9de08e
Signed-off-by: Jonathan Kim
---
drivers/gpu/drm/amd/amdgpu/Makefile| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_pmu.c| 370 +++
On 2019-05-24 3:12 p.m., Kim, Jonathan wrote:
> add pmu counters to monitor amdgpu device performance
>
> Change-Id: I8449f4ea824c411ee24a5b783ac066189b9de08e
> Signed-off-by: Jonathan Kim
> ---
> drivers/gpu/drm/amd/amdgpu/Makefile| 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
On 2019-05-23 6:41 p.m., Zeng, Oak wrote:
> Add functions in process queue manager to
> set/unset queue gws. Also set process's number
> of gws used. Currently only one queue in
> process can use and use all gws.
>
> Change-Id: I03e480c8692db3eabfc3a188cce8904d5d962ab7
> Signed-off-by: Oak Zeng
>
On 2019-05-23 6:41 p.m., Zeng, Oak wrote:
> Add a new kfd ioctl to allocate queue GWS. Queue
> GWS is released on queue destroy.
>
> Change-Id: I60153c26a577992ad873e4292e759e5c3d5bbd15
> Signed-off-by: Oak Zeng
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2
On 2019-05-23 5:06 a.m., Christian König wrote:
> [CAUTION: External Email]
>
> Leaving BOs on the LRU is harmless. We always did this for VM page table
> and per VM BOs.
>
> The key point is that BOs which couldn't be reserved can't be evicted.
> So what happened is that an application used basica
29 matches
Mail list logo
