0x FFF0 should be inside the hole, so why it is a correct address?
I was assuming that this is the linear address which is then "sign extended" to
0x FFF0 .
If that address is used somewhere without extending bit 47 into bits 48-63 then
we have found the root cause of the
Hi Monk,
You see that for UMD, it can use 0 to HOLE_START
Let me say it once more: The UMD nor anybody else CAN'T use 0 to
HOLE_START, that region is reserved for the ATC hardware!
We unfortunately didn't knew that initially and also didn't used the
ATC, so we didn't ran into a problem.
Bu
[SNIP]
Re-arming the timeout should probably have a much reduced value
when the job hasn't changed. E.g. something like a few ms.
>
> Now i got thinking about non hanged job in progress (job A) and let's
> say it's a long job , it just started executing but due to time out of
> another
在 2019/1/18 17:11, Christian König 写道:
Hi Monk,
You see that for UMD, it can use 0 to HOLE_START
Let me say it once more: The UMD nor anybody else CAN'T use 0 to HOLE_START,
that region is reserved for the ATC hardware!
We unfortunately didn't knew that initially and also didn't used the ATC, s
Am 18.01.19 um 10:29 schrieb Zhou, David(ChunMing):
在 2019/1/18 17:11, Christian König 写道:
Hi Monk,
You see that for UMD, it can use 0 to HOLE_START
Let me say it once more: The UMD nor anybody else CAN'T use 0 to HOLE_START,
that region is reserved for the ATC hardware!
We unfortunately didn'
Replace the last bool type parameter with a general flags parameter,
to make the last parameter be able to contain more information.
Signed-off-by: Jack Xiao
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 7 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/am
You know what, … when you explained range 0 to HOLE-START is even not good to
exposed to UMD I thought you made a typo and that’s why I repeat my question
again …
it’s the first time I heard that GMC9 cannot use 0 -> HOLE-START even for UMD
general usage …
With your assert in DEV_INFO the “vir
HI Christian
Regarding with range 0->hole_start being occupied by ATC, Can you share me
where you see such limitation, any hardware document ?
/Monk
From: amd-gfx On Behalf Of Koenig,
Christian
Sent: Friday, January 18, 2019 5:02 PM
To: Lou, Wentao ; Liu, Monk ;
amd-gfx@lists.freedesktop.org
You know what, … when you explained range 0 to HOLE-START is even not good to
exposed to UMD I thought you made a typo and that’s why I repeat my question
again …
Sorry my fault then. Didn't wanted to sound offending.
it’s the first time I heard that GMC9 cannot use 0 -> HOLE-START even for UM
Am 18.01.19 um 11:41 schrieb Xiao, Jack:
> Replace the last bool type parameter with a general flags parameter,
> to make the last parameter be able to contain more information.
>
> Signed-off-by: Jack Xiao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 7 ++-
> drivers/gpu/drm/amd/amdg
I've since replaced the LS1012ARDB with a LS1046ARDB, and this works out of
the box.
The LS1012ARDB does not have an SMMU, which handles hardware coherency on
ARM.
So amdgpu won't work on any ARM without an SMMU.
Bas Vermeulen
On Thu, Jan 10, 2019 at 2:38 PM Koenig, Christian
wrote:
> Am 10.01.
On 01/18/2019 04:25 AM, Koenig, Christian wrote:
> [SNIP]
> Re-arming the timeout should probably have a much reduced value
> when the job hasn't changed. E.g. something like a few ms.
>> Now i got thinking about non hanged job in progress (job A) and let's
>> say it's a long job , it jus
Am 18.01.19 um 16:21 schrieb Grodzovsky, Andrey:
>
> On 01/18/2019 04:25 AM, Koenig, Christian wrote:
>> [SNIP]
>> Re-arming the timeout should probably have a much reduced value
>> when the job hasn't changed. E.g. something like a few ms.
>>> Now i got thinking about non hanged job in pro
On 01/18/2019 12:10 PM, Koenig, Christian wrote:
> Am 18.01.19 um 16:21 schrieb Grodzovsky, Andrey:
>> On 01/18/2019 04:25 AM, Koenig, Christian wrote:
>>> [SNIP]
>>> Re-arming the timeout should probably have a much reduced value
>>> when the job hasn't changed. E.g. something like a few
Am 18.01.19 um 18:34 schrieb Grodzovsky, Andrey:
>
> On 01/18/2019 12:10 PM, Koenig, Christian wrote:
>> Am 18.01.19 um 16:21 schrieb Grodzovsky, Andrey:
>>> On 01/18/2019 04:25 AM, Koenig, Christian wrote:
[SNIP]
Re-arming the timeout should probably have a much reduced value
>>>
Attached series is the first 2 patches we already discussed about ring
mirror list handling racing with all your comments fixed (still not
committed). The third patch is a prototype based on the first 2 patches
and on our discussion.
Please take a look.
Andrey
On 01/18/2019 01:32 PM, Koenig,
16 matches
Mail list logo
