On Tue, 11 Apr 2017 13:23:53 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Just let know what you need tested, I should be able to turn it around
> > > within a couple of days.
> >
> > That's part of my problem. I don't really know what should be tested.
> > What do people do with their BE machi
Driver must free the console lock whether driver resuming successful
or not. Otherwise, fb_console will be always waiting for the lock and
then cause system stuck.
[ 244.405541] INFO: task kworker/0:0:4 blocked for more than 120 seconds.
[ 244.405543] Tainted: G OE 4.9.0-custo
Change-Id: If0474e24e14d237d2d55731871c5ceb11e5a3601
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/driver
Change-Id: Ifea42c8ae2206143d7e22b35eea537ba9e928fe8
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 13 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 --
2 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu
gtt_mgr_alloc is called by many places in local driver, while
gtt_mgr_new is called by get_node in ttm.
Change-Id: Ia5a18a3b531a01ad7d47f40e08f778e7b94c048a
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions
On 13/04/17 05:12 PM, Huang Rui wrote:
> Driver must free the console lock whether driver resuming successful
> or not. Otherwise, fb_console will be always waiting for the lock and
> then cause system stuck.
>
> [ 244.405541] INFO: task kworker/0:0:4 blocked for more than 120 seconds.
> [ 244.
> -Original Message-
> From: Huang Rui [mailto:ray.hu...@amd.com]
> Sent: Thursday, April 13, 2017 4:12 AM
> To: amd-gfx@lists.freedesktop.org; Deucher, Alexander
> Cc: Koenig, Christian; Wang, Ken; Huang, Ray
> Subject: [PATCH] drm/amdgpu: fix dead lock if any ip block resume failed in
> s
Bring this in line with spec and what commit in upstream drm tree.
Signed-off-by: Harry Wentland
---
This brings this definition in amd-staging-4.9 in line with upstream.
include/drm/drm_dp_helper.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_dp_helper.h
On Thu, Apr 13, 2017 at 10:34 AM, Harry Wentland wrote:
> Bring this in line with spec and what commit in upstream drm tree.
>
> Signed-off-by: Harry Wentland
Acked-by: Alex Deucher
> ---
>
> This brings this definition in amd-staging-4.9 in line with upstream.
>
> include/drm/drm_dp_helper.h
Hi all,
These changes expose a function to call the WAIT_FENCES ioctl for
waiting on multiple fences at the same time. This is useful for
Vulkan.
They are mostly changes that have been in the amdgpu-pro libdrm
for a long time. I've taken the liberty to clean them up a bit
and add some missing bit
From: Nicolai Hähnle
Signed-off-by: Junwei Zhang
[v2: allow returning the first signaled fence index]
Signed-off-by: monk.liu
[v3:
- cleanup *status setting
- fix amdgpu symbols check]
Signed-off-by: Nicolai Hähnle
Reviewed-by: Christian König (v1)
Reviewed-by: Jammy Zhou (v1)
---
amdgpu/
From: Nicolai Hähnle
Signed-off-by: monk.liu
[v2: actually hook up the test case]
Signed-off-by: Nicolai Hähnle
---
tests/amdgpu/basic_tests.c | 100 +
1 file changed, 100 insertions(+)
diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_te
Hello!
I am trying to use an AMD FirePro S7150X2 with the AMDGPU driver of a Linux
4.10.9 kernel (CoreOS Container Linux) and linux-firmware
e39f0e3e6897ad865b3704f61218ae83f98a85da, but I run into the following error
after the amdgpu module is being loaded:
[ 17.692746] amdgpu :84:00.0:
Hello again!
I am trying to use a AMD FirePro S7150X2 with the AMDGPU driver of a Linux
4.10.9 kernel (CoreOS Container Linux) and linux-firmware
e39f0e3e6897ad865b3704f61218ae83f98a85da.
Since the card has no display output and I want to run remote applications
only, I would like to prevent a
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Dennis Schridde
> Sent: Thursday, April 13, 2017 10:32 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: AMDGPU without display output
>
> Hello again!
>
> I am trying to use a AMD FirePro S
Thanks, Alex!
signature.asc
Description: This is a digitally signed message part.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Dennis Schridde
> Sent: Thursday, April 13, 2017 10:18 AM
> To: amd-gfx@lists.freedesktop.org
> Subject: amdgpu :84:00.0: gpu post error! \\ Fatal error during GPU init
>
> Hello!
>
> I
+ Vilas
> -Original Message-
> From: Deucher, Alexander
> Sent: Wednesday, April 12, 2017 9:29 PM
> To: 'Michel Dänzer' ; Panariti, David
>
> Cc: amd-gfx@lists.freedesktop.org
> Subject: RE: [PATCH] drm/amdgpu: Add kernel parameter to manage
> memory error handling.
>
> > -Original M
On 13/04/17 11:38 AM, Panariti, David wrote:
+ Vilas
-Original Message-
From: Deucher, Alexander
Sent: Wednesday, April 12, 2017 9:29 PM
To: 'Michel Dänzer' ; Panariti, David
Cc: amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Add kernel parameter to manage
memory error
On 11.04.2017 00:06, Felix Kuehling wrote:
On 17-04-08 04:50 AM, Nicolai Hähnle wrote:
On 07.04.2017 22:15, Felix Kuehling wrote:
Change the wording of the CONFIG_DRM_AMDGPU_CIK option to indicate
that it's no longer experimental.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Harry Wentland
> Sent: Thursday, April 13, 2017 10:34 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Wentland, Harry
> Subject: [PATCH] drm/dp-helper: DP_TEST_MISC1 should be
> DP_TEST_MISC0
>
On Thu, Apr 13, 2017 at 6:41 PM, Nicolai Hähnle wrote:
> On 11.04.2017 00:06, Felix Kuehling wrote:
>>
>> On 17-04-08 04:50 AM, Nicolai Hähnle wrote:
>>>
>>> On 07.04.2017 22:15, Felix Kuehling wrote:
Change the wording of the CONFIG_DRM_AMDGPU_CIK option to indicate
that it's no lo
Hi!
On Donnerstag, 13. April 2017 17:30:45 CEST Deucher, Alexander wrote:
> > [ 17.692746] amdgpu :84:00.0: enabling device ( -> 0003)
> > [ 17.692940] [drm] initializing kernel modesetting (TONGA 0x1002:0x6929
> > 0x1002:0x0334 0x00).
> > [ 17.692963] [drm] register mmio base: 0xD01
The gfxv7 contains a slightly different version of cik_mqd called
bonaire_mqd. This can introduce subtle bugs if fixes are not applied in
both places.
Reviewed-by: Edward O'Callaghan
Acked-by: Christian König
Acked-by: Felix Kuehling
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amd
This is a split of patches that are ready to land from the series:
Add support for high priority scheduling in amdgpu v8
I've included Felix and Alex's feedback from the thread above. This includes:
* Separate MEC_HPD_SIZE rename into a separate patch (patch 01)
* Added a patch to fix the kgd_hq
According to comment of amdgpu_bo_reserve, amdgpu_bo_reserve
can return with -ERESTARTSYS. When this function was interrupted
by a signal, BO should not be unref. Otherwise the BO might be
released while is kmapped and pinned, or BO MIGHT be deref
multiple times, etc.
Change-Id: If76071a768950a0d3
Rename MEC_HPD_SIZE to GFXN_MEC_HPD_SIZE to clarify it is specific to a
gfx generation.
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 11 +--
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 15 +++
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 17 -
Handle HQD deactivation timeouts instead of ignoring them.
Reviewed-by: Edward O'Callaghan
Acked-by: Christian König
Acked-by: Felix Kuehling
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
The MQD programming sequence currently exists in 3 different places.
Refactor it to absorb all the duplicates.
The success path remains mostly identical except for a slightly
different order in the non-kiq case. This shouldn't matter if the HQD
is disabled.
The error handling paths have been upda
Rename straggler instances of r(adeon)dev to a(mdgpu)dev
Reviewed-by: Edward O'Callaghan
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 70 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_
Take ownership of pipe initialization away from KFD.
Note that hpd_eop_gpu_addr was already large enough to accomodate all
pipes.
Reviewed-by: Edward O'Callaghan
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/radeon/cik.c| 27
Make amdgpu the owner of all per-pipe state of the HQDs.
This change will allow us to split the queues between kfd and amdgpu
with a queue granularity instead of pipe granularity.
This patch fixes kfd allocating an HDP_EOP region for its 3 pipes which
goes unused.
v2: support for gfx9
Reviewed-
This information is already available in adev.
Reviewed-by: Edward O'Callaghan
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 12 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 12
Instead of picking an arbitrary queue for KIQ, search for one according
to policy. The queue must be unused.
Also report the KIQ as an unavailable resource to KFD.
In testing I ran into KCQ initialization issues when using pipes 2/3 of
MEC2 for the KIQ. Therefore the policy disallows grabbing one
The return value from copy_form_user is 0 for the success case.
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c
b/drivers/gpu/drm/amd/amdgp
Instead of taking the first pipe and giving the rest to kfd, take the
first 2 queues of each pipe.
Effectively, amdgpu and amdkfd own the same number of queues. But
because the queues are spread over multiple pipes the hardware will be
able to better handle concurrent compute workloads.
amdgpu go
Pipes provide better concurrency than queues, therefore we want to make
sure that apps use queues from different pipes whenever possible.
Optimize for the trivial case where an app will consume rings in order,
therefore we don't want adjacent rings to belong to the same pipe.
Reviewed-by: Edward
The assumption that we are only using the first pipe no longer holds.
Instead, calculate the queue_mask from the queue_bitmap.
Acked-by: Felix Kuehling
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 20 ++--
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 23
Update the KGD to KFD interface to allow sharing pipes with queue
granularity instead of pipe granularity.
This allows for more interesting pipe/queue splits.
v2: fix overflow check for res.queue_mask
v3: fix shift overflow when setting res.queue_mask
v4: fix comment in is_pipeline_enabled()
Rev
Previously the queue/pipe split with kfd operated with pipe
granularity. This patch allows amdgpu to take ownership of an arbitrary
set of queues.
It also consolidates the last few magic numbers in the compute
initialization process into mec_init.
v2: support for gfx9
v3: renamed AMDGPU_MAX_QUEUE
The current implementation is hardcoded to enable ME1/PIPE0 interrupts
only.
This patch allows amdgpu to enable interrupts for any pipe of ME1.
v2: added gfx9 support
v3: use soc15_grbm_select for gfx9
Acked-by: Felix Kuehling
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/gfx
Use the same gfx_*_mqd_commit function for kfd and amdgpu codepaths.
This removes the last duplicates of this programming sequence.
v2: fix cp_hqd_pq_wptr value
Reviewed-by: Edward O'Callaghan
Acked-by: Christian König
Reviewed-by: Felix Kuehling
Signed-off-by: Andres Rodriguez
---
drivers/
Forgot to mention:
* Re-ordered some patches as suggested by Felix
* Included "drm: Fix get_property logic fumble" during testing,
otherwise the system boots to a black screen.
Regards,
Andres
On 2017-04-13 05:35 PM, Andres Rodriguez wrote:
This is a split of patches that are ready to lan
Tonga based asics may experience hangs when an HQD's EOP parameters
are modified.
Workaround this HW issue by avoiding writes to these registers for
tonga asics.
Based on the following ROCm commit:
2a0fb8 - drm/amdgpu: Synchronize KFD HQD load protocol with CP scheduler
From the ROCm git reposit
Spreading the load across multiple SDMA engines can increase memory
transfer performance.
Signed-off-by: Andres Rodriguez
Reviewed-by: Nicolai Hähnle
---
drivers/gpu/drm/amd/amdgpu/amdgpu_queue_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/
Use an LRU policy to map usermode rings to HW compute queues.
Most compute clients use one queue, and usually the first queue
available. This results in poor pipe/queue work distribution when
multiple compute apps are running. In most cases pipe 0 queue 0 is
the only queue that gets used.
In orde
Add amdgpu_queue_mgr, a mechanism that allows disjointing usermode's
ring ids from the kernel's ring ids.
The queue manager maintains a per-file descriptor map of user ring ids
to amdgpu_ring pointers. Once a map is created it is permanent (this is
required to maintain FIFO execution guarantees fo
The MQD structure matches the reg layout. Take advantage of this to
simplify HQD programming.
Note that the ACTIVE field still needs to be programmed last.
Suggested-by: Felix Kuehling
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 44 +-
drivers/gp
Depending on usage patterns, the current LRU policy may create a
non-injective mapping between userspace ring ids and kernel rings.
This behaviour is undesired as apps that attempt to fill all HW blocks
would be unable to reach some of them.
This change forces the LRU policy to create bijective m
Second part of the split of the series:
Add support for high priority scheduling in amdgpu v8
These patches should be close to being good enough to land.
The first two patches are simple fixes I've ported from the ROCm branch. These
still need review.
I've fixed all of Christian's comments for p
Add a new context creation parameter to express a global context priority.
Contexts allocated with AMDGPU_CTX_PRIORITY_HIGH will receive higher
priority to schedule their work than AMDGPU_CTX_PRIORITY_NORMAL
(default) contexts.
v2: Instead of using flags, repurpose __pad
v3: Swap enum values of _
Replace adev->srbm_mutex with a spinlock adev->srbm_lock
v2: rebased on 4.12 and included gfx9
Signed-off-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 4 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v
Add an initial framework for changing the HW priorities of rings. The
framework allows requesting priority changes for the lifetime of an
amdgpu_job. After the job completes the priority will decay to the next
lowest priority for which a request is still valid.
A new ring function set_priority() c
Third part of the split of the series:
Add support for high priority scheduling in amdgpu v8
This is the part of the series that is in a bit more murky water than the rest.
Sending out this patch series mostly for completion. And maybe for discussion
purposes as well. There are still 2 issues ope
Programming CP_HQD_QUEUE_PRIORITY enables a queue to take priority over
other queues on the same pipe. Multiple queues on a pipe are timesliced
so this gives us full precedence over other queues.
Programming CP_HQD_PIPE_PRIORITY changes the SPI_ARB_PRIORITY of the
wave as follows:
0x2: CS_
PS. If you want to use X11/OGL on this no display output card, just add an
option to
the amdgpu kernel module "virtual_display=all" which will fake a display output
so that
the xserver can start with amdgpu DDX successfully. You can use remote desktop
apps
like VNC to view the X screen.
Regard
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index da4559b..4736196 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b
On 14/04/17 11:50 AM, Huang Rui wrote:
> Signed-off-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
> index da4559b..4736196 10
On 2017年04月14日 05:34, Alex Xie wrote:
According to comment of amdgpu_bo_reserve, amdgpu_bo_reserve
can return with -ERESTARTSYS. When this function was interrupted
by a signal, BO should not be unref. Otherwise the BO might be
released while is kmapped and pinned, or BO MIGHT be deref
multiple
59 matches
Mail list logo
