Change-Id: I22a7851d4a87028778dfdc18b3da2ed856a8092b
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index d0890ad..5348710 100644
Change-Id: Iab362ad196a3d515e5ac8d9a7c925b0752c96830
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 5348710..563944a 100644
--- a/drivers/g
the system will trigger BUG_ON When amdgpu_fini is called,
the IRQ source will be cleaned before IRQ uninstalled
becasue of the sequence of ip_block.
so not set irq source.
Change-Id: I64b99247c36edb84bd209905eb24b391720b4d8f
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 10
Fix issue that PSP initialization will fail if reload amdgpu module.
That's because the PSP ring must be destroyed to be ready for the
next time PSP initialization.
Changes in v2:
- Move psp_ring_destroy before all BOs free according to
Ray Huang's suggestion.
Signed-off-by: Tri
For SRIOV doesn't need clockgating, bypass it.
Signed-off-by: Xiangliang Yu
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
index f6b2329..ca77e33 100644
--- a/drivers/
For SRIOV doesn't need CG, so bypass it.
Signed-off-by: Xiangliang Yu
---
drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
index 6268451..dbfe48d 100644
--- a/drivers/
Hi,
> > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> > only format supported by bochs-drm), and we have to interpret that in
> > bigendian byte order on the host side to get a correct displa
Post-Easter ping - anybody want to give their R-b?
Thanks,
Nicolai
On 13.04.2017 16:47, Nicolai Hähnle wrote:
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 bee
Hi,
> > Quite true that this proves nothing. However one should note that
> > fbcon -> fbdev works,
>
> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API uses
> native endian packed colour values.
Same is
On Tue, 18 Apr 2017 12:00:17 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > ppc64 (big endian) virtual machine, running with qemu stdvga & bochs-drm
> > > driver. Xorg with modesetting driver uses DRM_FORMAT_XRGB (one and
> > > only format supported by bochs-drm), and we have to interpret that
On 18.04.2017 05:13, Zhang, Jerry (Junwei) wrote:
On 04/18/2017 10:47 AM, zhoucm1 wrote:
On 2017年04月18日 09:51, Zhang, Jerry (Junwei) wrote:
Anyone could help to review it?
On 04/17/2017 05:04 PM, Junwei Zhang wrote:
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
With that fixed I can read (non-cached) IBs from the libdrm test suite.
Signed-off-by: Tom St Denis
---
src/lib/read_vram.c | 47 ---
1 file changed, 32 insertions(+), 15 deletions(-)
diff --git a/src/lib/read_vram.c b/src/lib/read_vram.c
index c9811e
On 18/04/17 07:32 AM, Tom St Denis wrote:
With that fixed I can read (non-cached) IBs from the libdrm test suite.
Signed-off-by: Tom St Denis
+ pde_fields.pte_base_addr = (pde_entry & ((1ULL << 48) -
1)) & ~0xFFFULL; //pde_entry & 0xF000ULL;
In my loc
if we enable uvd dpm during boot time,
mclk will be fixed in the initially enabled level
for activity. In performance level, other leevels
can't be enabled by send the mask to SMC.
so set all mclk levels enabled.
Change-Id: Id5c795317412a8013666fa432426d2713a27a2f8
Signed-off-by: Rex Zhu
---
dri
On Freitag, 14. April 2017 03:50:30 CEST Yu, Qiang wrote:
> 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
Hello Alex et al.!
On Donnerstag, 13. April 2017 22:16:50 CEST Dennis Schridde wrote:
> 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
>
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Trigger Huang
> Sent: Monday, April 17, 2017 10:14 PM
> To: amd-gfx@lists.freedesktop.org
> Cc: Huang, Trigger
> Subject: [PATCH] drm/amdgpu: Fix module unload hang by KIQ on Vega10
>
> Apply
Hi,
> > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest
> > here, it drives the qemu stdvga with offb, not bochs-drm.
>
> I suppose this proves the virtual machine itself is correct about
> framebuffer endianess? Except you are running it on a little-endian
> host machine
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Tuesday, April 18, 2017 3:02 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH 1/3] drm/amdgpu: fix typo in dmesg in
> gfx_v8_0_kiq_kcq_disable.
>
> Chan
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Tuesday, April 18, 2017 3:02 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH 2/3] drm/amdgpu: delete reduant kiq irq funcs type check in
> gfx8.
>
> Ch
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Tuesday, April 18, 2017 3:02 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH 3/3] drm/amdgpu: not set KIQ IRQ source in gfx_v9.
>
> the system will tri
Signed-off-by: Tom St Denis
---
src/lib/ring_decode.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/lib/ring_decode.c b/src/lib/ring_decode.c
index 372bb43595b8..48d840643bf9 100644
--- a/src/lib/ring_decode.c
+++ b/src/lib/ring_decode.c
@@ -379,6 +379,19 @@ static void p
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang Yu
> Sent: Tuesday, April 18, 2017 3:38 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang
> Subject: [PATCH 2/2] drm/amdgpu/gfx9: bypass clockgating setting
>
> For SRIOV
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Xiangliang Yu
> Sent: Tuesday, April 18, 2017 3:38 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Yu, Xiangliang
> Subject: [PATCH 1/2] drm/amdgpu/mmhub_v1: bypass clockgating setting
>
> For S
On Tue, 18 Apr 2017 15:39:53 +0200
Gerd Hoffmann wrote:
> Hi,
>
> > > Historical note: RHEL-6.9 (gnome 2) works fine. Not of much interest
> > > here, it drives the qemu stdvga with offb, not bochs-drm.
> >
> > I suppose this proves the virtual machine itself is correct about
> > framebuf
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Rex Zhu
> Sent: Tuesday, April 18, 2017 7:35 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Zhu, Rex
> Subject: [PATCH] drm/amdgpu: fix memory clock can't switch on CI.
>
> if we enable uvd dpm
I think no need to check function type.
Best Regards
Rex
From: amd-gfx on behalf of Deucher,
Alexander
Sent: Tuesday, April 18, 2017 9:33:58 PM
To: Huang, Trigger; amd-gfx@lists.freedesktop.org
Cc: Huang, Trigger
Subject: RE: [PATCH] drm/amdgpu: Fix module unloa
On Tue, Apr 18, 2017 at 6:11 AM, Nicolai Hähnle wrote:
> Post-Easter ping - anybody want to give their R-b?
For the series:
Reviewed-by: Alex Deucher
>
> Thanks,
> Nicolai
>
> On 13.04.2017 16:47, Nicolai Hähnle wrote:
>>
>> Hi all,
>>
>> These changes expose a function to call the WAIT_FENCES
2017-04-17 Sumit Semwal :
> On 17 April 2017 at 18:43, Gustavo Padovan wrote:
> > 2017-04-13 Dave Airlie :
> >
> >> From: Dave Airlie
> >>
> >> sync_file uses the reference count of the file, the internal
> >> kref was never getting moved past 1.
> >>
> >> We can reintroduce this if we decide we
Hi David,
When amdgpu_bo_reserve return errors, we cannot release the BO. This is not a
memory leak. General speaking, memory leak is unnoticed and unintentional.
The caller of function amdgpu_vram_scratch_fini ignores the return error
value...
The "memory leak" is not caused by my patch. I
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
Change-Id: Ie5a6ba045bde07ccd35b27690709ad1670139447
Signed-off-by: Alex Xie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 79b5fda..7e43f63 100644
On 04/14/2017 12:47 AM, Nicolai Hähnle wrote:
> 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-
KIQ is the Kernel Interface Queue for managing the MEC. Rather than setting
up rings via direct MMIO of ring registers, the rings are configured via
special packets sent to the KIQ. The allows the MEC to better manage shared
resources and certain power events. It also reduces the code paths in th
Thanks. Updated patch sent out.
Alex
From: Zhu, Rex
Sent: Tuesday, April 18, 2017 2:11 AM
To: Alex Deucher; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH 12/12] drm/amdgpu/gfx9: Switch baremetal to use KIQ for
compute ring management. (v3)
+static int gfx_v9_0_kiq_k
Be consistent and use the canonical form while sanity checking
null pointers, also combine a few branches for brevity.
Signed-off-by: Edward O'Callaghan
---
amdgpu/amdgpu_bo.c | 2 +-
amdgpu/amdgpu_cs.c | 36 +++-
amdgpu/amdgpu_gpu_info.c | 5 +++--
On 2017-04-17 06:00 PM, Alex Deucher wrote:
KIQ is the Kernel Interface Queue for managing the MEC. Rather than setting
up rings via direct MMIO of ring registers, the rings are configured via
special packets sent to the KIQ. The allows the MEC to better manage shared
resources and certain po
s/mpd/mqd in subject
On 2017-04-17 06:00 PM, Alex Deucher wrote:
Using the wrong macro for soc15 register access.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
One comment and two typo nitpicks on the emails.
With those fixed the series is:
Reviewed-by: Andres Rodriguez
Regards,
Andres
On 2017-04-17 06:00 PM, Alex Deucher wrote:
Basically a port of the recent KIQ work for gfx8 to gfx9. A couple
of general bug fixes as well. Can someone with a vega
On 18/04/17 01:00 PM, Andres Rodriguez wrote:
+static int gfx_v9_0_kiq_kcq_disable(struct amdgpu_device *adev)
+{
+struct amdgpu_ring *kiq_ring = &adev->gfx.kiq.ring;
+uint32_t scratch, tmp = 0;
+int r, i;
+
+r = amdgpu_gfx_scratch_get(adev, &scratch);
+if (r) {
+DRM_
Hi AlexBin,
No, David is right. This is a very common coding pattern in the kernel
module.
Freeing up a BO while there still exists a kernel mapping is perfectly
ok, the mapping will just be released a bit later on.
So this code is actually perfectly ok and just an optimization, but your
p
Am 18.04.2017 um 17:43 schrieb Alex Xie:
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
Hi Christian,
Would you point out where/when will kunmap happen for this BO when release? It
must be somewhere in some function calls.
I checked before I asked for review. But I did not see such obvious kunmap
function call.
If so, there should be a comment in function amdgpu_vram_scratch_f
On 18.04.2017 17:47, Edward O'Callaghan wrote:
On 04/14/2017 12:47 AM, Nicolai Hähnle wrote:
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-b
Hi Christian,
Have you found how/where/when? When you said "mapping will just be released a
bit later on", you must know the answer.
It is difficult to prove something does not exist. Anyway, I will give it a try
to prove such "later on" does not exist.
Function ttm_bo_kunmap is the only funct
On 14 April 2017 at 19:45, Chris Wilson wrote:
> On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote:
>> This set of sync object patches should address most of the issues
>> raised in review.
>>
>> The major changes:
>> Race on destroy should be gone,
>> Documentation fixups
>> amdgpu inte
With the new patch-set, I get the following error (on Kaveri), when
running KFDEventTest.SignalEvent (There are some other tests who
produce same result e.g. KFDQMTest.OverSubscribeCpQueues):
dmesg:
[ 276.528643] kfd: qcm fence wait loop timeout expired
[ 276.528649] kfd: the cp might be in an u
On Wed, Apr 19, 2017 at 05:34:52AM +1000, Dave Airlie wrote:
> On 14 April 2017 at 19:45, Chris Wilson wrote:
> > On Tue, Apr 11, 2017 at 01:22:12PM +1000, Dave Airlie wrote:
> >> This set of sync object patches should address most of the issues
> >> raised in review.
> >>
> >> The major changes:
Hi,
> Right. Very nice if we can trust the virtual machine at least getting
> things right, gives some chance for people to test anything. Except...
> that's a question of what kind of hardware the virtual machine
> emulates. The display device defines what endianess it uses on
> framebuffers, n
A few thoughts (from the anv perspective) that I put on IRC but may be
better in a mail. In no particular order:
1. Having the fd exported from a syncobj be a valid sync_file seems like a
fairly pointless feature to me. If we can make things more sane by
throwing that out, I'm all for it.
2.
On 19 April 2017 at 07:55, Jason Ekstrand wrote:
> A few thoughts (from the anv perspective) that I put on IRC but may be
> better in a mail. In no particular order:
>
> 1. Having the fd exported from a syncobj be a valid sync_file seems like a
> fairly pointless feature to me. If we can make t
On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> Quite true that this proves nothing. However one should note that
>>> fbcon -> fbdev works,
>>
>> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
>> e.g. DRM_FORMAT_XRGB for depth/bpp 24/32, and the fbdev API use
On 04/18/2017 07:25 PM, Nicolai Hähnle wrote:
On 18.04.2017 05:13, Zhang, Jerry (Junwei) wrote:
On 04/18/2017 10:47 AM, zhoucm1 wrote:
On 2017年04月18日 09:51, Zhang, Jerry (Junwei) wrote:
Anyone could help to review it?
On 04/17/2017 05:04 PM, Junwei Zhang wrote:
Signed-off-by: Junwei Zhang
v2: unify PRT bit for all ASICs
Signed-off-by: Junwei Zhang
Acked-by: David Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 5 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 3 ++-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers
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
V3 updates:
* Fixed kfd set resources grabbing MEC1 queues
* kfdtest now passes on Kaveri with the amdgpu or radeon driver
V2 updates:
* Fixed wrong HPD offset in compute_pipe_init for gfx7
* Fixed compute_pipe_init using wrong ME for gfx7
This is a split of patches that are ready to land fr
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
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
v3: fix gf
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
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_
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
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
The return value from copy_form_user is 0 for the success case.
Reviewed-by: Felix Kuehling
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
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
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()
v5:
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
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/
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 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
---
drivers/gpu/drm/drm_property.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 3feef06..3e88fa2 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -459,41 +459,41 @@ int d
Ooops, please ignore this patch. It was just for local testing.
Regards,
Andres
On Apr 18, 2017 10:36 PM, "Andres Rodriguez" wrote:
> ---
> drivers/gpu/drm/drm_property.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/d
On 04/19/2017 04:28 AM, Nicolai Hähnle wrote:
> On 18.04.2017 17:47, Edward O'Callaghan wrote:
>> On 04/14/2017 12:47 AM, Nicolai Hähnle wrote:
>>> From: Nicolai Hähnle
>>>
>>> Signed-off-by: Junwei Zhang
>>> [v2: allow returning the first signaled fence index]
>>> Signed-off-by: monk.liu
>>>
On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote:
> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
>> Hi,
>>
Quite true that this proves nothing. However one should note that
fbcon -> fbdev works,
>>>
>>> BTW, this supports Gerd's patch, since the KMS fbdev emulation code uses
>>> e.g.
On Tue, Apr 18, 2017 at 11:19 PM, Ilia Mirkin wrote:
> On Tue, Apr 18, 2017 at 9:01 PM, Michel Dänzer wrote:
>> On 18/04/17 07:14 PM, Gerd Hoffmann wrote:
>>> Hi,
>>>
> Quite true that this proves nothing. However one should note that
> fbcon -> fbdev works,
BTW, this supports
Change-Id: If0474e24e14d237d2d55731871c5ceb11e5a3601
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drive
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 04/19/2017 11:50 AM, Chunming Zhou wrote:
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 del
Hi AlexBin,
the answer is ttm_bo_kunmap isn't called at all and yes in the case of
an iomap we leak the address space reserved.
But that is completely harmless on a 64bit system compared to leaking
the memory backing the address space.
Using amdgpu_bo_free_kernel() instead of openly coding
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
gtt_mgr_alloc is called by many places in local driver, while
gtt_mgr_new is called by get_node in ttm.
NAK, that can lead to over allocating the address space and we can't
handle that during suspend/resume.
Regards,
Christian.
Change-Id: Ia5a
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
Change-Id: Ifea42c8ae2206143d7e22b35eea537ba9e928fe8
Signed-off-by: Chunming Zhou
Nice idea for a cleanup, but please do even a few more things:
1. Rebase on not moving the statistics from mgr_new to mgr_alloc.
2. Joing mgr->available and adev->gtt
On 18.04.2017 18:20, Edward O'Callaghan wrote:
Be consistent and use the canonical form while sanity checking
null pointers, also combine a few branches for brevity.
Signed-off-by: Edward O'Callaghan
Sure, it's a good cleanup. Feel free to add the corresponding change
also to amdgpu_cs_wait_
On 2017年04月19日 14:38, Christian König wrote:
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
gtt_mgr_alloc is called by many places in local driver, while
gtt_mgr_new is called by get_node in ttm.
NAK, that can lead to over allocating the address space and we can't
handle that during suspend/
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
Change-Id: If0474e24e14d237d2d55731871c5ceb11e5a3601
Signed-off-by: Chunming Zhou
One nit pick below.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 7 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4
2 files changed, 11 inser
Am 19.04.2017 um 08:52 schrieb zhoucm1:
On 2017年04月19日 14:38, Christian König wrote:
Am 19.04.2017 um 05:50 schrieb Chunming Zhou:
gtt_mgr_alloc is called by many places in local driver, while
gtt_mgr_new is called by get_node in ttm.
NAK, that can lead to over allocating the address space
88 matches
Mail list logo
