Hmm,
This zone was intended to stop TTM page allocations from exhausting the
DMA32 zone. IIRC dma_alloc_coherent() uses DMA32 by default, which means
if we drop this check, other devices may stop functioning unexpectedly?
However, in the end I'd expect the kernel page allocation system to mak
On Thu, Jan 31, 2019 at 1:01 PM Masahiro Yamada
wrote:
>
> Currently, the Kbuild core manipulates header search paths in a crazy
> way [1].
>
> To fix this mess, I want all Makefiles to add explicit $(srctree)/ to
> the search paths in the srctree. Some Makefiles are already written in
> that way,
From: Colin Ian King
There are multiple occurrances of the same spelling mistake in
messages in PP_ASSERT_WITH_CODE macros. Fix these.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/smumgr/vega12_smumgr.c | 12 ++--
drivers/gpu/drm/amd/powerplay/smumgr/vega20_smumgr.c
Another good question is also why the heck the acc_size counts towards
the DMA32 zone?
In other words why should the internal bookkeeping pages be allocated in
the DMA32 zone?
That doesn't sounds valid to me in any way,
Christian.
Am 18.02.19 um 09:02 schrieb Thomas Hellstrom:
> Hmm,
>
> This
On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
> Another good question is also why the heck the acc_size counts
> towards
> the DMA32 zone?
DMA32 TTM pages are accounted in the DMA32 zone. Other pages are not.
For small persistent allocations using ttm_mem_global_alloc(), they are
a
Hi Lionel,
I checked your igt test case,
uint64_t points[5] = { 1, 5, 3, 7, 6 };
which is illegal signal order.
I must admit we should handle it gracefully if signal isn't in-order,
and we shouldn't lead to deadlock.
Hi Christian,
Can we just ignore when signal point X <= timeline Y? Or ju
Hi David,
well I think Lionel is testing the invalid signal order on purpose :)
Anyway we really need to handle invalid order graceful here. E.g. either the
same way as during CS or we abort and return an error message.
I think just using the same approach as during CS ist the best we can do.
On 18/02/2019 07:28, Koenig, Christian wrote:
Am 18.02.19 um 04:10 schrieb zhoucm1:
On 2019年02月17日 03:22, Christian König wrote:
Am 15.02.19 um 20:31 schrieb Lionel Landwerlin via amd-gfx:
On 07/12/2018 09:55, Chunming Zhou wrote:
user mode can query timeline payload.
v2: check return value
Thanks guys :)
You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj
implementation?
I'm not finding anything in the vulkan spec that makes out of order
signaling illegal.
That's why I came up with this test, just verifying that
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/si_dpm.c: In function 'si_program_response_times':
drivers/gpu/drm/radeon/si_dpm.c:3640:29: warning:
variable 'backbias_response_time' set but not used [-Wunused-but-set-variable]
It never used since introduction.
Signed-off-
Am 18.02.19 um 13:07 schrieb Lionel Landwerlin:
Thanks guys :)
You mentioned that signaling out of order is illegal.
Is this illegal with regard to the vulkan spec or to the syncobj implementation?
David is the expert on that, but as far as I know that is forbidden by the
vulkan spec.
I'm not f
Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
Another good question is also why the heck the acc_size counts
towards
the DMA32 zone?
DMA32 TTM pages are accounted in the DMA32 zone. Other pages are not.
Yeah, I'm perfectly aware of
On Mon, 2019-02-18 at 18:07 +0100, Christian König wrote:
> Am 18.02.19 um 10:47 schrieb Thomas Hellstrom:
> > On Mon, 2019-02-18 at 09:20 +, Koenig, Christian wrote:
> > > Another good question is also why the heck the acc_size counts
> > > towards
> > > the DMA32 zone?
> > DMA32 TTM pages are
Based on a similar patch from Rafael for radeon.
When using ATPX to control dGPU power, the state is not retained
across suspend and resume cycles by default. This can probably
be loosened for Hybrid Graphics (_PR3) laptops where I think the
state is properly retained.
Fixes: c62ec4610c40 ("PM /
On Sun, Feb 17, 2019 at 4:26 PM Rafael J. Wysocki wrote:
>
> On Sun, Feb 17, 2019 at 12:37 AM Alex Deucher wrote:
> >
> > On Sat, Feb 16, 2019 at 1:01 AM Lukas Wunner wrote:
> > >
> > > On Fri, Feb 15, 2019 at 11:01:04AM -0500, Alex Deucher wrote:
> > > > On Fri, Feb 15, 2019 at 10:39 AM Rafael
On Fri, Feb 15, 2019 at 5:40 PM Gustavo A. R. Silva
wrote:
>
> Add missing break statement in order to prevent the code from falling
> through to case CB_TARGET_MASK.
>
> This bug was found thanks to the ongoing efforts to enable
> -Wimplicit-fallthrough.
>
> Fixes: dd220a00e8bd ("drm/radeon/kms:
This was noticed by Gustavo and his -Wimplicit-fallthrough
patches. However, in this case, I believe we should have breaks
rather than falling though, that said, in practice we should
never fall through in the first place so there should be no
change in behavior.
Signed-off-by: Alex Deucher
---
On Fri, Feb 15, 2019 at 1:50 PM Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enable
> -Wimplicit-
On 2/18/19 4:40 PM, Alex Deucher wrote:
> On Fri, Feb 15, 2019 at 1:50 PM Gustavo A. R. Silva
> wrote:
>>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This patch i
Although the shader is simple enough, please work with CQE to test it on all
gfx9 ASICs before push it.
The patch is Reviewed-by: Hawking Zhang
Regards,
Hawking
-Original Message-
From: amd-gfx On Behalf Of Cui, Flora
Sent: 2019年2月18日 12:56
To: amd-gfx@lists.freedesktop.org; dri-de...@
Simplify the ppfeature mask calculations.
Change-Id: I41dee48c2ac8ed1fd7736bc8bb1f832da22cba13
Signed-off-by: Evan Quan
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/vega20_hwmgr.c
Reviewed-by: Kenneth Feng
-Original Message-
From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Evan
Quan
Sent: Tuesday, February 19, 2019 12:28 PM
To: amd-gfx@lists.freedesktop.org
Cc: Kuehling, Felix ; Quan, Evan
Subject: [PATCH] drm/amd/powerplay: fix the confu
22 matches
Mail list logo
