DRM 4.0 support for kernel 2.4.17

I've placed a patch to allow optional drm 4.0 support in kernel 2.4.17 at:

ftp.kernel.org/pub/linux/kernel/people/hch/patches/v2.4/2.4.17/linux-2.4.17-drm40.patch.bz2

Please report any fedback to me. It has been submitted to Marcelo for inclusion into 2.4.18.

Christoph

Of course it doesn't work. We've performed a software upgrade.

Only if the new version cleans up the horrible drm 4.0 Makefile. The separate copy of drmlib in each object and/or the kernel goes against the rest of the kbuild design, needs an ugly makefile and AFAICT nobody needs the separate copy of drmlib. I will not maintain that crud into kbuild 2.5.

drivers/char/drm-4.0/Makefile below uses the standard kbuild design. One copy of drmlib-4.0 which is built into the kernel if any drm 4.0 drivers are built in, otherwise drmlib-4.0 is a module if there are any drm 4.0 modules. Totally untested.

Some of the code in $(drmlib-4.0-objs) will need EXPORT_SYMBOLS to work when drm 4.0 drivers are compiled as modules.

#
# Makefile for the drm device driver. This driver provides support for

# the Direct Rendering Infrastructure (DRI) in XFree86 4.x.
#

O_TARGET := drm.o

export-objs     := gamma_drv.o tdfx_drv.o r128_drv.o ffb_drv.o mga_drv.o \
		   i810_drv.o

list-multi := gamma.o tdfx.o r128.o ffb.o mga.o i810.o drmlib-4.0
gamma-objs := gamma_drv.o gamma_dma.o
tdfx-objs := tdfx_drv.o tdfx_context.o
r128-objs := r128_drv.o r128_cce.o r128_context.o r128_bufs.o r128_state.o
ffb-objs := ffb_drv.o ffb_context.o
mga-objs := mga_drv.o mga_dma.o mga_context.o mga_bufs.o mga_state.o
i810-objs := i810_drv.o i810_dma.o i810_context.o i810_bufs.o
radeon-objs := radeon_drv.o radeon_cp.o radeon_context.o radeon_bufs.o radeon_state.o
drmlib-4.0-objs := init.o memory.o proc.o auth.o context.o drawable.o bufs.o \
lists.o lock.o ioctl.o fops.o vm.o dma.o ctxbitmap.o

ifneq ($(subst n,,$(CONFIG_AGP)),)
drmlib-4.0-objs += agpsupport.o
endif

obj-$(CONFIG_DRM40_GAMMA) += gamma.o drmlib-4.0.o
obj-$(CONFIG_DRM40_TDFX) += tdfx.o drmlib-4.0.o
obj-$(CONFIG_DRM40_R128) += r128.o drmlib-4.0.o
obj-$(CONFIG_DRM40_RADEON)+= radeon.o drmlib-4.0.o

obj-$(CONFIG_DRM40_FFB)   += ffb.o	drmlib-4.0.o
obj-$(CONFIG_DRM40_MGA)   += mga.o	drmlib-4.0.o
obj-$(CONFIG_DRM40_I810)  += i810.o	drmlib-4.0.o

include $(TOPDIR)/Rules.make

drmlib-4.0.o: $(drmlib-4.0-objs)

	$(LD) -r -o $@ $^

gamma.o: $(gamma-objs)

	$(LD) -r -o $@ $^

tdfx.o: $(tdfx-objs)

	$(LD) -r -o $@ $^

mga.o: $(mga-objs)

	$(LD) -r -o $@ $^

i810.o: $(i810-objs)

	$(LD) -r -o $@ $^

r128.o: $(r128-objs)

	$(LD) -r -o $@ $^

radeon.o: $(radeon-objs)

	$(LD) -r -o $@ $^

ffb.o: $(ffb-objs)

	$(LD) -r -o $@ $^

I am more than happy to do so. In fact I already did in 2.4.0-test times and got flamed by the drm crew..

Christoph

Of course it doesn't work. We've performed a software upgrade.

Don't see why. drm 4.1 uses a sane makefile, apart from a few dead references to $(lib) which do nothing. The separate copy of drmlib in each object was meant to allow migration to a new format, it obviously failed in its task, drm 4.1 is not compatible. From drm 4.0 Makefile

# The upside is that if the DRM support library ever becomes insufficient

# for new families of cards, a new library can be implemented for those new
# cards without impacting the drivers for the old cards.  This is significant,
# because testing architectural changes to old cards may be impossible, and
# may delay the implementation of a better architecture.  We've traded slight
# memory waste (in the dual-head case) for greatly improved long-term
# maintainability.

Nice definition of long term, it survived 0 new releases. Kill it.

ftp.kernel.org/pub/linux/kernel/people/hch/patches/v2.4/2.4.17/linux-2.4.17-drm40-1.patch.bz2

Is a version that is (build-) tested and very similar to your versions, based on my 2.4.0-test Makefile.

I don't consider that a good use of drm 4.0. If someone wants to fix it anyway he/she should do it. I don't think this compatiblity code needs so much attention.

Christoph

Of course it doesn't work. We've performed a software upgrade.

Looks good to me. The first person who wants drm-4.0 support as a module has some work to do. ia64 defconfig has drm-4.0 tdfx built in, no problem there.