From: Jens O. <je...@tu...> - 2002-03-15 15:38:25
|
I would like to move the device dependent functionality currently included in the drm library back into the device driver layer. My objective is to make sure new driver suites can be independently released without stepping on any components needed by other driver suites. Currently, libdrm contains a mixture of device independent code and multiple device dependent routines. I'm looking for a clean way to split this functionality and restore libdrm device independent, while still providing a mechanism for device specific IOCTL style support directly in device drivers. Could we simply add a drmIOCTL entry point to the DRM library? Then, the packing and unpacking could be done in the drivers. The Linux and BSD implementations would simply wrap the standard IOCTL and future OS ports of the DRI would have a layer, if needed, for emulating an IOCTL. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Alan H. <al...@fa...> - 2002-03-18 18:57:14
|
On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: > I would like to move the device dependent functionality currently > included in the drm library back into the device driver layer. > > My objective is to make sure new driver suites can be independently > released without stepping on any components needed by other driver > suites. Currently, libdrm contains a mixture of device independent code > and multiple device dependent routines. > > I'm looking for a clean way to split this functionality and restore > libdrm device independent, while still providing a mechanism for device > specific IOCTL style support directly in device drivers. > > Could we simply add a drmIOCTL entry point to the DRM library? Then, > the packing and unpacking could be done in the drivers. The Linux and > BSD implementations would simply wrap the standard IOCTL and future OS > ports of the DRI would have a layer, if needed, for emulating an IOCTL. > Jens, This is definately a problem that needs sorting out. We certainly need to put the driver specific calls into the 2D ddx portion, and abstract some form of drmIOCTL for the os-support routines. Please go ahead, and I'll certainly help out with this. Alan. |
From: Jens O. <je...@tu...> - 2002-03-22 15:03:53
|
Alan Hourihane wrote: > > On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: > > I would like to move the device dependent functionality currently > > included in the drm library back into the device driver layer. > > > > My objective is to make sure new driver suites can be independently > > released without stepping on any components needed by other driver > > suites. Currently, libdrm contains a mixture of device independent code > > and multiple device dependent routines. > > > > I'm looking for a clean way to split this functionality and restore > > libdrm device independent, while still providing a mechanism for device > > specific IOCTL style support directly in device drivers. > > > > Could we simply add a drmIOCTL entry point to the DRM library? Then, > > the packing and unpacking could be done in the drivers. The Linux and > > BSD implementations would simply wrap the standard IOCTL and future OS > > ports of the DRI would have a layer, if needed, for emulating an IOCTL. > > > Jens, > > This is definately a problem that needs sorting out. We certainly > need to put the driver specific calls into the 2D ddx portion, and > abstract some form of drmIOCTL for the os-support routines. > > Please go ahead, and I'll certainly help out with this. Alan, Thanks for the feedback. I plan to proceed on this next week. Maybe you can verify it's portability on the BSD branch after I'm done. Regards, Jens -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Alan H. <al...@fa...> - 2002-03-22 15:52:19
|
On Fri, Mar 22, 2002 at 08:03:29 -0700, Jens Owen wrote: > Alan Hourihane wrote: > > > > On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: > > > I would like to move the device dependent functionality currently > > > included in the drm library back into the device driver layer. > > > > > > My objective is to make sure new driver suites can be independently > > > released without stepping on any components needed by other driver > > > suites. Currently, libdrm contains a mixture of device independent code > > > and multiple device dependent routines. > > > > > > I'm looking for a clean way to split this functionality and restore > > > libdrm device independent, while still providing a mechanism for device > > > specific IOCTL style support directly in device drivers. > > > > > > Could we simply add a drmIOCTL entry point to the DRM library? Then, > > > the packing and unpacking could be done in the drivers. The Linux and > > > BSD implementations would simply wrap the standard IOCTL and future OS > > > ports of the DRI would have a layer, if needed, for emulating an IOCTL. > > > > > Jens, > > > > This is definately a problem that needs sorting out. We certainly > > need to put the driver specific calls into the 2D ddx portion, and > > abstract some form of drmIOCTL for the os-support routines. > > > > Please go ahead, and I'll certainly help out with this. > > Alan, > > Thanks for the feedback. I plan to proceed on this next week. Maybe > you can verify it's portability on the BSD branch after I'm done. > Actually, just a heads up. The bsd-3-0-0-branch is dead. forget this one. I'm doing whatever changes the BSD stuff needs on the trunk. They're going to be only minor changes now we've got the kernel modules in sync. Alan. |
From: Jens O. <je...@tu...> - 2002-03-28 17:35:34
|
Alan Hourihane wrote: > > On Fri, Mar 22, 2002 at 08:03:29 -0700, Jens Owen wrote: > > Alan Hourihane wrote: > > > > > > On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: > > > > I would like to move the device dependent functionality currently > > > > included in the drm library back into the device driver layer. > > > > > > > > My objective is to make sure new driver suites can be independently > > > > released without stepping on any components needed by other driver > > > > suites. Currently, libdrm contains a mixture of device independent code > > > > and multiple device dependent routines. > > > > > > > > I'm looking for a clean way to split this functionality and restore > > > > libdrm device independent, while still providing a mechanism for device > > > > specific IOCTL style support directly in device drivers. > > > > > > > > Could we simply add a drmIOCTL entry point to the DRM library? Then, > > > > the packing and unpacking could be done in the drivers. The Linux and > > > > BSD implementations would simply wrap the standard IOCTL and future OS > > > > ports of the DRI would have a layer, if needed, for emulating an IOCTL. > > > > > > > Jens, > > > > > > This is definately a problem that needs sorting out. We certainly > > > need to put the driver specific calls into the 2D ddx portion, and > > > abstract some form of drmIOCTL for the os-support routines. > > > > > > Please go ahead, and I'll certainly help out with this. > > > > Alan, > > > > Thanks for the feedback. I plan to proceed on this next week. Maybe > > you can verify it's portability on the BSD branch after I'm done. > > > Actually, just a heads up. The bsd-3-0-0-branch is dead. forget this one. > > I'm doing whatever changes the BSD stuff needs on the trunk. They're > going to be only minor changes now we've got the kernel modules in > sync. Alan, As I get closer to having a prototype going, we will probably want some place other than the trunk to try this out; and possibly make sure the prototype works for BSD, I you want to do that. I'd like to get the prototype working and verified portable before doing all the work of converting the huge number of device specific DRM extensions. I've been working from the tcl-0-0-branch code base, but we could make a new branch from the trunk if you'd prefer that. Let me know if you plan on building and verifying the prototype under BSD. If not, I'll probably just continue my work in the tcl-0-0-branch. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Alan H. <al...@fa...> - 2002-03-28 17:46:27
|
On Thu, Mar 28, 2002 at 10:35:16AM -0700, Jens Owen wrote: > Alan Hourihane wrote: > > > > On Fri, Mar 22, 2002 at 08:03:29 -0700, Jens Owen wrote: > > > Alan Hourihane wrote: > > > > > > > > On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: > > > > > I would like to move the device dependent functionality currently > > > > > included in the drm library back into the device driver layer. > > > > > > > > > > My objective is to make sure new driver suites can be independently > > > > > released without stepping on any components needed by other driver > > > > > suites. Currently, libdrm contains a mixture of device independent code > > > > > and multiple device dependent routines. > > > > > > > > > > I'm looking for a clean way to split this functionality and restore > > > > > libdrm device independent, while still providing a mechanism for device > > > > > specific IOCTL style support directly in device drivers. > > > > > > > > > > Could we simply add a drmIOCTL entry point to the DRM library? Then, > > > > > the packing and unpacking could be done in the drivers. The Linux and > > > > > BSD implementations would simply wrap the standard IOCTL and future OS > > > > > ports of the DRI would have a layer, if needed, for emulating an IOCTL. > > > > > > > > > Jens, > > > > > > > > This is definately a problem that needs sorting out. We certainly > > > > need to put the driver specific calls into the 2D ddx portion, and > > > > abstract some form of drmIOCTL for the os-support routines. > > > > > > > > Please go ahead, and I'll certainly help out with this. > > > > > > Alan, > > > > > > Thanks for the feedback. I plan to proceed on this next week. Maybe > > > you can verify it's portability on the BSD branch after I'm done. > > > > > Actually, just a heads up. The bsd-3-0-0-branch is dead. forget this one. > > > > I'm doing whatever changes the BSD stuff needs on the trunk. They're > > going to be only minor changes now we've got the kernel modules in > > sync. > > Alan, > > As I get closer to having a prototype going, we will probably want some > place other than the trunk to try this out; and possibly make sure the > prototype works for BSD, I you want to do that. I'd like to get the > prototype working and verified portable before doing all the work of > converting the huge number of device specific DRM extensions. > > I've been working from the tcl-0-0-branch code base, but we could make a > new branch from the trunk if you'd prefer that. Let me know if you plan > on building and verifying the prototype under BSD. If not, I'll > probably just continue my work in the tcl-0-0-branch. > In the limited time I have at the moment, Yes. I'll help. It'd be worth dragging Eric Anholt into this as he's been doing a lot with this too. Eric - are you reading this ? Alan. |
From: Eric A. <ea...@gl...> - 2002-04-02 21:31:10
|
Just to update you all on what I'm doing: I have just finished getting some of the 4.2.0 patches and drm-kmod (DRM kernel modules in the FreeBSD port/package system) updates into the FreeBSD ports collection. At this point I think the biggest priority for FreeBSD is getting mesa 4.0 working, hopefully in the os-templated form. I've got 3dfx working great, but ATI cards were just giving me a black window last I tried. I'll see what Alan's updates in the non-templated version have done and compare the templated version to them and to current linux source. After that I'll take a look at drmcommand (which sounds like it won't be too big of a deal to support, though I haven't looked at the code yet) and then tcl (again, haven't looked, but if it's just new ioctls it shouldn't be a problem and should be possible to roll into drm-kmod). On Thu, 2002-03-28 at 09:46, Alan Hourihane wrote: > In the limited time I have at the moment, Yes. I'll help. > > It'd be worth dragging Eric Anholt into this as he's been doing a > lot with this too. > > Eric - are you reading this ? > > Alan. > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: Jens O. <je...@tu...> - 2002-04-02 22:40:17
|
Eric Anholt wrote: > > Just to update you all on what I'm doing: I have just finished getting > some of the 4.2.0 patches and drm-kmod (DRM kernel modules in the > FreeBSD port/package system) updates into the FreeBSD ports collection. > At this point I think the biggest priority for FreeBSD is getting mesa > 4.0 working, hopefully in the os-templated form. I've got 3dfx working > great, but ATI cards were just giving me a black window last I tried. > I'll see what Alan's updates in the non-templated version have done and > compare the templated version to them and to current linux source. > After that I'll take a look at drmcommand (which sounds like it won't be > too big of a deal to support, though I haven't looked at the code yet) > and then tcl (again, haven't looked, but if it's just new ioctls it > shouldn't be a problem and should be possible to roll into drm-kmod). Eric, Thanks for the update. You have the right priorites from what I can tell. I didn't realize that FreeBSD was so far behind the DRI trunk. I thought it had Mesa 4 since Alan had merged FreeBSD support into the trunk. I'm pushing forward with the drmCommand interface. Hopefully, it won't give you any problems, because major changes will be very time consuming after all the working drivers in the trunk have been converted. Regards, Jens -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Alan H. <al...@fa...> - 2002-04-02 22:48:08
|
On Tue, Apr 02, 2002 at 03:39:48PM -0700, Jens Owen wrote: > Eric Anholt wrote: > > > > Just to update you all on what I'm doing: I have just finished getting > > some of the 4.2.0 patches and drm-kmod (DRM kernel modules in the > > FreeBSD port/package system) updates into the FreeBSD ports collection. > > At this point I think the biggest priority for FreeBSD is getting mesa > > 4.0 working, hopefully in the os-templated form. I've got 3dfx working > > great, but ATI cards were just giving me a black window last I tried. > > I'll see what Alan's updates in the non-templated version have done and > > compare the templated version to them and to current linux source. > > After that I'll take a look at drmcommand (which sounds like it won't be > > too big of a deal to support, though I haven't looked at the code yet) > > and then tcl (again, haven't looked, but if it's just new ioctls it > > shouldn't be a problem and should be possible to roll into drm-kmod). > > Eric, > > Thanks for the update. You have the right priorites from what I can > tell. I didn't realize that FreeBSD was so far behind the DRI trunk. I > thought it had Mesa 4 since Alan had merged FreeBSD support into the > trunk. > Jens, XFree86 4.2.0 was merged to the trunk with Mesa 3.4.2 which had the BSD kernel modules, then the mesa-4-0-branch was merged to the trunk and the BSD modules were not updated. That's what I've fixed, although I haven't tested them yet. Although I'm surprised that they would need any work at all, especially the tdfx driver. Nothing ever changes at the kernel level for that one, and the kernel module that was in 4.2.0 should work for the new mesa 4.0 code. I've committed patches already to compile the drmcommand branch on BSD although, again not tested yet. It seems that sourceforge's mailing lists are having problems and the CVS message hasn't shown up. I'll try and spend some time testing the BSD code this week. Alan. |
From: Jens O. <je...@tu...> - 2002-04-02 22:55:41
|
Alan Hourihane wrote: > > On Tue, Apr 02, 2002 at 03:39:48PM -0700, Jens Owen wrote: > > Eric Anholt wrote: > > > > > > Just to update you all on what I'm doing: I have just finished getting > > > some of the 4.2.0 patches and drm-kmod (DRM kernel modules in the > > > FreeBSD port/package system) updates into the FreeBSD ports collection. > > > At this point I think the biggest priority for FreeBSD is getting mesa > > > 4.0 working, hopefully in the os-templated form. I've got 3dfx working > > > great, but ATI cards were just giving me a black window last I tried. > > > I'll see what Alan's updates in the non-templated version have done and > > > compare the templated version to them and to current linux source. > > > After that I'll take a look at drmcommand (which sounds like it won't be > > > too big of a deal to support, though I haven't looked at the code yet) > > > and then tcl (again, haven't looked, but if it's just new ioctls it > > > shouldn't be a problem and should be possible to roll into drm-kmod). > > > > Eric, > > > > Thanks for the update. You have the right priorites from what I can > > tell. I didn't realize that FreeBSD was so far behind the DRI trunk. I > > thought it had Mesa 4 since Alan had merged FreeBSD support into the > > trunk. > > > Jens, > > XFree86 4.2.0 was merged to the trunk with Mesa 3.4.2 which had > the BSD kernel modules, then the mesa-4-0-branch was merged to the trunk > and the BSD modules were not updated. That's what I've fixed, although > I haven't tested them yet. Although I'm surprised that they would > need any work at all, especially the tdfx driver. > Nothing ever changes at the kernel level for that one, and the kernel > module that was in 4.2.0 should work for the new mesa 4.0 code. Sounds like FreeBSD is actually pretty close... > I've committed patches already to compile the drmcommand branch on > BSD although, again not tested yet. Great. > It seems that sourceforge's > mailing lists are having problems and the CVS message hasn't shown > up. Okay, thanks for the heads up. Maybe we should send a short e-mail to devel notifying when we update until this works again. > I'll try and spend some time testing the BSD code this week. Great. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Jens O. <je...@tu...> - 2002-03-27 05:36:49
|
On Mon, Mar 18, 2002, Alan Hourihane wrote: > > On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote: > > I would like to move the device dependent functionality currently > > included in the drm library back into the device driver layer. > > > > My objective is to make sure new driver suites can be independently > > released without stepping on any components needed by other driver > > suites. Currently, libdrm contains a mixture of device independent code > > and multiple device dependent routines. > > > > I'm looking for a clean way to split this functionality and restore > > libdrm device independent, while still providing a mechanism for device > > specific IOCTL style support directly in device drivers. > > > > Could we simply add a drmIOCTL entry point to the DRM library? Then, > > the packing and unpacking could be done in the drivers. The Linux and > > BSD implementations would simply wrap the standard IOCTL and future OS > > ports of the DRI would have a layer, if needed, for emulating an IOCTL. > > > Jens, > > This is definately a problem that needs sorting out. We certainly > need to put the driver specific calls into the 2D ddx portion, and > abstract some form of drmIOCTL for the os-support routines. > > Please go ahead, and I'll certainly help out with this. Alan, I've made some headway on this today, and could use some feedback based on your BSD experience. I've attempted to move the packing of drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing is the actual IOCTL request number. I can easily use the Linux number, but I thought it might be better to have some OS independent offset. However, generating all the combinations of _IO, _IOR, _IOW and _IOWR semantics in an OS independent way is going to be challenging. See xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line 373 Here is an incomplete patch in case you are interested in the general direction I was currently prototyping... Should I just use the Linux _IO* semantics and let other OS ports twizzle this to get this working, or do you have any ideas on how we can generate the proper semantics in a more general way. I think we will need to generate these semantics at run time, not compile time. -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Alan H. <al...@fa...> - 2002-03-27 09:01:04
|
On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote: > I've made some headway on this today, and could use some feedback based > on your BSD experience. I've attempted to move the packing of > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing > is the actual IOCTL request number. I can easily use the Linux number, > but I thought it might be better to have some OS independent offset. > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR > semantics in an OS independent way is going to be challenging. See > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line > 373 > > Here is an incomplete patch in case you are interested in the general > direction I was currently prototyping... > > Should I just use the Linux _IO* semantics and let other OS ports > twizzle this to get this working, or do you have any ideas on how we can > generate the proper semantics in a more general way. I think we will > need to generate these semantics at run time, not compile time. > Jens, The idea of offset's with an os dependent MAGIC_NUMBER sounds like the right idea. I also think that we go ahead and use the Linux _IO* semantics, as the *BSD just twizzles around these anyway at the moment. And until more OS's support the drm (or at least show some signs) then that's probably the best we can hope for. Alan. |
From: Jens O. <je...@tu...> - 2002-03-27 14:22:58
|
Alan Hourihane wrote: > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote: > > I've made some headway on this today, and could use some feedback based > > on your BSD experience. I've attempted to move the packing of > > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing > > is the actual IOCTL request number. I can easily use the Linux number, > > but I thought it might be better to have some OS independent offset. > > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR > > semantics in an OS independent way is going to be challenging. See > > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line > > 373 > > > > Here is an incomplete patch in case you are interested in the general > > direction I was currently prototyping... > > > > Should I just use the Linux _IO* semantics and let other OS ports > > twizzle this to get this working, or do you have any ideas on how we can > > generate the proper semantics in a more general way. I think we will > > need to generate these semantics at run time, not compile time. > > > Jens, > > The idea of offset's with an os dependent MAGIC_NUMBER sounds like > the right idea. I also think that we go ahead and use the Linux _IO* > semantics, as the *BSD just twizzles around these anyway at the moment. > And until more OS's support the drm (or at least show some signs) then > that's probably the best we can hope for. Okay, I'll use the Linux DRM semantics where are: ( (direction) << 30 | (size) << 16 | (type) << 8 | (request) << 0 ) where direction is: 0 for none, 1 for write, 2 for read and 3 for both size is: size of record to be transfered type is: 'd' for DRM drivers request is: our OS independent offset -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Jeff H. <jha...@ad...> - 2002-03-28 04:27:26
|
-----Original Message----- From: dri...@li... [mailto:dri...@li...]On Behalf Of Jens Owen Sent: Wednesday, March 27, 2002 6:23 AM To: Alan Hourihane Cc: dri-devel Subject: Re: [Dri-devel] Restoring DRM Library Device Independence Alan Hourihane wrote: > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote: > > I've made some headway on this today, and could use some feedback based > > on your BSD experience. I've attempted to move the packing of > > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing > > is the actual IOCTL request number. I can easily use the Linux number, > > but I thought it might be better to have some OS independent offset. > > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR > > semantics in an OS independent way is going to be challenging. See > > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line > > 373 > > > > Here is an incomplete patch in case you are interested in the general > > direction I was currently prototyping... > > > > Should I just use the Linux _IO* semantics and let other OS ports > > twizzle this to get this working, or do you have any ideas on how we can > > generate the proper semantics in a more general way. I think we will > > need to generate these semantics at run time, not compile time. > > Heres just a thought... When we added the usage of device specific ioctls we just linked them into the drm library because that was convient at the time. I think keeping this code os dependant is probably a good idea. This gives more flexibility, like on another os where ioctl semantics are impossible. In such an os they might want to use read/write to do message passing. In a clean implementation of this case it won't even make sense to have a drmIOCTL at all. Remember that each os can have their own drm library, even though I think BSD basically uses the linux one. There really shouldn't be something as os specific as an ioctl presented in the drm interface layer. It smells of bad design. The basic point of this exercise is to make it so we can hot swap driver suites (or at least I'm pretty sure this is your goal.) Why don't we just make each device have its own xfree module for its os specific part? That way we can add/subtract/upgrade driver suites, and not upset the apple cart. Just seems like a whole lot easier solution to the problem. Adding another module load into each driver just sounds like a cleaner implementation, and it solves your problem. -Jeff |
From: Alan H. <al...@fa...> - 2002-03-28 08:15:34
|
On Wed, Mar 27, 2002 at 10:25:18 -0800, Jeff Hartmann wrote: > Heres just a thought... > > When we added the usage of device specific ioctls we just linked them into > the drm library because that was convient at the time. I think keeping this > code os dependant is probably a good idea. This gives more flexibility, like > on another os where ioctl semantics are impossible. In such an os they > might want to use read/write to do message passing. In a clean > implementation of this case it won't even make sense to have a drmIOCTL at > all. Remember that each os can have their own drm library, even though I > think BSD basically uses the linux one. There really shouldn't be something > as os specific as an ioctl presented in the drm interface layer. It smells > of bad design. > > The basic point of this exercise is to make it so we can hot swap driver > suites (or at least I'm pretty sure this is your goal.) Why don't we just > make each device have its own xfree module for its os specific part? That > way we can add/subtract/upgrade driver suites, and not upset the apple cart. > Just seems like a whole lot easier solution to the problem. > > Adding another module load into each driver just sounds like a cleaner > implementation, and it solves your problem. > The code specifically we're talking about is this kind of thing.... - if (drmRadeonInitCP(info->drmFD, &drmInfo) < 0) return FALSE; + if (drmIOCTL(info->drmFD, DRM_IOCTL_RADEON_CP_INIT, &init) < 0) We're passing exactly the same information, apart from now, we're passing a specific command. We could rename drmIOCTL to drmCOMMAND and make it clear that it's not an IOCTL we are calling, it just happens to be an IOCTL in the linux layer. Also, DRM_IOCTL_RADEON_CP_INIT we really be just RADEON_CP_INIT. So it's now.... - if (drmRadeonInitCP(info->drmFD, &drmInfo) < 0) return FALSE; + if (drmCOMMAND(info->drmFD, RADEON_CP_INIT, &init) < 0) The drmCOMMAND can be anything that the OS supports to do, and it knows what we're are trying to do by passing RADEON_CP_INIT, then processes the &init data by understanding that command. Alan. |
From: Jens O. <je...@tu...> - 2002-03-28 17:29:42
|
Jeff Hartmann wrote: > The basic point of this exercise is to make it so we can hot swap driver > suites (or at least I'm pretty sure this is your goal.) Yes. > Why don't we just > make each device have its own xfree module for its os specific part? In an ideal world, we would have N OS independent drivers and M device independent platforms for drivers to plug into. That is a total of M+N modules to support. When we have device spefics and OS specifics in the same module, we have M*N modules to support. To push portability, you have to stay away from combining device specifics and OS specifics in the same module. I realize we have already crossed this line, but we should be doing everything we can to pull back and fix these areas and at least keep from adding to the M*N support burden we have today. M+N: Good M*N: Bad > > That > > way we can add/subtract/upgrade driver suites, and not upset the apple cart. > > Just seems like a whole lot easier solution to the problem. > > > > Adding another module load into each driver just sounds like a cleaner > > implementation, and it solves your problem. > > > The code specifically we're talking about is this kind of thing.... > > - if (drmRadeonInitCP(info->drmFD, &drmInfo) < 0) return FALSE; > + if (drmIOCTL(info->drmFD, DRM_IOCTL_RADEON_CP_INIT, &init) < 0) > > We're passing exactly the same information, apart from now, we're > passing a specific command. Alan Hourihane wrote: > We could rename drmIOCTL to drmCOMMAND and make it clear that it's > not an IOCTL we are calling, it just happens to be an IOCTL in the > linux layer. > The drmCOMMAND can be anything that the OS supports to do, and it > knows what we're are trying to do by passing RADEON_CP_INIT, then > processes the &init data by understanding that command. This morning, before reading this e-mail thread, I was working on this very issue, and did manage to remove the Linux specific semantics. I now have a generic mechanism, which includes explicit data passing information. I'll use your suggestion of naming it drmCOMMAND, except we'll have 4 verisions depending on data transfer type: drmCommandNone, drmCommandRead, drmCommandWrite, drmCommandWriteRead. The drmRadeonInitCP example becomes: - if (drmRadeonInitCP(info->drmFD, &drmInfo) < 0) return FALSE; + if (drmCommandWrite(info->drmFD, RADEON_INIT_CP, + &drmInfo, sizeof(drmRadeonInit)) < 0) -- /\ Jens Owen / \/\ _ je...@tu... / \ \ \ Steamboat Springs, Colorado |
From: Alan H. <al...@fa...> - 2002-03-28 09:32:10
|
On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: > Alan Hourihane wrote: > > > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote: > > > I've made some headway on this today, and could use some feedback based > > > on your BSD experience. I've attempted to move the packing of > > > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing > > > is the actual IOCTL request number. I can easily use the Linux number, > > > but I thought it might be better to have some OS independent offset. > > > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR > > > semantics in an OS independent way is going to be challenging. See > > > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line > > > 373 > > > > > > Here is an incomplete patch in case you are interested in the general > > > direction I was currently prototyping... > > > > > > Should I just use the Linux _IO* semantics and let other OS ports > > > twizzle this to get this working, or do you have any ideas on how we can > > > generate the proper semantics in a more general way. I think we will > > > need to generate these semantics at run time, not compile time. > > > > > Jens, > > > > The idea of offset's with an os dependent MAGIC_NUMBER sounds like > > the right idea. I also think that we go ahead and use the Linux _IO* > > semantics, as the *BSD just twizzles around these anyway at the moment. > > And until more OS's support the drm (or at least show some signs) then > > that's probably the best we can hope for. > > Okay, I'll use the Linux DRM semantics where are: > > ( (direction) << 30 | (size) << 16 | (type) << 8 | (request) << 0 ) > > where > > direction is: 0 for none, 1 for write, 2 for read and 3 for both > size is: size of record to be transfered > type is: 'd' for DRM drivers > request is: our OS independent offset > Jens, Doesn't the request identify it's direction ? Also, we should be able to hide the type in the Linux os support and not need to pass this ? I've just taken a closer look at the xf86drmRadeon.c code, and in drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. Going down this road though, we'll be pushing that back into the 2d/3d code which I don't think is the right way to go. I'm thinking more of Jeff's solution now, and what we could do..... If we take a minimalist xf86drm.c which makes the libdrm.a loadable module. Then within xf86drm.c we identify which sub-drm module to load (i.e. the driver's libradeon_drm.a - or something like that) and load it. For the *BSD's this code is a symlink from the Linux directory. We can already load a kernel module based on name via drmOpenByName, we could just implement another drmSubOpenByName command to load the sub module based on it's name. We've also got easy backwards compatibility this way too. Alan. |
From: Keith W. <ke...@tu...> - 2002-03-28 10:15:14
|
Alan Hourihane wrote: > > On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: > > Alan Hourihane wrote: > > > > > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote: > > > > I've made some headway on this today, and could use some feedback based > > > > on your BSD experience. I've attempted to move the packing of > > > > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing > > > > is the actual IOCTL request number. I can easily use the Linux number, > > > > but I thought it might be better to have some OS independent offset. > > > > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR > > > > semantics in an OS independent way is going to be challenging. See > > > > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line > > > > 373 > > > > > > > > Here is an incomplete patch in case you are interested in the general > > > > direction I was currently prototyping... > > > > > > > > Should I just use the Linux _IO* semantics and let other OS ports > > > > twizzle this to get this working, or do you have any ideas on how we can > > > > generate the proper semantics in a more general way. I think we will > > > > need to generate these semantics at run time, not compile time. > > > > > > > Jens, > > > > > > The idea of offset's with an os dependent MAGIC_NUMBER sounds like > > > the right idea. I also think that we go ahead and use the Linux _IO* > > > semantics, as the *BSD just twizzles around these anyway at the moment. > > > And until more OS's support the drm (or at least show some signs) then > > > that's probably the best we can hope for. > > > > Okay, I'll use the Linux DRM semantics where are: > > > > ( (direction) << 30 | (size) << 16 | (type) << 8 | (request) << 0 ) > > > > where > > > > direction is: 0 for none, 1 for write, 2 for read and 3 for both > > size is: size of record to be transfered > > type is: 'd' for DRM drivers > > request is: our OS independent offset > > > Jens, > > Doesn't the request identify it's direction ? > > Also, we should be able to hide the type in the Linux os support and > not need to pass this ? > > I've just taken a closer look at the xf86drmRadeon.c code, and in > drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. > > Going down this road though, we'll be pushing that back into the 2d/3d code > which I don't think is the right way to go. > > I'm thinking more of Jeff's solution now, and what we could do..... > > If we take a minimalist xf86drm.c which makes the libdrm.a loadable > module. Then within xf86drm.c we identify which sub-drm module to > load (i.e. the driver's libradeon_drm.a - or something like that) and > load it. For the *BSD's this code is a symlink from the Linux directory. > > We can already load a kernel module based on name via drmOpenByName, > we could just implement another drmSubOpenByName command to load the sub > module based on it's name. Linus is pretty clear that he'd only accept a single module per driver - ie a radeon.o, but not a drm_core.o + drm_radeon.o combo. Keith |
From: Alan H. <al...@fa...> - 2002-03-28 10:51:13
|
On Thu, Mar 28, 2002 at 10:13:04 +0000, Keith Whitwell wrote: > Alan Hourihane wrote: > > > > On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: > > > Alan Hourihane wrote: > > > > > > > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote: > > > > > I've made some headway on this today, and could use some feedback based > > > > > on your BSD experience. I've attempted to move the packing of > > > > > drmRadeonInitCP into the 2D ddx driver, and the main concern I'm seeing > > > > > is the actual IOCTL request number. I can easily use the Linux number, > > > > > but I thought it might be better to have some OS independent offset. > > > > > However, generating all the combinations of _IO, _IOR, _IOW and _IOWR > > > > > semantics in an OS independent way is going to be challenging. See > > > > > xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel/drm.h:line > > > > > 373 > > > > > > > > > > Here is an incomplete patch in case you are interested in the general > > > > > direction I was currently prototyping... > > > > > > > > > > Should I just use the Linux _IO* semantics and let other OS ports > > > > > twizzle this to get this working, or do you have any ideas on how we can > > > > > generate the proper semantics in a more general way. I think we will > > > > > need to generate these semantics at run time, not compile time. > > > > > > > > > Jens, > > > > > > > > The idea of offset's with an os dependent MAGIC_NUMBER sounds like > > > > the right idea. I also think that we go ahead and use the Linux _IO* > > > > semantics, as the *BSD just twizzles around these anyway at the moment. > > > > And until more OS's support the drm (or at least show some signs) then > > > > that's probably the best we can hope for. > > > > > > Okay, I'll use the Linux DRM semantics where are: > > > > > > ( (direction) << 30 | (size) << 16 | (type) << 8 | (request) << 0 ) > > > > > > where > > > > > > direction is: 0 for none, 1 for write, 2 for read and 3 for both > > > size is: size of record to be transfered > > > type is: 'd' for DRM drivers > > > request is: our OS independent offset > > > > > Jens, > > > > Doesn't the request identify it's direction ? > > > > Also, we should be able to hide the type in the Linux os support and > > not need to pass this ? > > > > I've just taken a closer look at the xf86drmRadeon.c code, and in > > drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. > > > > Going down this road though, we'll be pushing that back into the 2d/3d code > > which I don't think is the right way to go. > > > > I'm thinking more of Jeff's solution now, and what we could do..... > > > > If we take a minimalist xf86drm.c which makes the libdrm.a loadable > > module. Then within xf86drm.c we identify which sub-drm module to > > load (i.e. the driver's libradeon_drm.a - or something like that) and > > load it. For the *BSD's this code is a symlink from the Linux directory. > > > > We can already load a kernel module based on name via drmOpenByName, > > we could just implement another drmSubOpenByName command to load the sub > > module based on it's name. > > Linus is pretty clear that he'd only accept a single module per driver - ie a > radeon.o, but not a drm_core.o + drm_radeon.o combo. > This isn't at the kernel level Keith. The libdrm.a and drafted libradeon_drm.a will be loaded via the Xserver. Alan. |
From: Keith W. <ke...@tu...> - 2002-03-28 11:43:25
|
> > > We can already load a kernel module based on name via drmOpenByName, > > > we could just implement another drmSubOpenByName command to load the sub > > > module based on it's name. > Sorry, got mixed up by this paragraph. Keith |
From: Michael <le...@nt...> - 2002-03-28 13:17:08
|
On Thu, Mar 28, 2002 at 10:13:04AM +0000, Keith Whitwell wrote: > Linus is pretty clear that he'd only accept a single module per driver - ie a > radeon.o, but not a drm_core.o + drm_radeon.o combo. He hasn't seen alsa or usb then...:) -- Michael. |
From: Mike W. <we...@cs...> - 2002-03-28 13:55:17
|
To be a bit more specific the 2.4.x sound system now loads something like (on my system) soundcore.o ~ drm_core.o cs46xx.o ~ drm_radeon.o (plus codec modules) Mike Michael wrote: > > On Thu, Mar 28, 2002 at 10:13:04AM +0000, Keith Whitwell wrote: > > Linus is pretty clear that he'd only accept a single module per driver - ie a > > radeon.o, but not a drm_core.o + drm_radeon.o combo. > > He hasn't seen alsa or usb then...:) > > -- > Michael. > > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel |
From: David D. <da...@tu...> - 2002-03-28 16:15:33
|
On Thu, Mar 28, 2002 at 09:31:40AM +0000, Alan Hourihane wrote: >On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: >Also, we should be able to hide the type in the Linux os support and >not need to pass this ? > >I've just taken a closer look at the xf86drmRadeon.c code, and in >drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. > >Going down this road though, we'll be pushing that back into the 2d/3d code >which I don't think is the right way to go. > >I'm thinking more of Jeff's solution now, and what we could do..... > >If we take a minimalist xf86drm.c which makes the libdrm.a loadable >module. Then within xf86drm.c we identify which sub-drm module to >load (i.e. the driver's libradeon_drm.a - or something like that) and >load it. For the *BSD's this code is a symlink from the Linux directory. I'm losing track of what the goal was with the changes. If it was to remove hw-specifics from the libdrm.a module, then I think Jeff's idea of pushing them into a separate HW-specific module is worth looking at. By doing this, it might even be feasible to make libdrm.a part of the (built-in) OS-support layer. Stepping back a bit, the current model puts different types of dependencies in different places. The XFree86 video driver module contains HW dependencies, but should have no OS dependencies. The libdrm.a module contains both HW and OS dependencies. I guess the aim is to separate that into the HW-dependent and HW-independent pieces? One problem I had with simply changing the libdrm.a interfaces is that it doesn't succeed in making that separation. Something in libdrm.a still needs to know how to translate a HW-specific command into whatever is appropriate for the OS. I.e, there's nothing conceptually different between drmRadeonCPStop(args) and drmCOMMAND(RADEON_CP_STOP, args), unless the token RADEON_CP_STOP can be passed transparently to the HW+OS specific component that will actually do the requested operation. With Jeff's suggestion there would be several components: video driver module (HW specific, OS independent) core libdrm module (HW independent, OS specific, so part of core server?) HW libdrm module (HW specific, OS specific) The question this raises is what do we gain from this? What would actually be in the core libdrm module -- is there enough there to justify separating out the HW-specific parts? If the HW libdrm module could be made HW specific and OS independent, then that would be a big win, and it could even be moved into the video driver module in that case. This would simplify things to the point where the OS-specific parts are built-in to the X server and the HW specific parts are all in the video driver module. David -- David Dawes Senior X Architect Tungsten Graphics, Inc www.XFree86.org/~dawes www.tungstengraphics.com |
From: Kevin E M. <ke...@re...> - 2002-03-28 16:24:58
|
On Thu, Mar 28, 2002 at 11:15:25AM -0500, David Dawes wrote: > On Thu, Mar 28, 2002 at 09:31:40AM +0000, Alan Hourihane wrote: > >On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote: > > >Also, we should be able to hide the type in the Linux os support and > >not need to pass this ? > > > >I've just taken a closer look at the xf86drmRadeon.c code, and in > >drmRadeonCPStop we're issuing 3 ioctl's to flush, and idle the CP. > > > >Going down this road though, we'll be pushing that back into the 2d/3d code > >which I don't think is the right way to go. > > > >I'm thinking more of Jeff's solution now, and what we could do..... > > > >If we take a minimalist xf86drm.c which makes the libdrm.a loadable > >module. Then within xf86drm.c we identify which sub-drm module to > >load (i.e. the driver's libradeon_drm.a - or something like that) and > >load it. For the *BSD's this code is a symlink from the Linux directory. > > I'm losing track of what the goal was with the changes. If it was > to remove hw-specifics from the libdrm.a module, then I think Jeff's > idea of pushing them into a separate HW-specific module is worth looking at. > By doing this, it might even be feasible to make libdrm.a part of the > (built-in) OS-support layer. > > Stepping back a bit, the current model puts different types of > dependencies in different places. The XFree86 video driver module > contains HW dependencies, but should have no OS dependencies. The libdrm.a > module contains both HW and OS dependencies. I guess the aim is to > separate that into the HW-dependent and HW-independent pieces? > > One problem I had with simply changing the libdrm.a interfaces is > that it doesn't succeed in making that separation. Something in > libdrm.a still needs to know how to translate a HW-specific command > into whatever is appropriate for the OS. I.e, there's nothing > conceptually different between drmRadeonCPStop(args) and > drmCOMMAND(RADEON_CP_STOP, args), unless the token RADEON_CP_STOP > can be passed transparently to the HW+OS specific component that > will actually do the requested operation. > > With Jeff's suggestion there would be several components: > > video driver module (HW specific, OS independent) > core libdrm module (HW independent, OS specific, so part of core server?) > HW libdrm module (HW specific, OS specific) > > The question this raises is what do we gain from this? What would > actually be in the core libdrm module -- is there enough there to > justify separating out the HW-specific parts? > > If the HW libdrm module could be made HW specific and OS independent, > then that would be a big win, and it could even be moved into the > video driver module in that case. This would simplify things to > the point where the OS-specific parts are built-in to the X server > and the HW specific parts are all in the video driver module. Thank you David. I was just starting to write up my thoughts, and found that you've covered everything that I was concerned about. So, I would like to echo David's concerns and look forward to hearing more about the motivation for the proposed changes. Thanks, Kevin ------------------------------------------------------------------------ Kevin E. Martin Core Team Member, The XFree86 Project, Inc. Chapel Hill, NC Senior Software Architect, Red Hat, Inc. |
From: Jeff H. <jha...@ad...> - 2002-03-28 16:51:15
|
-----Original Message----- From: dri...@li... [mailto:dri...@li...]On Behalf Of Kevin E Martin Sent: Thursday, March 28, 2002 8:25 AM To: David Dawes Cc: dri-devel Subject: Re: [Dri-devel] Restoring DRM Library Device Independence > I'm losing track of what the goal was with the changes. If it was > to remove hw-specifics from the libdrm.a module, then I think Jeff's > idea of pushing them into a separate HW-specific module is worth looking at. > By doing this, it might even be feasible to make libdrm.a part of the > (built-in) OS-support layer. I believe seperating out the hw dependancies to make binary releases easier is the reasoning for the change. I do think that perhaps making libdrm.a part of the built-in OS-support layer is an excellent idea. Even though it is a small change, this might give more people a reason to start porting to the drm to other OS'es. > > Stepping back a bit, the current model puts different types of > dependencies in different places. The XFree86 video driver module > contains HW dependencies, but should have no OS dependencies. The libdrm.a > module contains both HW and OS dependencies. I guess the aim is to > separate that into the HW-dependent and HW-independent pieces? Yes. > > One problem I had with simply changing the libdrm.a interfaces is > that it doesn't succeed in making that separation. Something in > libdrm.a still needs to know how to translate a HW-specific command > into whatever is appropriate for the OS. I.e, there's nothing > conceptually different between drmRadeonCPStop(args) and > drmCOMMAND(RADEON_CP_STOP, args), unless the token RADEON_CP_STOP > can be passed transparently to the HW+OS specific component that > will actually do the requested operation. It could be done, but its ugly and it makes too many assumptions about the underlying OS. Because of these assumptions I don't like an implementation of a drmCOMMAND (or ioctl, etc.) It just doesn't fit in an OS independant interface. > > With Jeff's suggestion there would be several components: > > video driver module (HW specific, OS independent) > core libdrm module (HW independent, OS specific, so part of core server?) > HW libdrm module (HW specific, OS specific) > > The question this raises is what do we gain from this? What would > actually be in the core libdrm module -- is there enough there to > justify separating out the HW-specific parts? > > The core libdrm module would have all the OS dependant parts that are HW independant. This is actually the bulk of what libdrm contains. The hardware specific portion is small, but can be very different for each card. We can actually then ship whole scale replacements to just a driver suite without having to change out other modules that ship with an OS distribution. This allows an upgraded driver suite to be installed over an Xserver installation without breaking other drivers. If each driver suite ships with a different libdrm.a we start having conflicts really quick. Binary releases become alot easier with this seperation. People like Redhat might start shipping driver upgrades only, rather then requiring a user with a broken driver to download a new Xserver. That is a very good thing for the end user in my opinion. In the current model, this sort of packaging is prohibited. -Jeff |