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_irq_put(fence-rdev, fence
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-rdev-fence_drv
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 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 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 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 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 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 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 maarten.lankho...@canonical.com
---
Splitted out version, I've noticed that I forgot to convert
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 maarten.lankho...@canonical.com wrote
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 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
christian.koe...@amd.com 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
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, Jul 22, 2014 at 01
Am 22.07.2014 17:17, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 3:45 PM, Christian König
deathsim...@vodafone.de 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
Vetter:
On Tue, Jul 22, 2014 at 5:59 PM, Christian König
deathsim...@vodafone.de wrote:
Am 22.07.2014 17:42, schrieb Daniel Vetter:
On Tue, Jul 22, 2014 at 5:35 PM, Christian König
christian.koe...@amd.com wrote:
Drivers exporting fences need to provide a fence-signaled and a
fence-wait
function
Am 22.07.2014 06:05, schrieb Dave Airlie:
On 9 July 2014 22:29, Maarten Lankhorst maarten.lankho...@canonical.com wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60
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 not only the lockup
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
christian.koe...@amd.com wrote:
Drivers exporting fences need to provide a fence-signaled and a fence-wait
Am 23.07.2014 09:09, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:06 AM, Maarten Lankhorst
maarten.lankho...@canonical.com 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
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
christian.koe
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@vodafone.de 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
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.2014 09:31
Am 23.07.2014 10:07, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:58 AM, Christian König
deathsim...@vodafone.de 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
Am 23.07.2014 10:01, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:37 AM, Christian König
christian.koe...@amd.com wrote:
Am 23.07.2014 09:31, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 9:26 AM, Christian König
deathsim...@vodafone.de wrote:
It's not a locking problem I'm talking about
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@canonical.com 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
Am 23.07.2014 10:54, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:46 AM, Christian König
deathsim...@vodafone.de wrote:
Am 23.07.2014 10:42, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 10:25 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
In this case if the sync
Am 23.07.2014 11:30, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:27 AM, Christian König
christian.koe...@amd.com 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
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
christian.koe...@amd.com wrote:
You submit a job to the hardware and then block the job to wait for radeon
Am 23.07.2014 11:44, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 11:39 AM, Daniel Vetter daniel.vet...@ffwll.ch 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
Am 23.07.2014 12:52, schrieb Daniel Vetter:
On Wed, Jul 23, 2014 at 12:13 PM, Christian König
christian.koe...@amd.com 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
into 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 at 12
[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
Am 31.07.2014 um 17:33 schrieb Maarten Lankhorst:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
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.
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 maarten.lankho...@canonical.com
---
V1 had
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 schrieb
.
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 01.08.2014 um 19:46
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 only running
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 other solutions
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 pain
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
Am 01.01.2018 um 19:08 schrieb Ilia Mirkin:
On Sun, Dec 31, 2017 at 3:53 PM, Mike Galbraith <efa...@gmx.de> 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
<ckoenig.leichtzumer...@gmail.com> wrote:
Am 19.12.2017 um 1
: Christian König <christian.koe...@amd.com>
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
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
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
. 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 TODO list to clean
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
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 user
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 König
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 | 1
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
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 | 43
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
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
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
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
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
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 actually
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,
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
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 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
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
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/drm/amd
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 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
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
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
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
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
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
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
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
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 deprecate
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 loss
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 loss
Hi Dan,
Am 09.09.20 um 13:49 schrieb Dan Carpenter:
Hello Christian König,
The patch 141b15e59175: "drm/nouveau: move io_reserve_lru handling
into the driver v5" from Aug 21, 2020, leads to the following static
checker warning:
drivers/gpu/drm/nouveau/nouveau
Added my rb to the amdgpu and radeon patches.
Should we pick those up through the amd branches or do you want to push
everything to drm-misc-next?
I think the later since this should result in much merge clash.
Christian.
Am 15.09.20 um 16:59 schrieb Thomas Zimmermann:
The GEM and PRIME
ULL)
return -ENOMEM;
+
The newline is not unrelated.
Apart from that the patch is Reviewed-by: Christian König
.
But I think we need some smoke testing of it.
Christian.
drm_gem_private_object_init(adev_to_drm(adev), >tbo.base, size);
)
* set callbacks in radeon_gem_object_create() (Christian)
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/radeon/radeon_drv.c | 23 +
drivers/gpu/drm/radeon/radeon_gem.c | 31 +
2 files changed, 28
We are trying to remove the io_lru handling and depend
on zero init base, offset and addr here.
v2: init addr as well
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm
ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve
v3: rebased and use both base and offset in the check
v4: fix small typos and test the patch
v5: rebased and keep the mem.bus init in TTM.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 101
From: Christian König
That is not used any more.
v2: keep the NULL checks in TTM.
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ttm/ttm_bo.c | 34 +
drivers/gpu/drm/ttm/ttm_bo_util.c | 113 +++--
drivers/gpu/drm/ttm
Am 15.10.20 um 19:52 schrieb Thomas Zimmermann:
Hi
On Thu, 15 Oct 2020 18:49:09 +0200 Daniel Vetter wrote:
On Thu, Oct 15, 2020 at 04:08:13PM +0200, Christian König wrote:
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO
The amdgpu changes look good to me, but I can't fully judge the other stuff.
Acked-by: Christian König
---
Documentation/gpu/todo.rst | 18
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 36 ---
drivers/gpu/drm
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function etnaviv_gem_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 1 -
drivers
Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
address space. The mapping's address is returned as struct dma_buf_map.
Each function is a simplified version of TTM's existing kmap code. Both
functions respect the memory's
ann
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 3213429f8444..2d5ed3051
Am 15.10.20 um 14:37 schrieb Thomas Zimmermann:
The function drm_gem_cma_prime_vunmap() is empty. Remove it before
changing the interface to use struct drm_buf_map.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_gem_cma_helper.c | 17
-by: Thomas Zimmermann
Acked-by: Christian König
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 12
drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
PM Christian König
wrote:
Am 30.09.20 um 11:47 schrieb Daniel Vetter:
On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
Am 30.09.20 um 10:19 schrieb Thomas Zimmermann:
Hi
Am 30.09.20 um 10:05 schrieb Christian König:
Am 29.09.20 um 19:49 schrieb Thomas Zimmermann:
Hi
Hi Thomas,
[SNIP]
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = >mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem
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
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
We are trying to remove the io_lru handling and depend
on zero init base and offset here.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e3931e515906
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 | 34 ++---
drivers/gpu/drm/ttm/ttm_bo_util.c | 108 +
drivers/gpu/drm/ttm/ttm_bo_vm.c| 39
ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve
v3: rebased and use both base and offset in the check
v4: fix small typos and test the patch
Signed-off-by: Christian König
Acked-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 111 --
drivers/gpu/drm/nouveau/nouveau_bo.h
Hi guys,
so I got some hardware and tested this and after hammering out tons of typos it
now seems to work fine.
Could you give it more testing?
Thanks in advance,
Christian
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
1 - 100 of 385 matches
Mail list logo
