v2:
Modify for movig pflip flags to crtc_state
v4:
Fix identation.
v5:
Rename field to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 -
.../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 +
2 files change
v2:
Update code after flip_flags moved from plane_state
to crtc_state
v5:
Rename to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/nouveau/nv50_display.c | 84 --
1 file changed, 10 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/dr
This series is a folow-up on
https://patchwork.kernel.org/patch/9501787/
The first patch makes changes to atomic helpers to allow for drives with ASYNC
flip support to use them.
Patch 2 is to use this in AMDGPU/DC.
Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the
hel
Allows using atomic flip helpers for drivers
using ASYNC flip.
Remove ASYNC_FLIP restriction in helpers and
caches the page flip flags in drm_crtc_state
to be used in the low level drivers.
v2:
Resending the patch since the original was broken.
v3:
Save flag in crtc_state instead of plane_state
On Thu, Feb 2, 2017 at 4:05 PM, Bas Nieuwenhuizen
wrote:
> What branch is this based on? It fails to apply for me on
> drm-next-4.11-wip of Alex' git repo.
Probably amd-staging-4.9
Alex
>
> On Thu, Feb 2, 2017, at 11:25, Christian König wrote:
>> Hi guys,
>>
>> a bunch of bug fixes, but still c
What branch is this based on? It fails to apply for me on
drm-next-4.11-wip of Alex' git repo.
On Thu, Feb 2, 2017, at 11:25, Christian König wrote:
> Hi guys,
>
> a bunch of bug fixes, but still completely untested since I'm on sick
> leave.
>
> Bas maybe you could give it a try with radv.
>
>
Hi Dave,
Just a couple of small fixes for 4.10
The following changes since commit 52b679f60e2a68af88411f12318675a2424a0e14:
Merge tag 'drm-misc-fixes-2017-01-31' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-02-01 08:45:27
+1000)
are available in the git repository at:
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
wrote:
> This series is a folow-up on
> https://patchwork.kernel.org/patch/9501787/
>
> The first patch makes changes to atomic helpers to allow for drives with
> ASYNC flip support to use them.
> Patch 2 is to use this in AMDGPU/DC.
> Patch 3 is
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_crtc_state
> to be used in the low level drivers.
>
> v2:
> Resending the patch since the
Am 02.02.2017 um 07:09 schrieb Michel Dänzer:
[SNIP]
OTOH the people running the kernel aren't always the same people
building it, so the downside is that this would potentially delay
getting X86_PAT enabled.
And exactly for this reason I would rather like to keep the warning.
Regards,
Christi
On 02/02/17 12:59 AM, Arnd Bergmann wrote:
> My randconfig tests on linux-next showed a newly introduced warning:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function
> 'amdgpu_bo_create_restricted':
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please
> enable CONFI
On 02.02.2017 11:26, Christian König wrote:
Am 30.01.2017 um 15:43 schrieb Nicolai Hähnle:
On 30.01.2017 13:57, Christian König wrote:
From: Christian König
For PRT support we need mappings which aren't backed by any memory.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amd
From: Christian König
For PRT support we need mappings which aren't backed by any memory.
v2: fix parameter checking
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/
Hi guys,
a bunch of bug fixes, but still completely untested since I'm on sick leave.
Bas maybe you could give it a try with radv.
Regards,
Christian.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinf
From: Junwei Zhang
Till GFX8 we can only enable PRT support globally, but with the next hardware
generation we can do this on a per page basis.
Keep the interface consistent by adding PRT mappings and enable
support globally on current hardware when the first mapping is made.
v2: disable PRT su
From: Christian König
Enable/disable the handling globally for now and
print a warning when we enable it for the first time.
v2: set correct register
Signed-off-by: Junwei Zhang
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c | 57 +++
From: Christian König
Enable/disable the handling globally for now and
print a warning when we enable it for the first time.
v2: write to the correct register, adjust bits to that hw generation
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 55 +
From: Christian König
Future hardware generations can handle PRT flags on a per page basis,
but current hardware can only turn it on globally.
Add the basic handling for both, a global callback to enable/disable
triggered by setting a per mapping flag.
Signed-off-by: Christian König
---
drive
From: Christian König
Enable/disable the handling globally for now and
print a warning when we enable it for the first time.
v2: set correct register
Signed-off-by: Junwei Zhang
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 1 +
drivers/gpu/drm/amd/amdgpu/gmc_v7
Am 30.01.2017 um 15:43 schrieb Nicolai Hähnle:
On 30.01.2017 13:57, Christian König wrote:
From: Christian König
For PRT support we need mappings which aren't backed by any memory.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 20 ++--
1 file ch
Am 02.02.2017 um 10:33 schrieb Nicolai Hähnle:
On 02.02.2017 10:29, Bas Nieuwenhuizen wrote:
On Thu, Feb 2, 2017, at 10:18, Nicolai Hähnle wrote:
On 02.02.2017 02:49, Dave Airlie wrote:
I think we would require a fully open source user for this sort of
thing,
there are way to many corner cases
On 02.02.2017 10:29, Bas Nieuwenhuizen wrote:
On Thu, Feb 2, 2017, at 10:18, Nicolai Hähnle wrote:
On 02.02.2017 02:49, Dave Airlie wrote:
I think we would require a fully open source user for this sort of thing,
there are way to many corner cases for us to fall down here, prematurely
pushing t
On Thu, Feb 2, 2017, at 10:18, Nicolai Hähnle wrote:
> [ ceterum censeo, + John for addrlib :P ]
>
> On 02.02.2017 02:49, Dave Airlie wrote:
> >>> answered better by Dave.
> >>
> >>
> >> Yeah, though so as well. Dave can you comment?
> >
> > I think we would require a fully open source user for
[ ceterum censeo, + John for addrlib :P ]
On 02.02.2017 02:49, Dave Airlie wrote:
answered better by Dave.
Yeah, though so as well. Dave can you comment?
I think we would require a fully open source user for this sort of thing,
there are way to many corner cases for us to fall down here, pr
24 matches
Mail list logo