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.
On Sat, 22 Dec 2001 20:36:02 +0100,
Christoph Hellwig <[email protected]> wrote:
>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.
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 $@ $^
On Sun, Dec 23, 2001 at 10:48:36AM +1100, Keith Owens wrote:
> Only if the new version cleans up the horrible drm 4.0 Makefile.
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.
On Sun, 23 Dec 2001 13:28:24 +0100,
Christoph Hellwig <[email protected]> wrote:
>On Sun, Dec 23, 2001 at 10:48:36AM +1100, Keith Owens wrote:
>> Only if the new version cleans up the horrible drm 4.0 Makefile.
>
>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..
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.
On Sun, Dec 23, 2001 at 10:48:36AM +1100, Keith Owens wrote:
> 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.
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.
> Some of the code in $(drmlib-4.0-objs) will need EXPORT_SYMBOLS to work
> when drm 4.0 drivers are compiled as modules.
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.
On Sun, 23 Dec 2001 13:54:17 +0100,
Christoph Hellwig <[email protected]> wrote:
>On Sun, Dec 23, 2001 at 10:48:36AM +1100, Keith Owens wrote:
>> needs the separate copy of drmlib. I will not maintain that crud into
>> kbuild 2.5.
>
>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.
>
>> Some of the code in $(drmlib-4.0-objs) will need EXPORT_SYMBOLS to work
>> when drm 4.0 drivers are compiled as modules.
>
>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.
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.