Does it means we have to submit command to trigger the semaphore wait/signal?
Best Regards,
David
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Dave
Airlie
Sent: Tuesday, April 11, 2017 11:22 AM
To: amd-gfx@lists.freedesktop.org; dri-de...@l
From: Dave Airlie
This patch allows the underlying fence in a sync_file to be changed
or set to NULL. This isn't currently required but for Vulkan
semaphores we need to be able to swap and reset the fence.
In order to faciliate this, it uses rcu to protect the fence,
along with a new mutex. The
From: Dave Airlie
This object can be used to implement the Vulkan semaphores.
The object behaviour differs from fence, in that you can
replace the underlying fence, and you cannot merge semaphores.
v2: change replace fence API to have a return value,
don't allow polling on semaphore objects,
do
From: Dave Airlie
This just adds two helper interfaces to bridge the gap from
drivers to sync_file for the semaphore objects.
These will be used by the amdgpu driver.
v2: drop one of the APIs and replace with a fence
lookup to make the amdgpu api more robust.
Signed-off-by: Dave Airlie
---
d
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add wait and signal sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for semaphore waiting, one for semaphore
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1 file change
From: Dave Airlie
Sync objects are new toplevel drm object, that have the same
semantics as sync_file objects, but without requiring an fd
to be consumed to support them.
This patch just enables the DRM interface to create these
objects, it doesn't actually provide any semaphore objects
or new f
Okay another day, another sync object patchset.
In my drm-syncobj branch.
This round should:
a) address the amdgpu CS ERESTARTSYS failure case, I've reworked
the sync_file/syncobj/amdgpu bits to have a lookup and just replace
in separate phases and just do the wait lookup and sync, then later
rep
From: Dave Airlie
These are just alloc and fdget interfaces needed by the drm sync
objects code.
Reviewed-by: Christian König
Reviewed-by: Daniel Vetter
Signed-off-by: Dave Airlie
---
drivers/dma-buf/sync_file.c | 21 +++--
include/linux/sync_file.h | 3 ++-
2 files change
From: Dave Airlie
This allows us to create sync files with different semantics,
and clearly define the interoperation between them it also
provides flags to allow for tweaks on those semantics.
This provides a validation interface for drivers that accept
types from userspace so they can return E
=> we'd really want to pass a semaphore between the X server and client to do
this perfectly.
Do you means that you want X to signal the semaphore that waited by client,
through special version of xsync?
We use pretty complex tricks to build synchronization logic upon the event and
shm fence.
B
On 12 April 2017 at 13:34, Mao, David wrote:
> My point is it is reasonable to split the semaphore signal/wait with the
> command submission.
> For the signal ioctl, we could just pick the last fence in the same schedule
> context, and we don't need to ask for a explicit flush or a dummy submiss
My point is it is reasonable to split the semaphore signal/wait with the
command submission.
For the signal ioctl, we could just pick the last fence in the same schedule
context, and we don't need to ask for a explicit flush or a dummy submission
trick.
The spec guarantee the signal always come
But how to handle the semaphore wait in the vkQueuePresentkHR?
Thanks.
Best Regards,
David
-Original Message-
From: Dave Airlie [mailto:airl...@gmail.com]
Sent: Wednesday, April 12, 2017 10:44 AM
To: Mao, David
Cc: amd-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject:
On 12 April 2017 at 12:49, Mao, David wrote:
> But how to handle the semaphore wait in the vkQueuePresentkHR?
The problem here is that really we'd want the presenting process to
do the signal once it submits the work for actual presentations (be
that the X server DDX or whatever).
However that i
On 12 April 2017 at 12:36, Mao, David wrote:
> Does it means we have to submit command to trigger the semaphore wait/signal?
Yes, but I think that should be fine, we need to submit a job to the
scheduler to
get the waits to happen or to have a fence to fill into the signals.
Dave.
__
On 11/04/17 10:38 AM, Michel Dänzer wrote:
> On 11/04/17 08:21 AM, Felix Kuehling wrote:
>> Provide convenient compile time and boot time options for selecting
>> CIK ASIC support in either or both drivers.
>>
>> v2: git add missing files
>
> [...]
>
>> diff --git a/drivers/gpu/drm/Kconfig b/driv
On 11 April 2017 at 17:50, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> This object can be used to implement the Vulkan semaphores.
>>
>> The object behaviour differs from fence, in that you can
>> replace the underlying fence, and
On 11 April 2017 at 22:42, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:20PM +1000, Dave Airlie wrote:
>> +static int amdgpu_sem_lookup_and_sync(struct amdgpu_cs_parser *p,
>> + uint32_t handle)
>> +{
>> + int r;
>> + struct dma_fence *old_fence;
>>
On 12/04/17 01:13 AM, Felix Kuehling wrote:
> On 17-04-10 09:39 PM, Michel Dänzer wrote:
>> On 11/04/17 03:13 AM, Felix Kuehling wrote:
>>> On 17-04-09 09:28 PM, Michel Dänzer wrote:
On 10/04/17 09:56 AM, Michel Dänzer wrote:
> On 08/04/17 05:15 AM, Felix Kuehling wrote:
>> Advertise C
On 12/04/17 01:05 AM, Felix Kuehling wrote:
> On 17-04-11 12:01 AM, Michel Dänzer wrote:
>> One issue with this per-driver enable_cik option is that if the user
>> only enables it in the driver where it's disabled by default, without
>> also disabling it in the driver where it's enabled by default,
> > -Original Message-
> > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Xiangliang Yu
> > Sent: Tuesday, April 11, 2017 3:31 AM
> > To: amd-gfx@lists.freedesktop.org
> > Cc: Min, Frank; Yu, Xiangliang
> > Subject: [PATCH 2/3] drm/amdgpu/vce4: workaround VCE
Hi Dave,
Please send patches inline instead of as attachments, ideally using git
send-email.
> @@ -212,6 +213,9 @@ module_param_named(cg_mask, amdgpu_cg_mask, uint, 0444);
> MODULE_PARM_DESC(pg_mask, "Powergating flags mask (0 = disable power
> gating)");
> module_param_named(pg_mask, amdgp
Currently allows Carrizo EDC to be turned off.
davep
0001-drm-amdgpu-Add-kernel-parameter-to-manage-memory-err.patch
Description: 0001-drm-amdgpu-Add-kernel-parameter-to-manage-memory-err.patch
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
htt
On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote:
> 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 cha
I replied to patch 5 with an observation. But I think that code was
broken before your change.
The order of patches 7 and 8 should be reversed. Otherwise you break
radeon before you fix it.
See my comments on patch 9, 15 and 16 in separate emails. With those
comments addressed:
1-4, 10, 13-14 ar
What about GFX9?
See one more comment inline [FK].
On 17-04-06 02:21 AM, Andres Rodriguez wrote:
> 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 s
See comment inline [FK].
On 17-04-06 02:21 AM, Andres Rodriguez wrote:
> 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 whe
On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote:
> Replace adev->srbm_mutex with a spinlock adev->srbm_lock
>
> v2: rebased on 4.12 and included gfx9
> Signed-off-by: Andres Rodriguez
Maybe move this one up to the front of the series so it can be applied now?
Alex
> ---
> drivers/gpu/
On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote:
> 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 matte
On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote:
> 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 matte
I'm not sure if the order matters, but it seems like it makes
more sense to set this after the range is programmed.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
On Thu, Apr 6, 2017 at 2:21 AM, Andres Rodriguez wrote:
> The CP_MEC_DOORBELL_RANGE_* and CP_PQ_STATUS.DOORBELL_ENABLE registers
> are not HQD specific.
>
> They only need to be set once if at least 1 pipe requested doorbell
> support.
>
> v2: move doorbell_enable to amdgpu_gfx instead of amdgpu_d
Comments inline.
On 17-04-06 02:21 AM, Andres Rodriguez wrote:
> 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
> initializatio
The amdgpu_amdkfd code you're modifying has changed a lot on the KFD
branch. I'm not sure it's worth fixing on the amdgpu branch. We'll
largely replace it when we upstream KFD changes.
I spotted an obvious bug in your patch, but it was also broken before.
See inline [FK].
On 17-04-06 02:21 AM, A
Hello team,
As one of AMD A10-7400P with R7 M265DX(Kaveri) + R5 M230 (Hainan) hybrid
laptop, will it possible to enable support for SI with that mechanism
now that amdgpu drive is running fine?
00:01.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] Kaveri [Radeon R6 Graphics] (p
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Christian König
> Sent: Tuesday, April 11, 2017 1:22 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: jan.burgme...@unicon-software.com
> Subject: [PATCH] drm/radeon: force the UVD DPB into VRAM a
On 04/11/2017 12:16 PM, Christian König wrote:
Am 11.04.2017 um 18:05 schrieb Felix Kuehling:
On 17-04-11 12:01 AM, Michel Dänzer wrote:
One issue with this per-driver enable_cik option is that if the user
only enables it in the driver where it's disabled by default, without
also disabling it
From: Christian König
Seems to be mandatory for WMV playback.
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=100510
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_cs.c | 10 ++
drivers/gpu/drm/radeon/radeon_uvd.c | 2 +-
2 files changed, 7 insertions(+), 5 dele
The syntax is fairly simple but the parser isn't really robust so don't
feed it garbage. It will happily eat whitespace between tokens so you
can indent however you want.
Each command starts with "add", "edit", or "del" and then "bit" or "reg"
followed by a path and then an address or start/stop
On 17-04-10 09:39 PM, Michel Dänzer wrote:
> On 11/04/17 03:13 AM, Felix Kuehling wrote:
>> On 17-04-09 09:28 PM, Michel Dänzer wrote:
>>> On 10/04/17 09:56 AM, Michel Dänzer wrote:
On 08/04/17 05:15 AM, Felix Kuehling wrote:
> Advertise CIK PCI IDs only when they are not supported by amdg
Am 11.04.2017 um 18:05 schrieb Felix Kuehling:
On 17-04-11 12:01 AM, Michel Dänzer wrote:
One issue with this per-driver enable_cik option is that if the user
only enables it in the driver where it's disabled by default, without
also disabling it in the driver where it's enabled by default, it's
On 17-04-11 12:01 AM, Michel Dänzer wrote:
> One issue with this per-driver enable_cik option is that if the user
> only enables it in the driver where it's disabled by default, without
> also disabling it in the driver where it's enabled by default, it's back
> to the current situation where both
On Tue, Apr 11, 2017 at 4:44 AM, Christian König
wrote:
> From: Christian König
>
> David suggested this a long time ago, instead of checking
> each ring just walk over all the VMIDs in reverse LRU order.
>
> Signed-off-by: Christian König
> Reviewed-by: Andres Rodriguez
Reviewed-by: Alex Deuc
On 17-04-10 09:42 PM, Michel Dänzer wrote:
> On 11/04/17 08:29 AM, Felix Kuehling wrote:
>> I tested this with Hawaii on the KFD branch and
>> DRM_CIK_BOTH_DEFAULT_AMDGPU. Both modules get loaded, but radeon doesn't
>> initialize the device. Amdgpu works with kfdtest.
> Did radeon print the "CIK su
Am 24.03.2017 um 16:47 schrieb Bjorn Helgaas:
On Mon, Mar 13, 2017 at 01:41:35PM +0100, Christian König wrote:
From: Christian König
Most BIOS don't enable this because of compatibility reasons.
Can you give any more details here? Without more hints, it's hard to
know whether any of the comp
Hi Bjorn,
first of all sorry for the delay, had been busy with other stuff in the
last few weeks.
Am 24.03.2017 um 22:34 schrieb Bjorn Helgaas:
+ release_child_resources(res);
Doesn't this recursively release *all* child resources? There could
be BARs from several devi
On Tue, Apr 11, 2017 at 4:44 AM, Christian König
wrote:
> From: Christian König
>
> Trace on which hub we are doing the flush.
>
> v2: fix typo in commit message
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20 --
On Tue, Apr 11, 2017 at 4:44 AM, Christian König
wrote:
> From: Christian König
>
> Trace on which VMHUB we assigned an VMID.
>
> Signed-off-by: Christian König
> Reviewed-by: Andres Rodriguez
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 17 ++---
On Tue, Apr 11, 2017 at 4:44 AM, Christian König
wrote:
> From: Christian König
>
> For Vega10 we have 18 VM invalidation engines for each VMHUB.
>
> Start to assign them manually to the rings.
>
> v2: add a BUG_ON if we use to many engines
>
> Signed-off-by: Christian König
> Reviewed-by: Alex
On Tue, Apr 11, 2017 at 4:44 AM, Christian König
wrote:
> From: Christian König
>
> This way GFX and MM won't fight for VMIDs any more.
>
> Initially disabled since we need to stop flushing all HUBS
> at the same time as well.
>
> Signed-off-by: Christian König
> Reviewed-by: Andres Rodriguez
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Tuesday, April 11, 2017 9:52 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH] drm/amdgpu: set cpg doorbeel for fiji and polaris.
Good catch!
Typo in th
add set_doorbell functions for mec and cpg.
Change-Id: Ie696798633bc1d511a6526b2113907b70a92b303
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 82 ++-
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/g
On 2017-04-07 12:11 PM, Christian König wrote:
From: Christian König
Trace on which VMHUB we assigned an VMID.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 17 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
2 files changed, 11 inserti
On 2017-04-11 04:45 AM, Christian König wrote:
Am 07.04.2017 um 18:52 schrieb Andres Rodriguez:
s/druing/during in subject
On 2017-04-07 12:11 PM, Christian König wrote:
From: Christian König
Trace on which hub we are doing the flush.
Signed-off-by: Christian König
---
drivers/gpu/drm
On Tue, Apr 11, 2017 at 3:31 AM, Pekka Paalanen wrote:
> On Mon, 10 Apr 2017 12:10:14 -0400
> Ilia Mirkin wrote:
>
>> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote:
>
>> > I also wonder if a real BE machine could have different results than
>> > the virtual machine.
>>
>> I have a PPC G
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang Yu
> Sent: Tuesday, April 11, 2017 3:31 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Min, Frank; Yu, Xiangliang
> Subject: [PATCH 2/3] drm/amdgpu/vce4: workaround VCE ring test slow
On Tue, Apr 11, 2017 at 01:22:20PM +1000, Dave Airlie wrote:
> +static int amdgpu_sem_lookup_and_sync(struct amdgpu_cs_parser *p,
> + uint32_t handle)
> +{
> + int r;
> + struct dma_fence *old_fence;
> +
> + r = drm_syncobj_swap_fences(p->filp, handle,
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 machines that we should avoid breaking?
For the virtual machine use case the b
Am 11.04.2017 um 11:45 schrieb Huang Rui:
On Tue, Apr 11, 2017 at 02:53:27PM +0800, Christian König wrote:
Am 11.04.2017 um 04:58 schrieb Huang Rui:
This patch fixes the case when buffer funcs is empty and bo evict is
executing. It must double check buffer funcs, otherwise, a NULL
pointer deref
On Tue, Apr 11, 2017 at 02:53:27PM +0800, Christian König wrote:
> Am 11.04.2017 um 04:58 schrieb Huang Rui:
> > This patch fixes the case when buffer funcs is empty and bo evict is
> > executing. It must double check buffer funcs, otherwise, a NULL
> > pointer dereference kernel panic will be enco
Am 13.03.2017 um 17:49 schrieb Andy Shevchenko:
On Mon, Mar 13, 2017 at 2:41 PM, Christian König
wrote:
Most BIOS don't enable this because of compatibility reasons.
Manually enable a 64bit BAR of 64GB size so that we have
enough room for PCI devices.
+static void pci_amd_enable_64bit_bar(str
Sorry for the delayed response, have been busy with other stuff recently.
Am 13.03.2017 um 17:43 schrieb Andy Shevchenko:
v2: rebase on changes in rbar support
This kind of comments usually goes after --- delimiter below.
That would remove it from the commit message which I don't want.
+
On 2017年04月11日 16:45, Christian König wrote:
Am 10.04.2017 um 05:41 schrieb zhoucm1:
On 2017年04月08日 00:59, Andres Rodriguez wrote:
Some minor nitpicks as replies to the other emails.
With those fixed, this series is:
Looks good to me.
Does that mean I can stitch your rb on it and commit
Am 10.04.2017 um 05:41 schrieb zhoucm1:
On 2017年04月08日 00:59, Andres Rodriguez wrote:
Some minor nitpicks as replies to the other emails.
With those fixed, this series is:
Looks good to me.
Does that mean I can stitch your rb on it and commit it?
Thanks,
Christian.
David
Reviewed-by:
Support for deleting entries will be added later. The syntax is fairly
simple but the parser isn't really robust so don't feed it garbage. It
will happily eat whitespace between tokens so you can indent however you
want.
Each command starts with "add" or "edit" and then "bit" or "reg"
followed b
Am 07.04.2017 um 18:52 schrieb Andres Rodriguez:
s/druing/during in subject
On 2017-04-07 12:11 PM, Christian König wrote:
From: Christian König
Trace on which hub we are doing the flush.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20 --
From: Christian König
For Vega10 we have 18 VM invalidation engines for each VMHUB.
Start to assign them manually to the rings.
v2: add a BUG_ON if we use to many engines
Signed-off-by: Christian König
Reviewed-by: Alex Deucher (v1)
Reviewed-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amd
From: Christian König
Enable concurrent VM flushes for Vega10.
Signed-off-by: Christian König
Acked-by: Alex Deucher
Reviewed-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 50 +++---
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git
From: Christian König
David suggested this a long time ago, instead of checking
each ring just walk over all the VMIDs in reverse LRU order.
Signed-off-by: Christian König
Reviewed-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +++--
drivers/gpu/drm/amd/amdg
From: Christian König
Trace on which VMHUB we assigned an VMID.
Signed-off-by: Christian König
Reviewed-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 17 ++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
2 files changed, 11 insertions(+), 8 deletions(
From: Christian König
Drop invalidating both hubs from each engine.
v2: don't use hardcoded values
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 +-
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 36 +--
From: Christian König
Trace on which hub we are doing the flush.
v2: fix typo in commit message
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 20
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c| 2 +-
2 files changed, 13 insertions(+), 9 delet
From: Christian König
This way GFX and MM won't fight for VMIDs any more.
Initially disabled since we need to stop flushing all HUBS
at the same time as well.
Signed-off-by: Christian König
Reviewed-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 1 -
drivers/gpu/drm/a
From: Christian König
Add the info which ring belonging to which VMHUB.
Signed-off-by: Christian König
Reviewed-by: Alex Deucher
Reviewed-by: Andres Rodriguez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 1 +
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c| 3 +++
drivers/gpu/drm/amd/amdgpu/sdma
On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This object can be used to implement the Vulkan semaphores.
>
> The object behaviour differs from fence, in that you can
> replace the underlying fence, and you cannot merge semaphores.
>
> Signed-off-by: Dave
Am 11.04.2017 um 09:30 schrieb Xiangliang Yu:
Update the initialization sequence of VCE to make VCE work.
Signed-off-by: Frank Min
Acked-by: Christian König for the whole series.
---
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
di
Add VCE ring test slow workaround for SRIOV.
Signed-off-by: Frank Min
Signed-off-by: Xiangliang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
b/drivers/gpu/drm/amd/amdgpu/amd
Now VCE block can work for SRIOV, enable ring & ib test.
Signed-off-by: Frank Min
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index cdff938..6ccd244 10064
On Mon, 10 Apr 2017 12:10:14 -0400
Ilia Mirkin wrote:
> On Mon, Apr 10, 2017 at 11:09 AM, Pekka Paalanen wrote:
> > I also wonder if a real BE machine could have different results than
> > the virtual machine.
>
> I have a PPC G5 with an AGP GeForce FX 5200 that I can test things on,
> if ne
Update the initialization sequence of VCE to make VCE work.
Signed-off-by: Frank Min
---
drivers/gpu/drm/amd/amdgpu/vce_v4_0.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
b/drivers/gpu/drm/amd/amdgpu/vce_v4_0.c
index 8dde83f
81 matches
Mail list logo
