drm-next reverted the changes to ttm_tt_create() to do the
NULL check inside the function, but drm-misc-next adds new
users of this approach.
Re-apply the NULL check change inside the function to fix this.
Signed-off-by: Christian König
Reviewed-by: Dave Airlie
Link: https
Am 18.08.20 um 10:27 schrieb Gerd Hoffmann:
On Tue, Aug 18, 2020 at 09:57:59AM +0200, Christian König wrote:
Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
Am 18.08.20 um 09:48 schrieb Gerd Hoffmann:
Add max_segment argument to drm_prime_pages_to_sg(). When set pass it
through to the __sg_alloc_table_from_pages() call, otherwise use
SCATTERLIST_MAX_SEGMENT.
Also add max_segment field to gem objects and pass it to
drm_prime_pages_to_sg() calls in d
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in amdgpu. The only exception is gem_prime_mmap,
which is non-trivial to convert.
Sign
Am 13.08.20 um 12:41 schrieb Thomas Zimmermann:
Hi
Am 13.08.20 um 12:24 schrieb Christian König:
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per
Am 13.08.20 um 10:36 schrieb Thomas Zimmermann:
GEM object functions deprecate several similar callback interfaces in
struct drm_driver. This patch replaces the per-driver callbacks with
per-instance callbacks in radeon.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_drv.c
Am 27.07.20 um 22:53 schrieb Daniel Dadap:
Fall back to retrieving the EDID via the ACPI _DDC method, when present
for notebook internal panels, when retrieving BIOS-embedded EDIDs.
Signed-off-by: Daniel Dadap
---
drivers/gpu/drm/radeon/radeon_combios.c | 6 +++---
1 file changed, 3 insertio
Nouveau is the only user of this functionality and evicting io space
on -EAGAIN is really a misuse of the return code.
Instead switch to using -ENOSPC here which makes much more sense and
simplifies the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2
Implementing those is completely unecessary.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 5 -
drivers/gpu/drm/drm_gem_vram_helper.c | 5 -
drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
drivers/gpu/drm/radeon/radeon_ttm.c| 5
Just use the use_io_reserve_lru flag. It doesn't make much
sense to have two flags.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/drm/ttm/ttm_bo.c | 1 -
drivers/gpu/drm/ttm/ttm_bo_util.c| 8
include/drm/ttm/ttm_bo_dri
Only functional change is to always keep io_reserved_count up to date
for debugging even when it is not used otherwise.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 97 +++
1 file changed, 48 insertions(+), 49 deletions(-)
diff --git a
Am 20.05.20 um 18:18 schrieb Alex Deucher:
On Wed, May 20, 2020 at 10:43 AM Christian König
wrote:
Am 13.05.20 um 13:03 schrieb Christian König:
Unfortunately AGP is still to widely used as we could just drop support for
using its GART.
Not using the AGP GART also doesn't mean a lo
Am 20.05.20 um 18:25 schrieb Michel Dänzer:
On 2020-05-20 4:43 p.m., Christian König wrote:
Am 13.05.20 um 13:03 schrieb Christian König:
Unfortunately AGP is still to widely used as we could just drop
support for using its GART.
Not using the AGP GART also doesn't mean a lo
Am 13.05.20 um 13:03 schrieb Christian König:
Unfortunately AGP is still to widely used as we could just drop support for
using its GART.
Not using the AGP GART also doesn't mean a loss in functionality since drivers
will just fallback to the driver specific PCI GART.
For now just depr
Am 13.05.20 um 14:34 schrieb Daniel Vetter:
On Wed, May 13, 2020 at 01:03:13PM +0200, Christian König wrote:
Even when core AGP support is compiled in Radeon and
Nouveau can also work with the PCI GART.
The AGP support was notorious unstable and hard to
maintain, so deprecate it for now and
Even when core AGP support is compiled in Radeon and
Nouveau can also work with the PCI GART.
The AGP support was notorious unstable and hard to
maintain, so deprecate it for now and only enable it if
there is a good reason to do so.
Signed-off-by: Christian König
---
drivers/gpu/drm/Kconfig
Always use the PCI GART instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_drv.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index bbb0883e8ce6..a71f13116d6b 100644
--- a/drivers/gpu
Unfortunately AGP is still to widely used as we could just drop support for
using its GART.
Not using the AGP GART also doesn't mean a loss in functionality since drivers
will just fallback to the driver specific PCI GART.
For now just deprecate the code and don't enable the AGP GART in TTM eve
Am 12.05.20 um 23:12 schrieb Alex Deucher:
On Tue, May 12, 2020 at 4:52 PM Roy Spliet wrote:
Op 12-05-2020 om 14:36 schreef Alex Deucher:
On Tue, May 12, 2020 at 4:16 AM Michel Dänzer wrote:
On 2020-05-11 10:12 p.m., Alex Deucher wrote:
On Mon, May 11, 2020 at 1:17 PM Christian König
Am 11.05.20 um 22:56 schrieb Al Dunsmuir:
Hello Dave,
On Monday, May 11, 2020, 4:43:01 PM, Dave Airlie wrote:
On Tue, 12 May 2020 at 06:28, Alex Deucher wrote:
[SNIP]
Maybe we can find some way to compartmentalise AGP further?
Dave.
Significantly reduced caching on memory accesses defin
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/Makefile | 1 -
drivers/gpu/drm/ttm/ttm_agp_backend.c | 150 --
include/drm/ttm/ttm_set_memory.h | 44
include/drm/ttm/ttm_tt.h | 22
4 files changed
AGP is deprecated for 10+ years now and not used any more on modern hardware.
Old hardware should continue to work in PCI mode.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/Makefile| 4 +-
drivers/gpu/drm/radeon/evergreen.c | 7 -
drivers/gpu/drm/radeon/r100.c
AGP is deprecated for 10+ years now and not used any more on modern hardware.
Old hardware should continue to work in PCI mode.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 16 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 46 +
drivers/gpu/drm
Hi guys,
Well let's face it AGP is a total headache to maintain and dead for at least
10+ years.
We have a lot of x86 specific stuff in the architecture independent graphics
memory management to get the caching right, abusing the DMA API on multiple
occasions, need to distinct between AGP and
Am 18.02.20 um 19:28 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 19:23 schrieb Christian König:
Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am
Am 18.02.20 um 19:16 schrieb Thomas Zimmermann:
Hi
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
Am 18.02.20 um 18:13 schrieb Nirmoy:
On 2/18/20 1:44 PM, Christian König wrote:
Am 18.02.20 um 13:40 schrieb Thomas Zimmermann:
Hi
Am 17.02.20 um 16:04 schrieb Nirmoy Das:
GPU address handling is device specific and should be handle by its
device
driver.
Signed-off-by: Nirmoy Das
Hi Ben,
sorry for the delayed response. Haven been rather busy recently.
Am 28.01.20 um 06:49 schrieb Ben Skeggs:
On Sat, 25 Jan 2020 at 00:30, Christian König
wrote:
From: Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actuall
From: Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
From: Christian König
That is not used any more.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++--
include
Hi guys,
I've already send this out in September last year, but only got a response from
Daniel.
Could you guys please test this and tell me what you think about it?
Basically I'm trying to remove all driver specific features from TTM which
don't need to be inside the framework.
Thanks,
Chris
user_pages in worker
threads")
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Jason Gunthorpe
One question inline to confirm my understanding. Otherwise this patch is
Reviewed-by: Felix Kuehling
---
drivers/gpu/dr
Just a gentle ping on this.
Already got the Acked-by from Daniel, but I need some of the
nouveau guys to test this since I can only compile test it.
Regards,
Christian.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.o
From: Christian König
That is not used any more.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++--
include
From: Christian König
While working on TTM cleanups I've found that the io_reserve_lru used by
Nouveau is actually not working at all.
In general we should remove driver specific handling from the memory
management, so this patch moves the io_reserve_lru handling into Nouveau
instead.
Am 09.10.19 um 17:39 schrieb Daniel Vetter:
On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote:
[SNIP]
+static vm_fault_t nouveau_ttm_fault(struct vm_fault *vmf)
+{
+ struct vm_area_struct *vma = vmf->vma;
+ struct ttm_buffer_object *bo = vma->vm_privat
That is not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 37 +++--
drivers/gpu/drm/ttm/ttm_bo_util.c | 114 +-
drivers/gpu/drm/ttm/ttm_bo_vm.c | 33 +++
include/drm/ttm/ttm_bo_api.h | 5
ional correct, but is only compile tested!
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 106 ++
drivers/gpu/drm/nouveau/nouveau_bo.h | 3 +
drivers/gpu/drm/nouveau/nouveau_drv.h | 2 +
drivers/gpu/drm/nouveau/nouveau_ttm.c
Hi guys,
while working through more old TTM functionality I stumbled over the
io_reserve_lru.
Basic idea is that when this flag is set the driver->io_mem_reserve()
callback can return -EAGAIN resulting in unmapping of other BOs.
But Nouveau doesn't seem to return -EAGAIN in the call path of
manager.
When passing NULL the embedded _vma_manager is used.
All callers are updated to pass NULL, so the behavior doesn't change.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Christian König
---
include/drm/ttm/ttm_bo_driver.h | 8 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
ounds good. Drivers should not be allowed to create their
own private instance of that.
Thanks for doing this,
Christian.
It's also a step towards drm device
hotplug, which someone just asked.
Best regards
Thomas
Am 13.08.2018 um 12:33 schrieb Christian König:
Yes, please! I had it on my TOD
Yes, please! I had it on my TODO list to clean that up for an eternity.
Actually I never understood why that should be driver work to setup TTM?
I mean can't we just have a module_init/module_exit for TTM?
Thanks,
Christian.
Am 13.08.2018 um 12:24 schrieb Thomas Zimmermann:
TTM uses global me
Well I think we rejected that multiple times now.
At least I find the symbolic permissions easier to read and I absolutely
don't see any reason why we should only use one form.
Christian.
Am 24.05.2018 um 22:22 schrieb Joe Perches:
There is currently a mixture of octal and symbolic permissio
Good to have an example how to use HMM with an upstream driver.
Am 10.03.2018 um 04:21 schrieb jgli...@redhat.com:
This patchset adds SVM (Share Virtual Memory) using HMM (Heterogeneous
Memory Management) to the nouveau driver. SVM means that GPU threads
spawn by GPU driver for a specific user p
Ping?
Am 27.02.2018 um 13:07 schrieb Christian König:
Hi guys,
at least on amdgpu and radeon the page array allocated by
ttm_dma_tt_init is completely unused in the case of DMA-buf sharing.
So I'm trying to get rid of that by only allocating the DMA address
array.
Now the only other
u. So my question is are you guys using the page array anywhere in
your kernel driver in case of a DMA-buf sharing?
If no then I could just make this the default behavior for all drivers
and save quite a bit of memory for everybody.
Thanks,
Christian.
Am 27.02.2018 um 12:49 schrieb Christian
Hi Konrad,
just a gentle ping.
It looks like the patch "swiotlb: suppress warning when __GFP_NOWARN is
set" didn't made it into 4.15 and now people are bombarding us with bug
reports about that.
Did you already send that one out for inclusion in 4.16? It also has a
stable tag, so it should
uthor: Christian König
Date: Thu Jul 6 09:59:43 2017 +0200
drm/ttm: add transparent huge page support for DMA allocations v2
Try to allocate huge pages when it makes sense.
v2: fix comment and use ifdef
BTW, I haven't noticed any bad effects other than the dmesg splats, so
maybe
Am 01.01.2018 um 19:08 schrieb Ilia Mirkin:
On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith wrote:
On Sun, 2017-12-31 at 13:27 -0500, Ilia Mirkin wrote:
On Tue, Dec 19, 2017 at 8:45 AM, Christian König
wrote:
Am 19.12.2017 um 11:39 schrieb Michel Dänzer:
On 2017-12-19 11:37 AM, Michel
st I don't need this split up
between drivers.
Patch is Reviewed-by: Christian König .
Regards,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-
drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +-
Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst:
op 04-08-14 17:04, Christian König schreef:
Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
op 04-08-14 16:45, Christian König schreef:
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
op 04-08-14 16:37, Christian König schreef:
It'a
Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst:
op 04-08-14 16:45, Christian König schreef:
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
op 04-08-14 16:37, Christian König schreef:
It'a pain to deal with gpu reset.
Yeah, well that's nothing new.
I've now tried othe
Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst:
op 04-08-14 16:37, Christian König schreef:
It'a pain to deal with gpu reset.
Yeah, well that's nothing new.
I've now tried other solutions but that would mean reverting to the old style
during gpu lockup recovery, and o
set code?
Christian.
Am 04.08.2014 um 15:34 schrieb Maarten Lankhorst:
Hey,
op 04-08-14 13:57, Christian König schreef:
Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
op 04-08-14 10:36, Christian König schreef:
Hi Maarten,
Sorry for the delay. I've got way to much todo recently
Am 04.08.2014 um 10:55 schrieb Maarten Lankhorst:
op 04-08-14 10:36, Christian König schreef:
Hi Maarten,
Sorry for the delay. I've got way to much todo recently.
Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
On 01-08-14 18:35, Christian König wrote:
Am 31.07.2014 um 17:33 sc
Hi Maarten,
Sorry for the delay. I've got way to much todo recently.
Am 01.08.2014 um 19:46 schrieb Maarten Lankhorst:
On 01-08-14 18:35, Christian König wrote:
Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
Signed-off-by: Maarten Lankhorst
---
V1 had a nasty bug breaking gpu l
Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
Signed-off-by: Maarten Lankhorst
---
V1 had a nasty bug breaking gpu lockup recovery. The fix is not
allowing radeon_fence_driver_check_lockup to take exclusive_lock,
and kill it during lockup recovery instead.
That looks like the delayed work
[CCing Emil as well]
Am 30.07.2014 um 11:38 schrieb Maarten Lankhorst:
Using -export-symbols-regex all private symbols are hidden, resulting in the
following changes:
Wasn't "-export-symbols-regex" exactly that stuff we are trying to avoid
in mesa?
Christian.
libkms: removes all driver
it or help with the
patch, but the general approach sounds valid to me.
Regards,
Christian.
Am 23.07.2014 16:05, schrieb Maarten Lankhorst:
op 23-07-14 15:16, Maarten Lankhorst schreef:
op 23-07-14 14:36, Christian König schreef:
Am 23.07.2014 12:52, schrieb Daniel Vetter:
On Wed, Jul 23, 2014
Am 23.07.2014 12:52, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 12:13 PM, Christian König
wrote:
And the dma-buf would still have fences belonging to both drivers, and it
would still call from outside the driver.
Calling from outside the driver is fine as long as the driver can do
Am 23.07.2014 11:55, schrieb Maarten Lankhorst:
op 23-07-14 11:47, Christian König schreef:
Am 23.07.2014 11:44, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have to register call
Am 23.07.2014 11:44, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter wrote:
The scheduler needs to keep track of a lot of fences, so I think we'll
have to register callbacks, not a simple wait function. We must keep
track of all the non-i915 fences for all oustanding batc
Am 23.07.2014 11:38, schrieb Maarten Lankhorst:
op 23-07-14 11:36, Christian König schreef:
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
wrote:
You submit a job to the hardware and then block the job to wait for radeon
to be finished? Well
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
wrote:
You submit a job to the hardware and then block the job to wait for radeon
to be finished? Well than this would indeed require a hardware reset, but
wouldn't that make the whole problem
Am 23.07.2014 10:54, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:46 AM, Christian König
wrote:
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
wrote:
In this case if the sync was to i915 the i915 lockup procedure would take
care of
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
wrote:
In this case if the sync was to i915 the i915 lockup procedure would take care
of itself. It wouldn't fix radeon, but it would at least unblock your intel
card again. I haven't specifically
Am 23.07.2014 10:01, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:37 AM, Christian König
wrote:
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
wrote:
It's not a locking problem I'm talking about here. Radeons lockup
handling
kic
Am 23.07.2014 10:07, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:58 AM, Christian König
wrote:
Just imagine an application using prime is locking up Radeon and because of
that gets killed by the user. Nothing else in the system would use the
Radeon hardware any more and so radeon gets
alled by another
driver waiting patiently for radeon to finish rendering which never
happens because the whole thing is locked up and we don't get a chance
to recover.
Christian.
Am 23.07.2014 09:51, schrieb Maarten Lankhorst:
op 23-07-14 09:37, Christian König schreef:
Am 23.07.
Am 23.07.2014 09:32, schrieb Maarten Lankhorst:
op 23-07-14 09:15, Christian König schreef:
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
wrote:
Can we somehow avoid the need to call fence_signal() at all? The interrupts at
least on radeon
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
wrote:
It's not a locking problem I'm talking about here. Radeons lockup handling
kicks in when anything calls into the driver from the outside, if you have a
fence wait function that's
Am 23.07.2014 09:06, schrieb Maarten Lankhorst:
op 23-07-14 08:52, Christian König schreef:
Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
op 22-07-14 17:59, Christian König schreef:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
wrote
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
wrote:
Can we somehow avoid the need to call fence_signal() at all? The interrupts at
least on radeon are way to unreliable for such a thing. Can enable_signalling
fail? What's the reason for fence_
Am 23.07.2014 08:40, schrieb Maarten Lankhorst:
op 22-07-14 17:59, Christian König schreef:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
wrote:
Drivers exporting fences need to provide a fence->signaled and a fence->wait
function, ever
Am 22.07.2014 18:21, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:59 PM, Christian König
wrote:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
wrote:
Drivers exporting fences need to provide a fence->signaled and a
fence->
Am 22.07.2014 06:05, schrieb Dave Airlie:
On 9 July 2014 22:29, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60 -
drivers/gpu/drm/radeon/radeon_fence.c | 223 +++
Am 22.07.2014 16:44, schrieb Maarten Lankhorst:
op 22-07-14 15:45, Christian König schreef:
Am 22.07.2014 15:26, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian König wrote:
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01:46:07PM +0200
Am 22.07.2014 16:27, schrieb Maarten Lankhorst:
op 22-07-14 16:24, Christian König schreef:
No, you really shouldn't be doing much in the check anyway, it's meant to be a
lightweight check. If you're not ready yet because of a lockup simply return
not signaled yet.
It's
be necessary to call copy_from_user to figure
out if a fence is signaled or not.
Returning false all the time is probably not a good idea either.
Christian.
Am 22.07.2014 16:05, schrieb Maarten Lankhorst:
op 22-07-14 14:19, Christian König schreef:
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue
Am 22.07.2014 17:17, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 3:45 PM, Christian König
wrote:
Would that be something you can agree to?
No, the whole enable_signaling stuff should go away. No callback from the
driver into the fence code, only the other way around.
fence->signaled
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
wrote:
Drivers exporting fences need to provide a fence->signaled and a fence->wait
function, everything else like fence->enable_signaling or calling
fence_signaled() from the driver is
Am 22.07.2014 16:47, schrieb Maarten Lankhorst:
op 22-07-14 16:39, Christian König schreef:
Am 22.07.2014 16:27, schrieb Maarten Lankhorst:
op 22-07-14 16:24, Christian König schreef:
No, you really shouldn't be doing much in the check anyway, it's meant to be a
lightweight check.
Am 22.07.2014 15:26, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 02:19:57PM +0200, Christian König wrote:
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote:
Am
Am 22.07.2014 13:57, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian König wrote:
Am 22.07.2014 06:05, schrieb Dave Airlie:
On 9 July 2014 22:29, Maarten Lankhorst wrote:
Signed-off-by: Maarten
Am 02.06.2014 15:14, schrieb Maarten Lankhorst:
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
---
Splitted out version, I've noticed that I forgot to convert
radeon_fence_wait_empty to long r, fixed.
drivers/gp
Am 02.06.2014 12:09, schrieb Maarten Lankhorst:
Changes since v1:
- Fixed interaction with reset handling.
+ Use exclusive_lock, either with trylock or blocking.
+ Bump sw irq refcount in the recovery function to prevent fiddling
with irq registers during gpu recovery.
- Add radeon lockup
Am 19.05.2014 15:35, schrieb Maarten Lankhorst:
op 19-05-14 14:30, Christian König schreef:
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides
Am 19.05.2014 12:10, schrieb Maarten Lankhorst:
op 19-05-14 10:27, Christian König schreef:
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
[SNIP]
The problem here is that the whole approach collides with the way we
do reset handling from a conceptual point of view. Every IOCTL or
other call
Am 19.05.2014 10:00, schrieb Maarten Lankhorst:
op 15-05-14 18:13, Christian König schreef:
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014
Am 15.05.2014 17:58, schrieb Maarten Lankhorst:
op 15-05-14 17:48, Christian König schreef:
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014
Am 15.05.2014 16:18, schrieb Maarten Lankhorst:
op 15-05-14 15:19, Christian König schreef:
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014
Am 15.05.2014 15:04, schrieb Maarten Lankhorst:
op 15-05-14 11:42, Christian König schreef:
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did
Am 15.05.2014 11:38, schrieb Maarten Lankhorst:
op 15-05-14 11:21, Christian König schreef:
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did fence get signaled after we enabled the sw irq? */
+if
(atomic64_read(&fence-&
Am 15.05.2014 03:06, schrieb Maarten Lankhorst:
op 14-05-14 17:29, Christian König schreef:
+/* did fence get signaled after we enabled the sw irq? */
+if
(atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq) {
+radeon_irq_kms_sw_
+ /* did fence get signaled after we enabled the sw irq? */
+ if (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >=
fence->seq) {
+ radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring);
+ return false;
+ }
+
+ fence->fence_wake.flag
301 - 395 of 395 matches
Mail list logo
