similar to: [RFC] Deprecate AGP GART support for Radeon/Nouveau/TTM

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 only enable it if > there is a good reason to do so. > > Signed-off-by: Christian K?nig <christian.koenig at

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 driver specific page tables etc etc... So the idea here is to just go ahead and remove the support

Hi Christian Am 11.05.20 um 19:17 schrieb Christian K?nig: > 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 <christian.koenig at amd.com> > --- > drivers/gpu/drm/radeon/Makefile | 4 +- > drivers/gpu/drm/radeon/evergreen.c | 7 -

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 <christian.koenig at amd.com> --- drivers/gpu/drm/Kconfig | 8 ++++++++

On Mon, May 11, 2020 at 1:17 PM Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > AGP is deprecated for 10+ years now and not used any more on modern hardware. > > Old hardware should continue to work in PCI mode. Might want to clarify that there is no loss of functionality here. Something like: "There is no loss of functionality here. GPUs will continue to

On Wed, May 20, 2020 at 10:43 AM Christian K?nig <ckoenig.leichtzumerken at gmail.com> 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 in functionality since drivers will just fallback to the driver

The NULL initialization of the pointers assigned by kzalloc() or kunit_kzalloc() first is not necessary, because if the kzalloc() or kunit_kzalloc() failed, the pointers will be assigned NULL, otherwise it works as usual. so remove it. Ruan Jinjie (7): drm/amdkfd: Remove unnecessary NULL values drm/amd/display: Remove unnecessary NULL values drm/msm: Remove unnecessary NULL values

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 <christian.koenig at amd.com> --- drivers/gpu/drm/radeon/Makefile | 4 +- drivers/gpu/drm/radeon/evergreen.c | 7 - drivers/gpu/drm/radeon/r100.c | 10 +- drivers/gpu/drm/radeon/r300.c | 9 -

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 in functionality since >> drivers will just fallback to the driver specific PCI GART. >> >> For now

Hi guys, I already tried this a few month ago, but since I don't have NVidia hardware its rather hard to test for me (need to get some ordered). Dave brought up the topic that we should probably try to move the handling into Nouveau once more, so I tried to fix the problem Ben reported and rebased on top of current drm-misc-next. Dave can you test this? At least in theory the approach

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. :-) I've done at least basic

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma 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:

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma 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:

Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma 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:

fence_is_signaled callback should support being run in atomic context, but not in irq context. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- include/linux/fence.h | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/include/linux/fence.h b/include/linux/fence.h index d174585b874b..c1a4519ba2f5 100644 ---

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, Christian.

This series depends on the previously posted reservation api patches. 2 of them are not yet in for-next-fences branch of git://git.linaro.org/people/sumit.semwal/linux-3.x.git The missing patches are still in my vmwgfx_wip branch at git://people.freedesktop.org/~mlankhorst/linux All ttm drivers are converted to the fence api, fence_lock is removed and rcu is used in its place. qxl is the first

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

TTM uses global memory and BO for backing graphics buffers. These are represented by struct ttm_mem_global and struct ttm_bo_global. Currently, struct ttm_bo_global can only be initialized and released through struct ttm_bo_global_ref. This is a workaround for passing an instance of ttm_mem_global to the BO global initialization code. The use of struct ttm_bo_global_ref makes driver code

v2 was doing some pretty nasty things with the DMA API, so I took a different approach for this v3. As suggested, this version uses ttm_dma_populate() to populate BOs. The reason for doing this was that it would entitle us to using the DMA sync functions, but since the memory returned is already coherent anyway, we do not even need to call these functions anymore. So this series has turned into