When send messages to hypervior, the messages format should be is
idh_request, not idh_event.
Signed-off-by: Xiangliang Yu
---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drive
Need to free mqd backup when destroying ring.
Signed-off-by: Xiangliang Yu
---
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
index 2202f02..23cf6fa 100644
--- a/drivers/gp
vi_mqd is only used by VI family but mqd_ptr is common for all
ASIC, so change the pointer to void.
Signed-off-by: Xiangliang Yu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 2 +-
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c| 26 +-
2 files changed, 18 insertions(+), 10 d
On 02/16/2017 04:46 PM, Zhang, Jerry wrote:
> Hi Edward,
>
>> Question, is this a bit premature to have a new function and struct for
>> this, could
>> it just be put in amdgpu_gfx for now or are we expecting amdgpu_gfx_cap to
>> start growing quickly with far more cap state info?
> Yes, we wil
On 02/16/2017 03:00 PM, Bridgman, John wrote:
> Any objections to authorizing Oded to post the kfdtest binary he is using to
> some public place (if not there already) so others (like Andres) can test
> changes which touch on amdkfd ?
>
> We should check it for embarrassing symbols but otherw
Hi Edward,
> Question, is this a bit premature to have a new function and struct for this,
> could
> it just be put in amdgpu_gfx for now or are we expecting amdgpu_gfx_cap to
> start growing quickly with far more cap state info?
Yes, we will add more in the future.
Ideally we'd like to add a fe
Any objections to authorizing Oded to post the kfdtest binary he is using to
some public place (if not there already) so others (like Andres) can test
changes which touch on amdkfd ?
We should check it for embarrassing symbols but otherwise it should be OK.
That said, since we are getting peri
Hi,
Question, is this a bit premature to have a new function and struct for
this, could it just be put in amdgpu_gfx for now or are we expecting
amdgpu_gfx_cap to start growing quickly with far more cap state info?
Kind Regards,
Edward.
On 02/16/2017 01:53 PM, Junwei Zhang wrote:
> Change-Id: Ib
Vulkan needs to read the gfx hw capability info via gpu info.
According to the vaule, get different performance from device to device.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
On 15/02/17 11:47 AM, Alex Deucher wrote:
> On Tue, Feb 14, 2017 at 9:30 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> The crtc_h/vdisplay fields may not match the CRTC viewport dimensions
>> with special modes such as interlaced ones.
>>
>> Fixes the HW cursor disappearing in the bottom
Change-Id: Ibf3e4dbb7deb83271adabc275c9b7a0e0652541a
Signed-off-by: Junwei Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 6 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 ++
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 6 ++
drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 6 ++
driv
On 15/02/17 06:42 PM, Christian König wrote:
>
> IOMMU might not help here, cause when it would be the GPU we would have
> made a mapping once and then the page in question is never unmapped (IIRC).
That sounds like something which should be fixed if possible.
--
Earthling Michel Dänzer
On 16/02/17 04:10 AM, Nicolai Hähnle wrote:
> From: Nicolai Hähnle
>
> Open-code the initial ttm_bo_validate call, so that we can properly
> unlock the reservation lock when it fails. Also, properly destruct
> the reservation object when the first part of TTM BO initialization
> fails.
>
> Actua
This includes shader/memory clocks, temperature, GPU load, etc.
v2: - add sub-queries for AMDPGU_INFO_GPU_SENSOR_*
- do not break the ABI
v3: - return -ENOENT when amdgpu_dpm == 0
- expose more sensor queries
v4: - s/GPU_POWER/GPU_AVG_POWER/
- improve VDDNB/VDDGFX query description
On 02/15/2017 08:15 PM, Samuel Pitoiset wrote:
This includes shader/memory clocks, temperature, GPU load, etc.
v2: - add sub-queries for AMDPGU_INFO_GPU_SENSOR_*
- do not break the ABI
v3: - return -ENOENT when amdgpu_dpm == 0
- expose more sensor queries
Signed-off-by: Samuel Pitoise
This includes shader/memory clocks, temperature, GPU load, etc.
v2: - add sub-queries for AMDPGU_INFO_GPU_SENSOR_*
- do not break the ABI
v3: - return -ENOENT when amdgpu_dpm == 0
- expose more sensor queries
Signed-off-by: Samuel Pitoiset
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c |
From: Nicolai Hähnle
As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.
Signed-off-by: Nicolai Hähnle
---
include/drm/ttm/ttm_bo_api.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/in
From: Nicolai Hähnle
Open-code the initial ttm_bo_validate call, so that we can properly
unlock the reservation lock when it fails. Also, properly destruct
the reservation object when the first part of TTM BO initialization
fails.
Actual deadlocks caused by the missing unlock should have been fi
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy locked mutex)
in amdgpu.
v2: callers of ttm_bo_init_top should use ttm_bo_unref for e
On 02/15/2017 07:34 PM, Tom St Denis wrote:
On 15/02/17 01:32 PM, Samuel Pitoiset wrote:
read_sensor() has been recently implemented for dpm based boards
which means amdgpu_sensors can now be exposed.
v2: - make sure read_sensor is not NULL on dpm chips
- keep sanity check for powerplay c
On 15/02/17 01:32 PM, Samuel Pitoiset wrote:
read_sensor() has been recently implemented for dpm based boards
which means amdgpu_sensors can now be exposed.
v2: - make sure read_sensor is not NULL on dpm chips
- keep sanity check for powerplay chips
v3: - make sure amdgpu_dpm != 0
Cc: Tom S
read_sensor() has been recently implemented for dpm based boards
which means amdgpu_sensors can now be exposed.
v2: - make sure read_sensor is not NULL on dpm chips
- keep sanity check for powerplay chips
v3: - make sure amdgpu_dpm != 0
Cc: Tom St Denis
Signed-off-by: Samuel Pitoiset
---
d
Am 15.02.2017 um 19:09 schrieb Alex Xie:
Change-Id: Iaeeb253cc5c028c93c536ee6ea08213c7fa8f299
Signed-off-by: Alex Xie
Ah, good catch. I've missed that one.
Reviewed-by: Christian König .
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
dif
On Wed, Feb 15, 2017 at 1:09 PM, Alex Xie wrote:
> Change-Id: Iaeeb253cc5c028c93c536ee6ea08213c7fa8f299
> Signed-off-by: Alex Xie
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/a
Change-Id: Iaeeb253cc5c028c93c536ee6ea08213c7fa8f299
Signed-off-by: Alex Xie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
index 51fa12f..cc389af 10064
Hi Christian,
On 15.02.2017 16:59, Christian König wrote:
Nicolai could you give that set a try?
It should fix your problems with PRT tear down on process crash.
Yes, it fixes those issues for me, thanks! The first two patches have my
R-b, for the third one I don't really understand the bug
Nicolai could you give that set a try?
It should fix your problems with PRT tear down on process crash.
Regards,
Christian.
Am 15.02.2017 um 15:57 schrieb Christian König:
From: Christian König
When two VMs stop using PRT support at the same time we might
not disable it in the right order ot
On 02/15/2017 04:01 PM, Tom St Denis wrote:
On 14/02/17 09:56 PM, Deucher, Alexander wrote:
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, February 14, 2017 9:52 PM
To: Deucher, Alexander; 'Samuel Pitoiset'; StDenis, Tom
Cc: amd-gfx@lists.freedesktop.
On 15 February 2017 at 14:47, Harry Wentland wrote:
> On 2017-02-15 06:44 AM, Emil Velikov wrote:
>>
>> On 14 February 2017 at 20:36, Harry Wentland
>> wrote:
>>>
>>> Also make the code somewhat more readable.
>>>
>> I'd suggest reaching to the team to integrate scripts/checkpatch.pl in
>> the pr
On 15.02.2017 14:35, Nicolai Hähnle wrote:
On 14.02.2017 13:51, Christian König wrote:
Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle:
On 14.02.2017 11:49, Christian König wrote:
Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_va
On 14/02/17 09:56 PM, Deucher, Alexander wrote:
-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, February 14, 2017 9:52 PM
To: Deucher, Alexander; 'Samuel Pitoiset'; StDenis, Tom
Cc: amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/amdgpu: expose amd
From: Christian König
When two VMs stop using PRT support at the same time we might
not disable it in the right order otherwise.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gp
From: Christian König
v2: new approach fixing this by registering a fence callback for
all users of the VM on teardown
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 106 +
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
2 files
From: Christian König
Don't assume kmalloc will always succeed.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
b/drivers/gpu/drm/
On 2017-02-15 06:44 AM, Emil Velikov wrote:
On 14 February 2017 at 20:36, Harry Wentland wrote:
Also make the code somewhat more readable.
I'd suggest reaching to the team to integrate scripts/checkpatch.pl in
the pre-commit hook.
It will help you improve the coding standard and, as you ment
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy l
On Wed, Feb 15, 2017 at 09:56:48AM +0100, Arnd Bergmann wrote:
> On Wed, Feb 15, 2017 at 9:30 AM, kernelci.org bot wrote:
> > bcm47xx_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches
> >
> > Errors:
> > /home/buildslave/workspace/khilman-kbuilder/next/build-mips/../net/sched/sch_
Wed, Feb 15, 2017 at 10:38:07AM CET, james.ho...@imgtec.com wrote:
>On Wed, Feb 15, 2017 at 09:56:48AM +0100, Arnd Bergmann wrote:
>> On Wed, Feb 15, 2017 at 9:30 AM, kernelci.org bot wrote:
>> > bcm47xx_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches
>> >
>> > Errors:
>> > /hom
On Wed, Feb 15, 2017 at 9:30 AM, kernelci.org bot wrote:
> next build: 208 builds: 3 failed, 205 passed, 5 errors, 23 warnings
> Errors and Warnings Detected:
>
> arm64: gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> defconfig+CONFIG_KASAN=y 4 warnings
> arm: gcc version 5.3.1 20160412 (Li
On 14.02.2017 13:51, Christian König wrote:
Am 14.02.2017 um 13:00 schrieb Nicolai Hähnle:
On 14.02.2017 11:49, Christian König wrote:
Am 14.02.2017 um 11:37 schrieb Nicolai Hähnle:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibi
On 14 February 2017 at 20:36, Harry Wentland wrote:
> Also make the code somewhat more readable.
>
I'd suggest reaching to the team to integrate scripts/checkpatch.pl in
the pre-commit hook.
It will help you improve the coding standard and, as you mentioned, it
"make[s] the code somewhat more rea
On 2017年02月15日 18:43, Nicolai Hähnle wrote:
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, wh
On 15.02.2017 04:16, zhoucm1 wrote:
On 2017年02月14日 18:37, Nicolai Hähnle wrote:
From: Nicolai Hähnle
Allow callers to opt out of calling ttm_bo_validate immediately. This
allows more flexibility in how locking of the reservation object is
done, which is needed to fix a locking bug (destroy loc
Uff, well that's quite a problem you ran into here.
IOMMU might not help here, cause when it would be the GPU we would have
made a mapping once and then the page in question is never unmapped (IIRC).
To confirm if it is really the GPU writing those bytes I would add a
trace point to amdgpu_tt
Yeah, Nicolai was faster than you.
Patch is already reviewed and should be committed.
Christian.
Am 14.02.2017 um 19:30 schrieb Felix Kuehling:
I think Nicolai beat you to this with his patch "drm/ttm: make
TTM_MAX_BO_PRIORITY unsigned".
On 17-02-14 01:03 PM, Kent Russell wrote:
Addresses t
45 matches
Mail list logo
