regresstion issue.
caused by "f12f9f5e5d455edebc01"
forget to set start_thermal_controller function point.
Change-Id: Idcb127daccb96a6b30f8f83e8b1bd65b8f872f55
Signed-off-by: Rex Zhu
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 1 +
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_therma
On Wed, Oct 18, 2017 at 5:55 AM, Felix Kuehling wrote:
> Pass unmap filter parameters directly to execute_queues_cpsch, same
> as unmap_queues_cpsch.
>
> Signed-off-by: Felix Kuehling
> ---
> .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 32
> +++---
> 1 file changed, 16
Pass unmap filter parameters directly to execute_queues_cpsch, same
as unmap_queues_cpsch.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 32 +++---
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/
Hi all,
Could someone review this patch?
—
Sincerely Yours,
Pixel
On 17/10/2017, 4:06 PM, "amd-gfx on behalf of Ding, Pixel"
wrote:
>you can see the difference of function amdgpu_need_post. Generally speaking,
>there were 2 functions to check VBIOS posting, one considers VF and passt
On Mon, Oct 16, 2017 at 11:26 PM, Evan Quan wrote:
> Change-Id: If3b79428b32ffab57b4e75f9c20c2b2d7e600223
> Signed-off-by: Evan Quan
Please include a better commit message. Something like:
Prevent a a possible buffer overflow when updating the ring buffer by
bounds checking the command frame ag
The patch
drm/amdgpu Moving amdgpu asic types to a separate file
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and
The patch
ASoC: AMD: Audio buffer related changes for Stoney
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
ASoC: AMD: disabling memory gating in stoney platform
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and s
The patch
ASoC: AMD: Add machine driver for cz rt5650
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Lin
The patch
ASoC: AMD: DMA driver changes for Stoney Platform
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
yeah,
RB-by: Monk Liu
From: Ding, Pixel
Sent: Tuesday, October 17, 2017 4:06 PM
To: Liu, Monk; amd-gfx@lists.freedesktop.org; Koenig, Christian
Cc: Li, Bingley; Sun, Gary
Subject: Re: [PATCH 1/3] drm/amdgpu: always consider virualised device for
checking post
From: pding
Register accessing is performed when IRQ is disabled. Never sleep in
this function.
Known issue: dead sleep in many use cases of index/data registers.
v2: wrap polling fence functions. don't trigger IRQ for polling in
case of wrongly fence signal.
v3: handle wrap round gracefully.
On 2017-10-17 06:05 PM, Andrey Grodzovsky wrote:
>
>
> On 10/17/2017 05:11 PM, Tom St Denis wrote:
>> I'm ok with not pushing my commit and simply adding an else branch that sets
>> the pointer to NULL.
>>
>> (maybe put a WARN_ON to give context?)
>
> Seems reasonable to me.
> Harry ?
>
Sure.
On 2017-10-17 05:43 PM, Tom St Denis wrote:
> On 17/10/17 04:30 PM, Harry Wentland wrote:
>> Thanks for these cleanups.
>>
>> Some of these could possibly squashed but then, I generally
>> prefer smaller changes than one big lump.
>>
>> Reviewed-by: Harry Wentland
>
> Hi Harry,
>
> You're welcom
> -Original Message-
> From: Peter Stuge [mailto:pe...@stuge.se]
> Sent: Tuesday, October 17, 2017 7:29 AM
> To: amd-gfx@lists.freedesktop.org
> Cc: Deucher, Alexander; Koenig, Christian
> Subject: Re: drm/amdgpu: LVDS-1 output only turns on with sleep 1s
> workaround
>
> Peter Stuge wrote
On 10/17/2017 05:11 PM, Tom St Denis wrote:
I'm ok with not pushing my commit and simply adding an else branch
that sets the pointer to NULL.
(maybe put a WARN_ON to give context?)
Seems reasonable to me.
Harry ?
Andrey
Tom
On 17/10/17 04:42 PM, Andrey Grodzovsky wrote:
On 10/17/201
On 17/10/17 04:30 PM, Harry Wentland wrote:
Thanks for these cleanups.
Some of these could possibly squashed but then, I generally
prefer smaller changes than one big lump.
Reviewed-by: Harry Wentland
Hi Harry,
You're welcome. Normally I too agree that squashing is better but since
that p
I'm ok with not pushing my commit and simply adding an else branch that
sets the pointer to NULL.
(maybe put a WARN_ON to give context?)
Tom
On 17/10/17 04:42 PM, Andrey Grodzovsky wrote:
On 10/17/2017 04:12 PM, Nicolai Hähnle wrote:
On 17.10.2017 19:45, Tom St Denis wrote:
If the allocat
On 10/17/2017 04:12 PM, Nicolai Hähnle wrote:
On 17.10.2017 19:45, Tom St Denis wrote:
If the allocation fails in amdgpu_dm_connector_funcs_reset() the
API cannot continue so trigger a BUG_ON.
That seems questionable to be honest. The drm_atomic_helper version of
this function ends up setti
On 2017-10-17 04:12 PM, Nicolai Hähnle wrote:
> On 17.10.2017 19:45, Tom St Denis wrote:
>> If the allocation fails in amdgpu_dm_connector_funcs_reset() the
>> API cannot continue so trigger a BUG_ON.
>
> That seems questionable to be honest. The drm_atomic_helper version of this
> function ends
Thanks for these cleanups.
Some of these could possibly squashed but then, I generally
prefer smaller changes than one big lump.
Reviewed-by: Harry Wentland
Harry
On 2017-10-17 12:18 PM, Tom St Denis wrote:
> Various cleanups to indentation/braces as well as a couple of
> simplifications. Mos
On 17.10.2017 19:45, Tom St Denis wrote:
If the allocation fails in amdgpu_dm_connector_funcs_reset() the
API cannot continue so trigger a BUG_ON.
That seems questionable to be honest. The drm_atomic_helper version of
this function ends up setting connector->state = NULL; in this case.
Cheer
On 10/17/2017 03:43 PM, Harry Wentland wrote:
On 2017-10-17 02:15 PM, Christian König wrote:
Am 17.10.2017 um 19:58 schrieb Felix Kuehling:
On 2017-10-17 01:25 PM, Tom St Denis wrote:
On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16
On 2017-10-17 02:15 PM, Christian König wrote:
> Am 17.10.2017 um 19:58 schrieb Felix Kuehling:
>> On 2017-10-17 01:25 PM, Tom St Denis wrote:
>>> On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
> Am 17.10.2017 um 16:10 schrieb Tom St Denis:
>> In
[drm:gfx_v8_0_priv_reg_irq] *ERROR* Illegal register access in command stream
[drm] IP block:gmc_v8_0 is hung!
[drm] IP block:gfx_v8_0 is hung!
BUG: unable to handle kernel NULL pointer dereference at 00d8
IP: amd_sched_hw_job_reset+0x3c/0x9a
PGD 3aedd8067 P4D 3aedd8067 PUD 3aedd9067 P
Reviewed-by: Andrey Grodzovsky
On 10/17/2017 01:45 PM, Tom St Denis wrote:
If the allocation fails in amdgpu_dm_connector_funcs_reset() the
API cannot continue so trigger a BUG_ON.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
1 file changed, 1 i
On 10/17/2017 01:58 PM, Felix Kuehling wrote:
On 2017-10-17 01:25 PM, Tom St Denis wrote:
On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct d
Am 17.10.2017 um 19:58 schrieb Felix Kuehling:
On 2017-10-17 01:25 PM, Tom St Denis wrote:
On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct dr
On 2017-10-17 01:25 PM, Tom St Denis wrote:
> On 17/10/17 01:23 PM, Tom St Denis wrote:
>> On 17/10/17 01:18 PM, Christian König wrote:
>>> Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)
{
If the allocation fails in amdgpu_dm_connector_funcs_reset() the
API cannot continue so trigger a BUG_ON.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/dri
On 10/17/2017 01:36 PM, Tom St Denis wrote:
On 17/10/17 01:34 PM, Andrey Grodzovsky wrote:
On 10/17/2017 01:25 PM, Tom St Denis wrote:
On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code
On 17/10/17 01:34 PM, Andrey Grodzovsky wrote:
On 10/17/2017 01:25 PM, Tom St Denis wrote:
On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct
On 10/17/2017 01:25 PM, Tom St Denis wrote:
On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)
{
struct dm_connec
I'll send you a patch by Friday.
Regards,
Felix
On 2017-10-17 03:04 AM, Oded Gabbay wrote:
> Hi Felix, Yong.
> I would like to send a pull request to Dave for kernel 4.15 with all
> the patches you sent in the last 3 weeks, but I'm blocked by the fix I
> asked for this patch.
> Do you think yo
On 17/10/17 01:23 PM, Tom St Denis wrote:
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)
{
struct dm_connector_state *state =
to_dm_connector_stat
On 17/10/17 01:18 PM, Christian König wrote:
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)
{
struct dm_connector_state *state =
to_dm_connector_state(connector->state);
kfree(state);
Am 17.10.2017 um 16:10 schrieb Tom St Denis:
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)
{
struct dm_connector_state *state =
to_dm_connector_state(connector->state);
kfree(state);
state = kzalloc(sizeof(*state), GFP_KERNEL);
Acked-by: Andrey Grodzovsky
On 10/17/2017 12:18 PM, Tom St Denis wrote:
Various cleanups to indentation/braces as well as a couple of
simplifications. Mostly NFC but there are a couple of patches with
trivial functional changes (#6, #8)
___
amd-gf
There is a local reference to the dc_link that wasn't being
used so we shorten references throughout the function.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/am
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b4454937b4d4..89479eb99d1e 100644
--
Various cleanups to indentation/braces as well as a couple of
simplifications. Mostly NFC but there are a couple of patches with
trivial functional changes (#6, #8)
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/ma
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c23e6a288666..5e03d918b19f 100644
--
Replace inlined strncpy with library call.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdg
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 708372001456..0e10548dfd1f 100644
The cast of dc_link is redundant.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8
Move WARN_ON higher up and in doing so fix brace style.
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amd
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f2d21dccc647..e371d740b662 100644
--
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c
index b9e4d38310
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3a927a24ea0c..f999cb312fa3 100644
--
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 0e10548dfd1f..3a927a24ea0c 100644
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 8b90766c0fe8..708372001456 100644
Signed-off-by: Tom St Denis
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 63ddf78e7482..8b90766c0fe8 100644
--
If I remember correctly, it should be John B.
Regards,
Andres
On 2017-10-17 11:42 AM, Felix Kuehling wrote:
I didn't even know about the freedesktop repository. Do you know who has
commit access to that?
Regards,
Felix
On 2017-10-16 10:44 PM, Tom Stellard wrote:
Hi Felix,
What do you th
I didn't even know about the freedesktop repository. Do you know who has
commit access to that?
Regards,
Felix
On 2017-10-16 10:44 PM, Tom Stellard wrote:
> Hi Felix,
>
> What do you think about merging your fxkamd/drm-next-wip into the
> master branch of the hsakmt repository of freedesktop[1
On 17/10/17 04:52 PM, Kai Wasserbäch wrote:
> Dear Michel,
> Michel Dänzer wrote on 17.10.2017 11:20:
>> On 16/10/17 06:21 PM, Kai Wasserbäch wrote:
>>> Michel Dänzer wrote on 16.10.2017 18:05:
On 16/10/17 05:53 PM, Kai Wasserbäch wrote:
> [...]
>
> But when I look at my Xorg.0.log
On 17/10/17 04:53 PM, Harry Wentland wrote:
> On 2017-10-17 10:47 AM, Michel Dänzer wrote:
>> On 13/10/17 09:22 PM, Harry Wentland wrote:
>>> On 2017-10-12 08:22 PM, Dieter Nützel wrote:
next (regression) compilation error:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resour
On 2017-10-17 10:47 AM, Michel Dänzer wrote:
> On 13/10/17 09:22 PM, Harry Wentland wrote:
>> On 2017-10-12 08:22 PM, Dieter Nützel wrote:
>>> Hello,
>>>
>>> next (regression) compilation error:
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function
>>> ‘resource_map_pool
Dear Michel,
Michel Dänzer wrote on 17.10.2017 11:20:
> On 16/10/17 06:21 PM, Kai Wasserbäch wrote:
>> Michel Dänzer wrote on 16.10.2017 18:05:
>>> On 16/10/17 05:53 PM, Kai Wasserbäch wrote:
[...]
But when I look at my Xorg.0.log or the output of eglinfo, I see the
following
>
On 13/10/17 09:22 PM, Harry Wentland wrote:
> On 2017-10-12 08:22 PM, Dieter Nützel wrote:
>> Hello,
>>
>> next (regression) compilation error:
>>
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c: In function
>> ‘resource_map_pool_resources’:
>> drivers/gpu/drm/amd/amdgpu/../display/
In this block of code:
void amdgpu_dm_connector_funcs_reset(struct drm_connector *connector)
{
struct dm_connector_state *state =
to_dm_connector_state(connector->state);
kfree(state);
state = kzalloc(sizeof(*state), GFP_KERNEL);
The value of state is n
Peter Stuge wrote:
> Can I help find the cause of my problem and make the internal panel turn
> on without my workaround? What information would be needed, and should I
> send here or use bugzilla?
Anyone? Redirecting me to bugzilla is fine, if that's my best bet.
Thanks!
//Peter
__
Thanks. In logically, it can’t handle the extreme case that the seq almost
catches up with wait_seq in wrap round where we can’t use this trick, however I
understand it can’t happen in reality.
I will test and modify.
—
Sincerely Yours,
Pixel
On 17/10/2017, 4:59 PM, "Koenig, Christian"
On 16/10/17 06:21 PM, Kai Wasserbäch wrote:
> Michel Dänzer wrote on 16.10.2017 18:05:
>> On 16/10/17 05:53 PM, Kai Wasserbäch wrote:
>>>
>>> Hey,
>>> I'm not sure whether this is a bug or if I'm just missing something. I've
>>> got
>>> the following stack (Debian testing as a base):
>>> GPU: Hawa
Am 17.10.2017 um 10:57 schrieb Nicolai Hähnle:
On 13.10.2017 10:46, Liu, Monk wrote:
Just revert Nicolai’s patch,if other routine want to reference
s_fence, it should get the finished fence in the first place/time,
For gpu_reset routine, it refers to s_fence only on those unfinished
job in sc
Am 17.10.2017 um 10:38 schrieb Ding, Pixel:
[SNIP]
+ if (seq >= wait_seq && wait_seq >= last_seq)
+ break;
+ if (seq <= last_seq &&
+ (wait_seq <= seq || wait_seq >= last_seq))
+ break;
Why not just "(int3
On 13.10.2017 10:46, Liu, Monk wrote:
Just revert Nicolai’s patch,if other routine want to reference s_fence,
it should get the finished fence in the first place/time,
For gpu_reset routine, it refers to s_fence only on those unfinished job
in sched_hw_job_reset, so totally safe to refer to s_
On 2017年10月17日 16:34, Chunming Zhou wrote:
On 2017年10月17日 16:27, Christian König wrote:
Am 17.10.2017 um 10:15 schrieb Chunming Zhou:
On 2017年10月17日 15:46, Christian König wrote:
Am 17.10.2017 um 06:11 schrieb Chunming Zhou:
On 2017年10月16日 19:40, Christian König wrote:
Am 16.10.2017
On 17/10/2017, 4:20 PM, "Koenig, Christian" wrote:
>Am 17.10.2017 um 08:37 schrieb Pixel Ding:
>> From: pding
>>
>> Register accessing is performed when IRQ is disabled. Never sleep in
>> this function.
>>
>> Known issue: dead sleep in many use cases of index/data registers.
>>
>> v2: wrap poll
On 2017年10月17日 16:27, Christian König wrote:
Am 17.10.2017 um 10:15 schrieb Chunming Zhou:
On 2017年10月17日 15:46, Christian König wrote:
Am 17.10.2017 um 06:11 schrieb Chunming Zhou:
On 2017年10月16日 19:40, Christian König wrote:
Am 16.10.2017 um 11:42 schrieb Chunming Zhou:
On 2017年10月
Patch is
Tested-by: Rex Zhu
Best Regards
Rex
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of
Christian König
Sent: Tuesday, October 17, 2017 4:28 PM
To: Zhou, David(ChunMing); amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH 2/2] drm/amdgp
Am 17.10.2017 um 10:15 schrieb Chunming Zhou:
On 2017年10月17日 15:46, Christian König wrote:
Am 17.10.2017 um 06:11 schrieb Chunming Zhou:
On 2017年10月16日 19:40, Christian König wrote:
Am 16.10.2017 um 11:42 schrieb Chunming Zhou:
On 2017年10月16日 17:26, Christian König wrote:
From: Christi
Am 17.10.2017 um 08:37 schrieb Pixel Ding:
From: pding
Register accessing is performed when IRQ is disabled. Never sleep in
this function.
Known issue: dead sleep in many use cases of index/data registers.
v2: wrap polling fence functions. don't trigger IRQ for polling in
case of wrongly fenc
On 2017年10月17日 15:46, Christian König wrote:
Am 17.10.2017 um 06:11 schrieb Chunming Zhou:
On 2017年10月16日 19:40, Christian König wrote:
Am 16.10.2017 um 11:42 schrieb Chunming Zhou:
On 2017年10月16日 17:26, Christian König wrote:
From: Christian König
While binding BOs to GART we need to
you can see the difference of function amdgpu_need_post. Generally speaking,
there were 2 functions to check VBIOS posting, one considers VF and passthru
while the other doesn’t. In fact we should always consider VF and PT for
checking, right? For example, this checking here believe VF needs a p
From the patch itself I still couldn't tell the difference
-Original Message-
From: Ding, Pixel
Sent: 2017年10月17日 15:54
To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Koenig,
Christian
Cc: Li, Bingley ; Sun, Gary
Subject: Re: [PATCH 1/3] drm/amdgpu: always consider virualised device f
Okay leave it, we may need OS preemption in future so it still can be used for
that purpose
Reviewed-by: Monk Liu
-Original Message-
From: Ding, Pixel
Sent: 2017年10月17日 15:56
To: Liu, Monk ; amd-gfx@lists.freedesktop.org; Koenig,
Christian
Cc: Li, Bingley ; Sun, Gary
Subject: Re: [
Why? The fence WB is always 8 DW.
—
Sincerely Yours,
Pixel
On 17/10/2017, 3:49 PM, "Liu, Monk" wrote:
>Please use if (amdgpu_sriov_vf())
>To protect your added part
>
>-Original Message-
>From: Pixel Ding [mailto:pixel.d...@amd.com]
>Sent: 2017年10月17日 14:38
>To: amd-gfx@lists.fre
It fixes a issue hidden in:
95 static bool igp_read_bios_from_vram(struct amdgpu_device *adev)
96 {
97 uint8_t __iomem *bios;
98 resource_size_t vram_base;
99 resource_size_t size = 256 * 1024; /* ??? */
100
101 if (!(adev->flags & AMD_IS_APU))
102 if (amdgpu_need_p
Please use if (amdgpu_sriov_vf())
To protect your added part
-Original Message-
From: Pixel Ding [mailto:pixel.d...@amd.com]
Sent: 2017年10月17日 14:38
To: amd-gfx@lists.freedesktop.org; Liu, Monk ; Koenig,
Christian
Cc: Li, Bingley ; Sun, Gary ; Ding, Pixel
Subject: [PATCH 2/3] drm/amdg
I don't understand how this patch works??? Looks like just rename vpost_needed
to check_post
-Original Message-
From: Pixel Ding [mailto:pixel.d...@amd.com]
Sent: 2017年10月17日 14:38
To: amd-gfx@lists.freedesktop.org; Liu, Monk ; Koenig,
Christian
Cc: Li, Bingley ; Sun, Gary ; Ding, Pixe
Am 17.10.2017 um 06:11 schrieb Chunming Zhou:
On 2017年10月16日 19:40, Christian König wrote:
Am 16.10.2017 um 11:42 schrieb Chunming Zhou:
On 2017年10月16日 17:26, Christian König wrote:
From: Christian König
While binding BOs to GART we need to allow a bit overcommit in the GTT
domain.
If al
On Sun, Oct 8, 2017 at 3:13 PM, Oded Gabbay wrote:
> On Wed, Sep 27, 2017 at 7:09 AM, Felix Kuehling
> wrote:
>> From: Yong Zhao
>>
>> Signed-off-by: Yong Zhao
>> Signed-off-by: Felix Kuehling
>> ---
>> .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 28
>> --
>> 1
Am 17.10.2017 um 08:37 schrieb Pixel Ding:
From: pding
Only for GFX ring. This can help checking MCBP feature.
v2: report more fence offs.
The fence at the end of the frame will indicate the completion status.
If the frame completed normally, the fence is written to the address
given in the E
83 matches
Mail list logo
