Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Fri, Oct 15, 2004 at 11:40:30AM -0400, Jon Smirl wrote: On Fri, 15 Oct 2004 15:19:41 +0100, José Fonseca [EMAIL PROTECTED] wrote: It doesn't say nothing and I found (partially) why: the dynamic lynking is failing, so the call to drm_init(pci_driver, pciidlist, driver) never reaches a single line of code there (no debug message, *nothing*). Could it be symbol versioning? I've diffed my two machines kernel config files and symbol versioning was one of the suspicious differences indeed, but I only managed to get everything working as expected after disabling some of those kernel hacking options too. Things behave weirdly if you have an old drm module loaded and load the new ones too. You should at least get a sign on: [drm] Initialized drm 1.0.0 20040925 Yes, this message always appeared when loading drm.ko. That the very first thing the drm module does. If you sync from CVS you need to use... insmod ./drm.ko drm_debug=1 Thanks for your help. This issue is finally closed. Regards, José Fonseca --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Mon, Oct 11, 2004 at 10:52:40AM -0400, Jon Smirl wrote: What does dmesg say? There should be some debugging data in the log. drm loads right? which personality is failing? It doesn't say nothing and I found (partially) why: the dynamic lynking is failing, so the call to drm_init(pci_driver, pciidlist, driver) never reaches a single line of code there (no debug message, *nothing*). I still don't know how this can be (the kernel configuration, or software setup, maybe), but I'm more inclined toward a problem on my end, rather than in *-core code. I'll still try sorting this out, so that I can move on to more interesting things. José Fonseca --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Fri, 15 Oct 2004 15:19:41 +0100, José Fonseca [EMAIL PROTECTED] wrote: It doesn't say nothing and I found (partially) why: the dynamic lynking is failing, so the call to drm_init(pci_driver, pciidlist, driver) never reaches a single line of code there (no debug message, *nothing*). Could it be symbol versioning? Things behave weirdly if you have an old drm module loaded and load the new ones too. You should at least get a sign on: [drm] Initialized drm 1.0.0 20040925 That the very first thing the drm module does. If you sync from CVS you need to use... insmod ./drm.ko drm_debug=1 -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Wed, Oct 06, 2004 at 05:51:41PM -0400, Jon Smirl wrote: For debug info: insmod ./drm.ko drm_opts=debug:on insmod ./radeon.ko drm_opts=debug:on I haven't fully writen the code for the new parameters yet. When it is finished the message will disappear. Make sure you don't have any old DRM drivers loaded by accident or compiled into your kernel. If you do the symbols will be all messed up and who know where the code will jump. Sometimes the drm/radeon pair will still load even if an old version is in memory. Try a sequence like this: [EMAIL PROTECTED] linux-core]# insmod ./drm.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# rmmod drm [EMAIL PROTECTED] linux-core]# This runs for me without errors. This still fails on me. I've checked on another machine, with the same kernel but different hardware and kernel configuration, and it does works fint. I don't suppose any processor-specific assembly was added to the *-core, so I'm inclined towards any conflict with this machine kernel's configuration. FYI it's an AMD K6. I'll try to backtrack in the *-core to determine when the problem happened. Any other hints to hunt this bug down? José Fonseca --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Mon, 11 Oct 2004 11:56:27 +0100, José Fonseca [EMAIL PROTECTED] wrote: I've checked on another machine, with the same kernel but different hardware and kernel configuration, and it does works fint. I don't suppose any processor-specific assembly was added to the *-core, so I'm inclined towards any conflict with this machine kernel's configuration. FYI it's an AMD K6. I'll try to backtrack in the *-core to determine when the problem happened. Any other hints to hunt this bug down? What does dmesg say? There should be some debugging data in the log. drm loads right? which personality is failing? -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Code status (Was: New DRM driver model - gets rid of DRM() macros!)
Jon, I was trying to build and test the linux-core - I really like what you've been doing there - but I get endless kernel oops after insmod'ing any of the driver modules (not the common drm one though), regardless the specific chip is present or not. Before I search deeper into this could you let me know whether the code in *-core is not runnable yet, or if there must be something wrong on my side? Regards, José Fonseca --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Wed, 6 Oct 2004, [iso-8859-15] José Fonseca wrote: Jon, I was trying to build and test the linux-core - I really like what you've been doing there - but I get endless kernel oops after insmod'ing any of the driver modules (not the common drm one though), regardless the specific chip is present or not. Before I search deeper into this could you let me know whether the code in *-core is not runnable yet, or if there must be something wrong on my side? Just as a data point I was able to insert radeon module just fine on 2.6.9rc3. This was yesterday. Maybe a fresh checkout will help ? best Vladimir Dergachev Regards, José Fonseca --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Wed, Oct 06, 2004 at 09:53:51AM -0400, Vladimir Dergachev wrote: On Wed, 6 Oct 2004, [iso-8859-15] José Fonseca wrote: Jon, I was trying to build and test the linux-core - I really like what you've been doing there - but I get endless kernel oops after insmod'ing any of the driver modules (not the common drm one though), regardless the specific chip is present or not. Before I search deeper into this could you let me know whether the code in *-core is not runnable yet, or if there must be something wrong on my side? Just as a data point I was able to insert radeon module just fine on 2.6.9rc3. This was yesterday. Maybe a fresh checkout will help ? Inserting mga worked on 2.6.7 for me. Unfortunately actually using the module failed. The problem is with get_order() in drm_bufs.c. After I replaced get_order() with the original drm order function things started to work. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
I'll revert these to the old DRM(order). One of the kernel developers wanted this changed and now I see these functions aren't identical. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Wed, 6 Oct 2004 12:14:05 -0400, Jon Smirl [EMAIL PROTECTED] wrote: I'll revert these to the old DRM(order). One of the kernel developers wanted this changed and now I see these functions aren't identical. This is checked in now. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Wed, 6 Oct 2004 14:37:14 +0100, José Fonseca [EMAIL PROTECTED] wrote: Jon, I was trying to build and test the linux-core - I really like what you've been doing there - but I get endless kernel oops after insmod'ing any of the driver modules (not the common drm one though), regardless the specific chip is present or not. Before I search deeper into this could you let me know whether the code in *-core is not runnable yet, or if there must be something wrong on my side? What kernel version? What is the OOPs? Be sure and try with the current CVS. Bugs are getting fixed as fast as people are reporting them. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
On Wed, Oct 06, 2004 at 12:30:01PM -0400, Jon Smirl wrote: On Wed, 6 Oct 2004 14:37:14 +0100, José Fonseca [EMAIL PROTECTED] wrote: Jon, I was trying to build and test the linux-core - I really like what you've been doing there - but I get endless kernel oops after insmod'ing any of the driver modules (not the common drm one though), regardless the specific chip is present or not. Before I search deeper into this could you let me know whether the code in *-core is not runnable yet, or if there must be something wrong on my side? What kernel version? kernel version 2.6.8, from debian unstable. What is the OOPs? They are not reproducible, i.e., they are always different every run, on a different entry point. They happen one after the other so fast that they're never recorded on /proc/kmsg. I got a screenshot (literaly, with a digital camera) on http://jrfonseca.dyndns.org/misc/bugs/radeon-core.jpg after insmod'ing radeon. It's likely that the first oops is within the loaded module, but all the others oops trash it away... I also add that insmod'ing mach64 or radeon from the linux-2.6 works just fine, so it must be some regression in linux-core. Be sure and try with the current CVS. Bugs are getting fixed as fast as people are reporting them. On Wed, Oct 06, 2004 at 09:53:51AM -0400, Vladimir Dergachev wrote: Just as a data point I was able to insert radeon module just fine on 2.6.9rc3. This was yesterday. Maybe a fresh checkout will help ? best Vladimir Dergachev I've tracking the CVS closely for the last 2 days, but nothing changed so far. I'll try with 2.6.9 too see if it changes anything. I noticed the Ignoring new-style parameters in presence of obsolete ones warnings. What is the de-facto way to enable extra debugging info in linux-core modules? José Fonseca --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Code status (Was: New DRM driver model - gets rid of DRM() macros!)
For debug info: insmod ./drm.ko drm_opts=debug:on insmod ./radeon.ko drm_opts=debug:on I haven't fully writen the code for the new parameters yet. When it is finished the message will disappear. Make sure you don't have any old DRM drivers loaded by accident or compiled into your kernel. If you do the symbols will be all messed up and who know where the code will jump. Sometimes the drm/radeon pair will still load even if an old version is in memory. Try a sequence like this: [EMAIL PROTECTED] linux-core]# insmod ./drm.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# insmod ./radeon.ko drm_opts=debug:on [EMAIL PROTECTED] linux-core]# rmmod radeon [EMAIL PROTECTED] linux-core]# rmmod drm [EMAIL PROTECTED] linux-core]# This runs for me without errors. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Patch removes DRM flush, poll, read functions. It leave the fops entry
null so that the OS default function will be used.
The fops table is converted to be one per driver instead of a global.
This fixes the module open ref count problem. It also simplifies
i810/830 by allow them to directly patch their mmap function into the
fops table.
I spent two days looking for a bug in DRM with multiple drivers under
X. I don't think DRM has problems. I see now that X also fails if two
older DRM drivers are loaded. The first problem seems to be the X's
DRM lock refcount varibale is a static. That won't work for two DRM
drivers.
--
Jon Smirl
[EMAIL PROTECTED]
= linux-core/drmP.h 1.2 vs edited =
--- 1.2/linux-core/drmP.h 2004-09-28 18:26:13 -04:00
+++ edited/linux-core/drmP.h 2004-09-30 13:34:40 -04:00
@@ -523,11 +523,6 @@
struct drm_device;
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 *);
@@ -558,6 +553,13 @@
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);
+/* variables */
+ u32 driver_features;
+ int dev_priv_size;
+ int permanent_maps;
+ drm_ioctl_desc_t *ioctls;
+ int num_ioctls;
+ struct file_operations fops;
};
@@ -691,8 +693,6 @@
drm_sigdata_t sigdata; /** For block_all_signals */
sigset_t sigmask;
- struct file_operations *fops; /** file operations */
-
struct drm_driver_fn *fn_tbl;
drm_local_map_t *agp_buffer_map;
} drm_device_t;
@@ -757,13 +757,11 @@
extern int drm_fill_in_dev(drm_device_t *dev, struct pci_dev *pdev,
const struct pci_device_id *ent, struct drm_driver_fn *driver_fn);
extern int drm_fb_loaded;
-extern struct file_operations drm_fops;
/* Device support (drm_fops.h) */
extern int drm_open_helper(struct inode *inode, struct file *filp,
drm_device_t *dev);
-extern int drm_flush(struct file *filp);
-extern int drm_fasync(int fd, struct file *filp, int on);
+extern int drm_fasync(int fd, struct file *filp, int on);
/* Mapping support (drm_vm.h) */
extern void drm_vm_open(struct vm_area_struct *vma);
@@ -772,8 +770,6 @@
extern int drm_mmap_dma(struct file *filp,
struct vm_area_struct *vma);
extern int drm_mmap(struct file *filp, struct vm_area_struct *vma);
-extern unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait);
-extern ssize_t drm_read(struct file *filp, char __user *buf, size_t count, loff_t *off);
/* Memory management support (drm_memory.h) */
#include drm_memory.h
= linux-core/drm_drv.c 1.2 vs edited =
--- 1.2/linux-core/drm_drv.c 2004-09-28 18:26:13 -04:00
+++ edited/linux-core/drm_drv.c 2004-09-30 13:34:40 -04:00
@@ -76,18 +76,6 @@
int drm_fb_loaded = 0;
-struct file_operations drm_fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .flush = drm_flush,
- .release = drm_release,
- .ioctl = drm_ioctl,
- .mmap = drm_mmap,
- .fasync = drm_fasync,
- .poll = drm_poll,
- .read = drm_read,
-};
-
/** Ioctl table */
drm_ioctl_desc_t drm_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_VERSION)] = { drm_version, 0, 0 },
@@ -384,7 +372,6 @@
sema_init( dev-ctxlist_sem, 1 );
dev-name = DRIVER_NAME;
- dev-fops = drm_fops;
dev-pdev = pdev;
#ifdef __alpha__
@@ -630,7 +617,7 @@
minor = drm_minors[i];
dev = minor-dev;
DRM_DEBUG(fb loaded release minor %d\n, dev-minor);
- if ((minor-class == DRM_MINOR_PRIMARY) (dev-fops == drm_fops)) {
+ if (minor-class == DRM_MINOR_PRIMARY) {
/* release the pci driver */
if (dev-pdev)
pci_dev_put(dev-pdev);
= linux-core/drm_fops.c 1.1 vs edited =
--- 1.1/linux-core/drm_fops.c 2004-09-28 13:03:33 -04:00
+++ edited/linux-core/drm_fops.c 2004-09-30 13:56:18 -04:00
@@ -116,18 +116,6 @@
}
/** No-op. */
-int drm_flush(struct file *filp)
-{
- drm_file_t*priv = filp-private_data;
- drm_device_t *dev= priv-dev;
-
- DRM_DEBUG(pid = %d, device = 0x%lx, open_count = %d\n,
- current-pid, (long)old_encode_dev(dev-device), dev-open_count);
- return 0;
-}
-EXPORT_SYMBOL(drm_flush);
-
-/** No-op. */
int drm_fasync(int fd, struct file *filp, int on)
{
drm_file_t*priv = filp-private_data;
@@ -140,16 +128,3 @@
return 0;
}
EXPORT_SYMBOL(drm_fasync);
-
-/** No-op. */
-unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait)
-{
- return 0;
-}
-
-
-/** No-op. */
-ssize_t drm_read(struct file *filp, char __user *buf, size_t count, loff_t *off)
-{
- return 0;
-}
= linux-core/drm_stub.c 1.1 vs edited =
--- 1.1/linux-core/drm_stub.c 2004-09-28 13:03:33 -04:00
+++ edited/linux-core/drm_stub.c 2004-09-30 13:13:25 -04:00
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 29 Sep 2004 13:37:59 +0100, Christoph Hellwig [EMAIL PROTECTED] wrote: Some ideas that would be nice improvements still (not that some may be inherited from the old drm code, I just looked at the CVS checkout): - once we have Alan's idea of the graphics core implemented drm_init() should go awaw - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy, what about doing the full -probe callback in each driver where it can do basic hw setup, dealing with pci and calls back into the drm core for minor number allocation and common structure allocations. This would get rid of the -preinit and -postinit hooks. This has to stay the way it currently is because of the stealth mode code - isn't drm_order just a copy of get_order()? switched to get_order - any chance to use proper kernel-doc comments instead of the bastdized and hard to read version you have currently? doc people don't want to switch - the coding style is a little strange, like spurious whitespaces inside braces, maybe you could run it through scripts/Lindent ran most of it through Lindent. check out CVS for results. - care to use linux/lists.h instead of opencoded lists, e.g. in dev-file_last/dev-file_first or dev-vmalist There are about 20 open coded lists. I started to fix some of these but the code involved can be touchy and it's already well tested. It would be better to wait on these until someone is working on the code involved. I don't want to introduce bugs because I don't understand the code 100%. - drm_flush is a noop. a NULL -flush does the same thing, just easier - dito or -poll - dito for -read Changed these to use kernel defaults. - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code? That can probably be fixed. I believe it is because it is hiding a 2.4/2.6 change. - drm__mem_info should be converted to fs/seq_file.c functions - dito for functions in drm_proc.c I started to do this to but I didn't want to disrupt know working code. These may get rewritten for sysfs. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Still need someone with a Sparc machine to fix the ffb compile. I've got a cross compiler installed at home for just this purpose .. I'll work on it this evening.. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Tue, Sep 28, 2004 at 11:54:35AM -0400, Jon Smirl wrote: 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. I gave it a quick look and it looks great so far. Some ideas that would be nice improvements still (not that some may be inherited from the old drm code, I just looked at the CVS checkout): - once we have Alan's idea of the graphics core implemented drm_init() should go awaw - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy, what about doing the full -probe callback in each driver where it can do basic hw setup, dealing with pci and calls back into the drm core for minor number allocation and common structure allocations. This would get rid of the -preinit and -postinit hooks. - isn't drm_order just a copy of get_order()? - any chance to use proper kernel-doc comments instead of the bastdized and hard to read version you have currently? - the coding style is a little strange, like spurious whitespaces inside braces, maybe you could run it through scripts/Lindent - care to use linux/lists.h instead of opencoded lists, e.g. in dev-file_last/dev-file_first or dev-vmalist - drm_flush is a noop. a NULL -flush does the same thing, just easier - dito or -poll - dito for -read - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code? - drm__mem_info should be converted to fs/seq_file.c functions - dito for functions in drm_proc.c --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Mer, 2004-09-29 at 13:37, Christoph Hellwig wrote: - once we have Alan's idea of the graphics core implemented drm_init() should go awaw Last I heard Dave Airlie had that working having fixed my bugs. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
I have the basics working alright, my only issue was with getting proper sysfs with it, I'll dig up my latest version and post it, I've also got a ported DRM for it, at the moment it was doing something like /sys/devices/vga00 /sys/devices/vga01 one for each user of the card (multi-card would look really ugly) whereas what we probably want is a directory per card along the lines of /sys/device/vga0 /vga1 and then links 0-x for each registered driver or maybe even links like common, dri , fb0 (make the names meaningful as they do have one...) Dave. On Wed, 29 Sep 2004 12:59:55 +0100, Alan Cox [EMAIL PROTECTED] wrote: On Mer, 2004-09-29 at 13:37, Christoph Hellwig wrote: - once we have Alan's idea of the graphics core implemented drm_init() should go awaw Last I heard Dave Airlie had that working having fixed my bugs. ___ xorg mailing list [EMAIL PROTECTED] http://freedesktop.org/mailman/listinfo/xorg --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Christoph Hellwig wrote: - drm_flush is a noop. a NULL -flush does the same thing, just easier - dito or -poll - dito for -read Pretty sure you couldn't get away with null for these in 2.4, at least. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, Sep 29, 2004 at 02:29:24PM +0100, Keith Whitwell wrote: Christoph Hellwig wrote: - drm_flush is a noop. a NULL -flush does the same thing, just easier - dito or -poll - dito for -read Pretty sure you couldn't get away with null for these in 2.4, at least. Umm, of course you could. There's only a hanfull instance defining a -flush at all. Similarly all file_ops for regular files and many char devices don't have -poll. no -read is pretty rare but 2.4 chæcks it aswell. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
- once we have Alan's idea of the graphics core implemented drm_init() should go awaw - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy, what about doing the full -probe callback in each driver where it can do basic hw setup, dealing with pci and calls back into the drm core for minor number allocation and common structure allocations. We have mentioned this but 90% of the work done by the drivers would be common, we might do it the otherway I suppose have a driver probe that calls a function in the core, This would get rid of the -preinit and -postinit hooks. - isn't drm_order just a copy of get_order()? - any chance to use proper kernel-doc comments instead of the bastdized and hard to read version you have currently? I think we have doxygen comments in there at the moment - the Mesa/DRI documentation is done with doxygen... - the coding style is a little strange, like spurious whitespaces inside braces, maybe you could run it through scripts/Lindent there are a fair few of these in there in the kernel, it could probably do with a Lindent at some stage over the whole thing... - care to use linux/lists.h instead of opencoded lists, e.g. in dev-file_last/dev-file_first or dev-vmalist - drm_flush is a noop. a NULL -flush does the same thing, just easier - dito or -poll - dito for -read - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code? - drm__mem_info should be converted to fs/seq_file.c functions - dito for functions in drm_proc.c I think I can apply a lot of these to the current kernel code so I'll probably just start doing patches up for these sort of issues separately I'll get time to create a bitkeeper tree taking Jons changes ready for merging to Andrew at least, and maybe Linus for 2.6.10. Dave. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Christoph Hellwig wrote: On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote: Thinking about it, it may not have been a problem of crashing, but rather that the behaviour visible from a program attempting to read (or poll) was different with noop versions of these functions to NULL versions, and that was causing problems. This is 18 months ago, so yes, I'm being vague. The X server does look at this file descriptor, which is where the problem would have arisen, but only the gamma maybe ffb drivers do anything with it. Indeed, for read you're returning 0 now instead of the -EINVAL from common code when no -read is present. I'd say the current drm behaviour is a bug, but if X drivers rely on it. I'd agree, but it's a widely distributed bug. I guess we can fix it in the X server, but even better would be to rip out the code as it's fundamentally misguided, based on a wierd idea that the kernel would somehow ask the X server to perform a context switch between two userspace clients... Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Keith Whitwell wrote: Christoph Hellwig wrote: On Wed, Sep 29, 2004 at 02:29:24PM +0100, Keith Whitwell wrote: Christoph Hellwig wrote: - drm_flush is a noop. a NULL -flush does the same thing, just easier - dito or -poll - dito for -read Pretty sure you couldn't get away with null for these in 2.4, at least. Umm, of course you could. There's only a hanfull instance defining a -flush at all. Similarly all file_ops for regular files and many char devices don't have -poll. no -read is pretty rare but 2.4 chæcks it aswell. I tried it, led to crashes (panics, I guess) the change had to be reverted. On reverting the crashes stopped. This was for poll and read: Thinking about it, it may not have been a problem of crashing, but rather that the behaviour visible from a program attempting to read (or poll) was different with noop versions of these functions to NULL versions, and that was causing problems. This is 18 months ago, so yes, I'm being vague. The X server does look at this file descriptor, which is where the problem would have arisen, but only the gamma maybe ffb drivers do anything with it. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote: Thinking about it, it may not have been a problem of crashing, but rather that the behaviour visible from a program attempting to read (or poll) was different with noop versions of these functions to NULL versions, and that was causing problems. This is 18 months ago, so yes, I'm being vague. The X server does look at this file descriptor, which is where the problem would have arisen, but only the gamma maybe ffb drivers do anything with it. Indeed, for read you're returning 0 now instead of the -EINVAL from common code when no -read is present. I'd say the current drm behaviour is a bug, but if X drivers rely on it. Similar in poll your return 0 now while the generic code return (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM) for fds without -poll, and again I'd say current drm behaviour could be considered a bug. for -flush there's no behaviour change of not supplying it. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Jon Smirl wrote:
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 *);
Is this used by any driver?
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);
The whole context thing in the kernel is pretty much cruft. The gamma module
used to rely on it, maybe the ffb module if that still exists? It would be
good to see this disappear.
Though the drivers don't rely on it, I don't know if the server-side code
persists in setting it up regardless, which might make it hard to get rid of.
int (*vblank_wait)(struct drm_device *dev, unsigned int *sequence);
/* these have to be filled in */
int (*postinit)(struct drm_device *, unsigned long flags);
Maybe move this up with the other init/cleanup functions so that they are
visibly grouped? Can the large number of init/cleanup functions be
rationalized in some way?
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);
Maybe rename this to dma_reclaim_buffers() to make clear what code it is
associated with?
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);
};
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 2004-09-29 at 07:25, Keith Whitwell wrote: The whole context thing in the kernel is pretty much cruft. The gamma module used to rely on it, maybe the ffb module if that still exists? It would be good to see this disappear. A few Gentoo Sparc folks use ffb, and in some cases it works (http://bugs.gentoo.org/show_bug.cgi?id=65348). -- Donnie Berkholz Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: New DRM driver model - gets rid of DRM() macros!
Around 15 o'clock on Sep 29, Keith Whitwell wrote: A future X-on-GL world where regular applications are presumably doing direct rendering will change that assumption... I'm not planning on eliminating the X protocol in this environment, so unless cairo really takes off and applications start coding to cairo-on-GL instead of cairo-on-X-on-GL, then we'll have about the same number of contexts, although the X context will be more rational than it currently is. -keith pgpYiZtdZIDDG.pgp Description: PGP signature
Re: New DRM driver model - gets rid of DRM() macros!
On Tue, 28 Sep 2004 11:54:35 -0400 Jon Smirl [EMAIL PROTECTED] wrote: 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. A single savage works just fine. This is lsmod output with X running: Module Size Used by savage 3520 0 drm62500 3 savage Is it normal that the savage module looks unused? I can actually rmmod the savage module while X is running. After that direct rending fails with some error message about permissions ... reloading savage didn't help (of course, because X wouldn't reinitialize it). A bit later the box locked up. Is this 0 usage count and the ability to rmmod the module while X is running specific to the savage driver or do other drivers show the same behaviour? Some questions about future driver development: So the new linux-core and shared-core are the place to do new driver development? If this is correct then it will be for 2.6 kernels only, right? I suppose there would some back-porting effort involved in getting a future savage driver to work with 2.4 again (like adding back all the DRM() macros). [snip] -- Jon Smirl [EMAIL PROTECTED] | Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 29 Sep 2004 23:52:38 +0200, Felix Kühling [EMAIL PROTECTED] wrote: Is it normal that the savage module looks unused? I can actually rmmod the savage module while X is running. After that direct rending fails with some error message about permissions ... reloading savage didn't help (of course, because X wouldn't reinitialize it). A bit later the box locked up. Is this 0 usage count and the ability to rmmod the module while X is running specific to the savage driver or do other drivers show the same behaviour? This is a bug, open is marking the wrong module in use. Some questions about future driver development: So the new linux-core and shared-core are the place to do new driver development? If this is correct then it will be for 2.6 kernels only, right? I suppose there would some back-porting effort involved in getting a future savage driver to work with 2.4 again (like adding back all the DRM() macros). There is no real difference between the code in the linux directory and linux-core except for the removal of the DRM macros and the associated restructuring needed to make everything work. When we get linux-core working without problems, it's not there yet, it could become the future 2.6 platform if everyone agrees. The impact of the linux-core changes are minimal on the board specific code. For 2.4 there is a choice: continue using the linux directory or backport linux-core to 2.4. I don't know how much effort everyone wants to put into backporting new driver development to 2.4. There are several possible choices: 1) leave 2.4 alone and stop working on it, 2.4 stays in the linux directory 2) declare the DRM version in the linux-2.4 the final version and only submit bug patches via the kernel process. 3) backport linux-core to 2.4 and so that everything will build on both OS's. Some 2.6 kernel changes are starting to make this a very cluttered option. 4) Make parallel changes to the 2.4 and 2.6 versions. 5) other combinations of these The removal of the DRM macros from files in the shared directory means that things can't be shared again unless 2.4/BSD also move the the core model. I have no strong opinions on what to do about 2.4. I'll go along with whatever the crowd picks. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 2004-09-29 at 07:25, Keith Whitwell wrote:
Jon Smirl wrote:
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 *);
Is this used by any driver?
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);
The whole context thing in the kernel is pretty much cruft. The gamma module
used to rely on it, maybe the ffb module if that still exists? It would be
good to see this disappear.
Though the drivers don't rely on it, I don't know if the server-side code
persists in setting it up regardless, which might make it hard to get rid of.
SiS relies on context ctor/dtor (dtor only, when I'm done) for its
kernel memory manager.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
New DRM driver model - gets rid of DRM() macros!
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:[EMAIL PROTECTED]:/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.
[EMAIL PROTECTED] linux-2.6]# lsmod | more
Module Size Used by
tdfx2816 0
sis10176 0
mga56704 0
i915 16896 0
via19428 0
savage 3840 0
r128 44672 0
radeon 70272 0
drm59684 8 tdfx,sis,mga,i915,via,savage,r128,radeon
The core provides these entry points
[EMAIL PROTECTED] 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
Re: New DRM driver model - gets rid of DRM() macros!
On Tue, 28 Sep 2004 09:56:38 -0700, Ian Romanick [EMAIL PROTECTED] wrote: Anyone have a PCI card so that we can test actually using more than one at a time? In the mean time, I think just having them all load at once and one of them work is good enough. It would be best if everyone tested each card individually right now, both PCI and AGP versions should work. I think I know of a couple places where it might break if multiple cards are used simultaneously. All static variables in the core are suspect and need to be individually checked. There are less than 20 so it shouldn't take too long. Of course any help with this is appreciated. Another thing that isn't written is splitting the module parameters between the core and personalities. I'll also switch syntax from 2.4 style to 2.6 style. When finished each module with have a debug=1 parameter and the core will also have a cards_limit which defaults to 16. This version also includes minor number reuse so hotplugging a card in/out won't exhaust the DRM minors. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Tue, Sep 28, 2004 at 09:56:38AM -0700, Ian Romanick wrote: Jon Smirl wrote: [...] After sometime testing and fixing obvious problems I'll generate a patch for the 2.6 kernel and lkml. [EMAIL PROTECTED] linux-2.6]# lsmod | more Module Size Used by tdfx2816 0 sis10176 0 mga56704 0 i915 16896 0 via19428 0 savage 3840 0 r128 44672 0 radeon 70272 0 drm59684 8 tdfx,sis,mga,i915,via,savage,r128,radeon Anyone have a PCI card so that we can test actually using more than one at a time? In the mean time, I think just having them all load at once and one of them work is good enough. I have a radeon9200SE pci card, and a matrox G550 agp card. I can try when that 2.6 patch becomes available. Helge Hafting --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
As with Ian, I'm trying to grab the time to review this over the next day
or two, I have one or two worries but as I haven't read over the code I'll
wait until I'm ready to dedicate some proper time to it ..
Dave.
On Tue, 28 Sep 2004, Jon Smirl wrote:
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:[EMAIL PROTECTED]:/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.
[EMAIL PROTECTED] linux-2.6]# lsmod | more
Module Size Used by
tdfx2816 0
sis10176 0
mga56704 0
i915 16896 0
via19428 0
savage 3840 0
r128 44672 0
radeon 70272 0
drm59684 8 tdfx,sis,mga,i915,via,savage,r128,radeon
The core provides these entry points
[EMAIL PROTECTED] 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
Re: New DRM driver model - gets rid of DRM() macros!
Single card seems to be working currently. I still can't get multiple cards going yet. Second card tries to get the context without holding the lock and errors out. I'll keep working on it tonight and tomorrow. I'm past the obvious bug stage now and into the ones where I stare at it for five hours before I figure out what is wrong. Still need someone with a Sparc machine to fix the ffb compile. On Wed, 29 Sep 2004 00:10:18 +0100 (IST), Dave Airlie [EMAIL PROTECTED] wrote: As with Ian, I'm trying to grab the time to review this over the next day or two, I have one or two worries but as I haven't read over the code I'll wait until I'm ready to dedicate some proper time to it .. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
I've found the problem with multiple drivers, it's in the mapping code. When drivers close their handles they are deleting permanent maps that don't belong to them. I'll fix it tomorrow. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
