similar to: [RFC] Remove AGP support from Radeon/Nouveau/TTM

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 -

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 general AGP support is available. Please comment, Christian.

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

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 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

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 ++++++++

The wrong values are reported from pcie_bandwidth_available() which can cause problems for performance of eGPUs. This series overhauls Thunderbolt related device detection and uses the changes to change the behavior of pcie_bandwidth_available(). v2->v3: * Stop lumping all thunderbolt VSEC and USB4 devices together, introduce is_virtual_link instead * Drop unnecessary patches Mario

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 with the way >>>>

> -----Original Message----- > From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com] > Sent: Wednesday, July 09, 2014 8:30 AM > To: airlied at linux.ie > Cc: thellstrom at vmware.com; nouveau at lists.freedesktop.org; linux- > kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; > bskeggs at redhat.com; Deucher, Alexander; Koenig, Christian >

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 detection to the default fence wait function. First of all please

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 15:04, schrieb

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 >>>>>

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.lankhorst at canonical.com> > --- > Splitted out version, I've noticed that I forgot to convert > radeon_fence_wait_empty to long r, fixed. >

Rework fbdev probing to support fbdev_probe in struct drm_driver and remove the old fb_probe callback. Provide an initializer macro for struct drm_driver that sets the callback according to the kernel configuration. Call drm_client_setup() to run the kernel's default client setup for DRM. Set fbdev_probe in struct drm_driver, so that the client setup can start the common fbdev client. The

Joe Perches (2): drm: Use pr_cont where appropriate gpu: drm: Convert printk(KERN_<LEVEL> to pr_<level> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +-

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 ---

Am 23.07.2014 12:52, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig > <christian.koenig at 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 as the driver can do >> everything

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 <ddadap at nvidia.com> --- drivers/gpu/drm/radeon/radeon_combios.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c

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 to deal

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