public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: dri-devel <dri-devel@lists.sourceforge.net>,
	Xserver development <xorg@freedesktop.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: New DRM driver model - gets rid of DRM() macros!
Date: Tue, 28 Sep 2004 11:54:35 -0400	[thread overview]
Message-ID: <9e4733910409280854651581e2@mail.gmail.com> (raw)

I've checked two new directories into DRM CVS for Linux 2.6 -
linux-core, shared-core. This code implements a new model for DRM
where DRM is split into a core piece and personality modules that
share the core. The major reason for doing this is that it allows me
to remove all of the DRM() macros; something that is causing lot's of
complaints from the Linux kernel people.

cvs -z3 -d:pserver:anonymous@dri.freedesktop.org:/cvs/dri co drm 

The patch for this is quite large, 500K, and it will mess up the Linux
2.4/BSD DRM builds since it removes the DRM() macro. Instead of doing
this as a patch I made the new CVS directories.

I've checked radeon and r128 and they work. Everything else should
work except ffb, please check the other drivers and let me know. I've
probably made some typos with a edit this large.

ffb should work in principle but since I don't own one or a Sparc
machine so I can't compile the driver. I suspect ffb has compiler
errors but the are easily fixed just by copying similar code from one
of the working modules. Please send patches.

The API between the core and personalities doesn't look to be all that
huge. With work I'd guess that 10% of the entry points could be
eliminated. After another year of development we might be able to
specify a stable core API.

What are everyone's thoughts on this? There is no technical reason it
can't be implemented on Linux 2.4/BSD, although I don't see any reason
to do it for 2.4.

Any ideas on how to generate a unique identifier for the core? It
probably should be regenerated by the Makefile whenever the core
changes. Personalities would have to match the core identifier. This
would stop people from loading binary modules that don't match the
core.

After sometime testing and fixing obvious problems I'll generate a
patch for the 2.6 kernel and lkml.

[root@smirl linux-2.6]# lsmod | more
Module                  Size  Used by
tdfx                    2816  0
sis                    10176  0
mga                    56704  0
i915                   16896  0
via                    19428  0
savage                  3840  0
r128                   44672  0
radeon                 70272  0
drm                    59684  8 tdfx,sis,mga,i915,via,savage,r128,radeon

The core provides these entry points....

[root@smirl linux-2.6]# grep EXPORT_SYMBOL *
drm_bufs.c:EXPORT_SYMBOL(drm_order);
drm_bufs.c:EXPORT_SYMBOL(drm_initmap);
drm_dma.c:EXPORT_SYMBOL(drm_core_reclaim_buffers);
drm_drv.c:EXPORT_SYMBOL(drm_cleanup_pci);
drm_drv.c:EXPORT_SYMBOL(drm_init);
drm_drv.c:EXPORT_SYMBOL(drm_exit);
drm_drv.c:EXPORT_SYMBOL(drm_open);
drm_drv.c:EXPORT_SYMBOL(drm_release);
drm_drv.c:EXPORT_SYMBOL(drm_ioctl);
drm_fops.c:EXPORT_SYMBOL(drm_flush);
drm_fops.c:EXPORT_SYMBOL(drm_fasync);
drm_init.c:EXPORT_SYMBOL(drm_flags);
drm_irq.c:EXPORT_SYMBOL(drm_irq_uninstall);
drm_irq.c:EXPORT_SYMBOL(drm_vbl_send_signals);
drm_memory.c:EXPORT_SYMBOL(drm_calloc);
drm_pci.c:EXPORT_SYMBOL(drm_pci_alloc);
drm_pci.c:EXPORT_SYMBOL(drm_pci_free);
drm_stub.c:EXPORT_SYMBOL(drm_probe);
drm_vm.c:EXPORT_SYMBOL(drm_core_get_map_ofs);
drm_vm.c:EXPORT_SYMBOL(drm_core_get_reg_ofs);

Drivers provide these callbacks......

struct drm_driver_fn {
       u32 driver_features;
       int dev_priv_size;
       int permanent_maps;
       drm_ioctl_desc_t *ioctls;
       int num_ioctls;
       int (*preinit)(struct drm_device *, unsigned long flags);
       void (*prerelease)(struct drm_device *, struct file *filp);
       void (*pretakedown)(struct drm_device *);
       int (*postcleanup)(struct drm_device *);
       int (*presetup)(struct drm_device *);
       int (*postsetup)(struct drm_device *);
       int (*dma_ioctl)( DRM_IOCTL_ARGS );
       /* these are opposites at the moment */
       int (*open_helper)(struct drm_device *, drm_file_t *);
       void (*free_filp_priv)(struct drm_device *, drm_file_t *);

       void (*release)(struct drm_device *, struct file *filp);
       void (*dma_ready)(struct drm_device *);
       int (*dma_quiescent)(struct drm_device *);
       int (*context_ctor)(struct drm_device *dev, int context);
       int (*context_dtor)(struct drm_device *dev, int context);
       int (*kernel_context_switch)(struct drm_device *dev, int old, int new);
       int (*kernel_context_switch_unlock)(struct drm_device *dev);
       int (*vblank_wait)(struct drm_device *dev, unsigned int *sequence);
/* these have to be filled in */
       int (*postinit)(struct drm_device *, unsigned long flags);
       irqreturn_t (*irq_handler)( DRM_IRQ_ARGS );
       void (*irq_preinstall)(struct drm_device *dev);
       void (*irq_postinstall)(struct drm_device *dev);
       void (*irq_uninstall)(struct drm_device *dev);
       void (*reclaim_buffers)(struct file *filp);
       unsigned long (*get_map_ofs)(drm_map_t *map);
       unsigned long (*get_reg_ofs)(struct drm_device *dev);
       void (*set_version)(struct drm_device *dev, drm_set_version_t *sv);
       int (*version)(drm_version_t *version);
};

-- 
Jon Smirl
jonsmirl@gmail.com

             reply	other threads:[~2004-09-28 15:54 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-28 15:54 Jon Smirl [this message]
2004-09-28 16:56 ` New DRM driver model - gets rid of DRM() macros! Ian Romanick
2004-09-28 17:28   ` Jon Smirl
2004-09-28 19:35   ` Helge Hafting
2004-09-28 23:10 ` Dave Airlie
2004-09-29  1:27   ` Jon Smirl
2004-09-29  2:11     ` Dave Airlie
2004-09-29  5:25       ` Jon Smirl
2004-09-29 12:37 ` Christoph Hellwig
2004-09-29 11:59   ` Alan Cox
2004-09-29 13:16     ` Dave Airlie
2004-09-29 13:29   ` Keith Whitwell
2004-09-29 13:31     ` Christoph Hellwig
2004-09-29 13:35       ` Keith Whitwell
2004-09-29 14:12         ` Keith Whitwell
2004-09-29 14:16           ` Christoph Hellwig
2004-09-29 14:27             ` Keith Whitwell
2004-09-29 14:39               ` Keith Whitwell
2004-09-29 19:16                 ` Keith Packard
2004-09-30 18:10         ` Jon Smirl
2004-09-29 13:41   ` Dave Airlie
2004-10-01  5:15   ` Jon Smirl
2004-09-29 14:25 ` Keith Whitwell
2004-09-30  0:00   ` Eric Anholt
2004-09-29 21:52 ` Felix Kühling
2004-09-29 21:02   ` Alan Cox
2004-09-29 23:25   ` Jon Smirl
     [not found]     ` <20041006133714.GA26860@localdomain>
     [not found]       ` <9e47339104100609307307f8ea@mail.gmail.com>
     [not found]         ` <20041006211922.GA5167@localdomain>
2004-10-06 21:46           ` Code status (Was: New DRM driver model - gets rid of DRM() macros!) Ian Romanick

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e4733910409280854651581e2@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=dri-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xorg@freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox