first DRM function table patch (radeon only..)
Okay at http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff is my first attempt at swatting the low hanging fruit in the DRM, this moves the driver macros into a function table which the driver can work off.. i've only done the radeon on Linux (no point going too far without making sure the ideas are okay..) 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 OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: first DRM function table patch (radeon only..)
Dave Airlie wrote: Okay at http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff is my first attempt at swatting the low hanging fruit in the DRM, this moves the driver macros into a function table which the driver can work off.. i've only done the radeon on Linux (no point going too far without making sure the ideas are okay..) Looks good so far. This technique should be able to clean up a fair bit of the preprocessor-oddness that lkml people complain about without necessarily damaging BSD support at all. Keith --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: first DRM function table patch (radeon only..)
This will give us a chance to make sure they return errors and the errors get checked. But if this code is going to go into a library, the PCI match will need to be triggered from the personality modules. Does this change the way we want to structure the code? --- Keith Whitwell <[EMAIL PROTECTED]> wrote: > Dave Airlie wrote: > > Okay at > > > > http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff > > > > is my first attempt at swatting the low hanging fruit in the DRM, > > > > this moves the driver macros into a function table which the driver > can > > work off.. i've only done the radeon on Linux (no point going too > far > > without making sure the ideas are okay..) > > Looks good so far. This technique should be able to clean up a fair > bit of > the preprocessor-oddness that lkml people complain about without > necessarily > damaging BSD support at all. > > Keith > > > > --- > This SF.Net email is sponsored by OSTG. Have you noticed the changes > on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? > Now, > one more big change to announce. We are now OSTG- Open Source > Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: first DRM function table patch (radeon only..)
> This will give us a chance to make sure they return errors and the > errors get checked. But if this code is going to go into a library, the > PCI match will need to be triggered from the personality modules. Does > this change the way we want to structure the code? As Ian said we should take this in steps and see how it goes, I'd be against moving the device probe code down to the driver level (in code), however I'm not against leaving it in a templated header file, the less work required to change the probing per driver the better, What I would like to see is probably a hybrid approach, a core library containing all the core stuff, then maybe a templated driver per chipset.. I think this will give us the best of both worlds... I've come up with a different way of doing the fn table, I'll hack something together this evening ... I'd like to make every driver have a preinit function called DRM(preinit) or something like that and then have that function just fill out the pointers that driver is interested in, I dislike big tables with NULLs, this way we are more like DRI drivers with mesa functions.. just fill in the ones you want.. Dave. > > --- Keith Whitwell <[EMAIL PROTECTED]> wrote: > > > Dave Airlie wrote: > > > Okay at > > > > > > http://www.skynet.ie/~airlied/patches/dri/drm_fn_tbl.diff > > > > > > is my first attempt at swatting the low hanging fruit in the DRM, > > > > > > this moves the driver macros into a function table which the driver > > can > > > work off.. i've only done the radeon on Linux (no point going too > > far > > > without making sure the ideas are okay..) > > > > Looks good so far. This technique should be able to clean up a fair > > bit of > > the preprocessor-oddness that lkml people complain about without > > necessarily > > damaging BSD support at all. > > > > Keith > > > > > > > > --- > > This SF.Net email is sponsored by OSTG. Have you noticed the changes > > on > > Linux.com, ITManagersJournal and NewsForge in the past few weeks? > > Now, > > one more big change to announce. We are now OSTG- Open Source > > Technology > > Group. Come see the changes on the new OSTG site. www.ostg.com > > -- > > ___ > > Dri-devel mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/dri-devel > > > > > = > Jon Smirl > [EMAIL PROTECTED] > > > > __ > Do you Yahoo!? > Yahoo! Mail - 50x more storage than other providers! > http://promotions.yahoo.com/new_mail > > > --- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- 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 OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: first DRM function table patch (radeon only..)
the bulk of the probe code can stay in the library.
Maybe something like this in a personality module:
static struct pci_driver drm_driver = {
.name = DRIVER_NAME,
.id_table = DRM(pciidlist),
.probe = my_probe,
.remove= __devexit_p(drm_cleanup_pci),
};
my_probe() {
do my preinit stuff
drm_probe() - library routine
do my postinit stuff
}
Now you don't need pre and post init call outs. If the driver doesn't
have any pre/post init code just set .probe = drm_probe
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: first DRM function table patch (radeon only..)
> the bulk of the probe code can stay in the library.
>
> Maybe something like this in a personality module:
>
> static struct pci_driver drm_driver = {
> .name = DRIVER_NAME,
> .id_table = DRM(pciidlist),
> .probe = my_probe,
> .remove= __devexit_p(drm_cleanup_pci),
> };
>
>
> my_probe() {
>do my preinit stuff
>drm_probe() - library routine
>do my postinit stuff
> }
>
> Now you don't need pre and post init call outs. If the driver doesn't
> have any pre/post init code just set .probe = drm_probe
I'm not seeing the advantage of doing this, you'll have to convince me
that adding a section to each file is a better idea than having the
callouts in a templated header file ...
The less files we have to edit to change something the better ...
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 OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
