Re: Multiple hardware locks
> --- Thomas Hellström <[EMAIL PROTECTED]> wrote: > >> >> You are probably right, and it would be quite easy to implement such >> checks in the via command verifier as long as each lock is associated >> with >> a certain hardware address range. >> >> However, I don't quite see the point in plugging such a security hole >> when >> there are a similar ways to accomplish DOS, hardware crashes and even >> complete lockups using DRI. >> > The ideas is to plug all of them, soner or later. > Ok, I'll buy this. I'll implement a command queue check if I go for the multiple lock thing. AMEN ;) /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Other security issue (WAS Re: Multiple hardware locks)
Michel DÃnzer wrote: On Mon, 2004-11-01 at 14:21 +0100, Thomas HellstrÃm wrote: Hmm, correct me If I'm wrong, but after a brief check in the code, it seems like the current _DRM_LOCK_IS_HELD() used in dma buffer submission IOCTLS just checks that the lock is indeed held, but not if it is held by the current caller. Thus any authorized client should be able to sneek in DMA commands while the lock is held by another client or the X server. -> potential system crash. Hence _DRM_LOCK_IS_HELD() always seems to be (supposed to be) accompanied by another test that verifies the ownership. Michael, I just checked i830_dma.c, i915_dma.c and via_dma.c, and _DRM_LOCK_IS_HELD() is used without such a test, AFAICT. The correct macro to call seems to be LOCK_TEST_WITH_RETURN() which does incorporate such a test. In fact, the use of _DRM_LOCK_IS_HELD() here should allow malfunctioning or malicious SMP dri clients to modify internal drm data structures and DMA ring-buffers simultaneously? /Thomas
Re: Multiple hardware locks
On Mon, 2004-11-01 at 14:21 +0100, Thomas HellstrÃm wrote: > > Hmm, correct me If I'm wrong, but after a brief check in the code, it > seems like the current _DRM_LOCK_IS_HELD() used in dma buffer > submission IOCTLS just checks that the lock is indeed held, but not if > it is held by the current caller. Thus any authorized client should be > able to sneek in DMA commands while the lock is held by another client > or the X server. -> potential system crash. Hence _DRM_LOCK_IS_HELD() always seems to be (supposed to be) accompanied by another test that verifies the ownership. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Nicolai Haehnle <[EMAIL PROTECTED]> wrote: > On Monday 01 November 2004 07:01, Thomas Hellström wrote: > > You are probably right, and it would be quite easy to implement such > > checks in the via command verifier as long as each lock is associated > with > > a certain hardware address range. > > > > However, I don't quite see the point in plugging such a security hole > when > > there are a similar ways to accomplish DOS, hardware crashes and even > > complete lockups using DRI. > > > > On via, for example, writing random data to the framebuffer, writing > > random data to the sarea, taking the hardware lock and sleeping for an > > indefinite amount of time. Writing certain data sequences to the HQV > locks > > the north bridge etc. > > > > Seems like DRI allow authorized clients to do these things by design? > > From what I've learned, the DRI isn't exactly designed for robustness. > Still, an authorized client should never be able to cause a hardware > crash/lockup, and an authorized client must not be able to issue > arbitrary > DMA requests. As far as I know, all DRMs that are enabled by default > enforce at least the latter. > > Personally I believe that in the long term, the DRI should have (at > least) > the following security properties: > 1. Protect against arbitrary DMA (arbitrary DMA trivially allows > circumvention of process boundaries) > This can be done via command-stream checks. > > 2. Prevent hardware lockup or provide a robust recovery mechanism > (protection of multi-user systems, as well as data protection) > Should be relatively cheap via command-stream checks on most hardware > (unless there are crazy hardware problems with command ordering like > there This is something I think has been discussed. Hopefully the DRM currently varifies the cmd stream so that only the order in DRI's client side drivers is accepted. Other ordering could be fixed, sine the size of the cmds dosen't change, by simply memcpy'ing every thing into this right order. > seem to be on some Radeons). I believe that in the long term, recovery > should be in the kernel rather than the X server. > > 3. Make sure that no client can cause another client to crash > (malfunctioning clients shouldn't cause data loss in other applications) > In other words, make sure that a DRI client can continue even if the > shared > memory areas are overwritten with entirely random values. That does seem > > like a daunting task. > > 4. Make sure that no client can block access to the hardware forever > (don't > force the user to reboot) > I have posted a watchdog patch that protects against the "take lock, > sleep > forever" problem a long time ago. The patch has recently been updated by > > Dieter Nützel (search for updated drm.watchdog.3). However, I have to > admit > that the patch doesn't feel quite right to me. > > 5. Enable the user to kill/suspend resource hogs > Even if we protect against lock abuse, a client could still use > excessive > amounts of texture memory (thus causing lots of swap) or emit rendering > calls that take extremely long to execute. That kills latency and makes > the > system virtually unusable. Perhaps the process that authorizes DRI > clients > should be able to revoke or suspend that authorization. A suspend would > essentially mean that drmGetLock waits until the suspend is lifted. > > I know that actually implementing these things in such a way that they > Just > Work is not a pleasant task. I just felt like sharing a brain dump. > > cu, > Nicolai > > ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström <[EMAIL PROTECTED]> wrote: > > You are probably right, and it would be quite easy to implement such > checks in the via command verifier as long as each lock is associated > with > a certain hardware address range. > > However, I don't quite see the point in plugging such a security hole > when > there are a similar ways to accomplish DOS, hardware crashes and even > complete lockups using DRI. > The ideas is to plug all of them, soner or later. > On via, for example, writing random data to the framebuffer, writing > random data to the sarea, taking the hardware lock and sleeping for an > indefinite amount of time. Writing certain data sequences to the HQV > locks > the north bridge etc. > > Seems like DRI allow authorized clients to do these things by design? > > > /Thomas > > > > > > > > > > > > > > > > __ > > Do you Yahoo!? > > Yahoo! Mail - You care about security. So do we. > > http://promotions.yahoo.com/new_mail > > > > > __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Thomas Hellström wrote: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. This sounds conceptually similar to waiting for the vertical retrace. It sounds like what you really want is an ioctl to wait for the MPEG engine to complete and acquire the lock. Is it possible to have the engine generate an interrupt when it's done with a certain frame? If so, you could have the hardware do that, and have the ioctl make the process sleep until the interrpt arrives. At that point acquire the existing heavy-weight lock and return. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Nicolai Haehnle wrote: On Monday 01 November 2004 07:01, Thomas Hellström wrote: You are probably right, and it would be quite easy to implement such checks in the via command verifier as long as each lock is associated with a certain hardware address range. However, I don't quite see the point in plugging such a security hole when there are a similar ways to accomplish DOS, hardware crashes and even complete lockups using DRI. On via, for example, writing random data to the framebuffer, writing random data to the sarea, taking the hardware lock and sleeping for an indefinite amount of time. Writing certain data sequences to the HQV locks the north bridge etc. Seems like DRI allow authorized clients to do these things by design? >From what I've learned, the DRI isn't exactly designed for robustness. Still, an authorized client should never be able to cause a hardware crash/lockup, and an authorized client must not be able to issue arbitrary DMA requests. As far as I know, all DRMs that are enabled by default enforce at least the latter. Personally I believe that in the long term, the DRI should have (at least) the following security properties: 1. Protect against arbitrary DMA (arbitrary DMA trivially allows circumvention of process boundaries) This can be done via command-stream checks. Hmm, correct me If I'm wrong, but after a brief check in the code, it seems like the current _DRM_LOCK_IS_HELD() used in dma buffer submission IOCTLS just checks that the lock is indeed held, but not if it is held by the current caller. Thus any authorized client should be able to sneek in DMA commands while the lock is held by another client or the X server. -> potential system crash. /Thomas
Re: Multiple hardware locks
On Monday 01 November 2004 07:01, Thomas Hellström wrote: > You are probably right, and it would be quite easy to implement such > checks in the via command verifier as long as each lock is associated with > a certain hardware address range. > > However, I don't quite see the point in plugging such a security hole when > there are a similar ways to accomplish DOS, hardware crashes and even > complete lockups using DRI. > > On via, for example, writing random data to the framebuffer, writing > random data to the sarea, taking the hardware lock and sleeping for an > indefinite amount of time. Writing certain data sequences to the HQV locks > the north bridge etc. > > Seems like DRI allow authorized clients to do these things by design? From what I've learned, the DRI isn't exactly designed for robustness. Still, an authorized client should never be able to cause a hardware crash/lockup, and an authorized client must not be able to issue arbitrary DMA requests. As far as I know, all DRMs that are enabled by default enforce at least the latter. Personally I believe that in the long term, the DRI should have (at least) the following security properties: 1. Protect against arbitrary DMA (arbitrary DMA trivially allows circumvention of process boundaries) This can be done via command-stream checks. 2. Prevent hardware lockup or provide a robust recovery mechanism (protection of multi-user systems, as well as data protection) Should be relatively cheap via command-stream checks on most hardware (unless there are crazy hardware problems with command ordering like there seem to be on some Radeons). I believe that in the long term, recovery should be in the kernel rather than the X server. 3. Make sure that no client can cause another client to crash (malfunctioning clients shouldn't cause data loss in other applications) In other words, make sure that a DRI client can continue even if the shared memory areas are overwritten with entirely random values. That does seem like a daunting task. 4. Make sure that no client can block access to the hardware forever (don't force the user to reboot) I have posted a watchdog patch that protects against the "take lock, sleep forever" problem a long time ago. The patch has recently been updated by Dieter Nützel (search for updated drm.watchdog.3). However, I have to admit that the patch doesn't feel quite right to me. 5. Enable the user to kill/suspend resource hogs Even if we protect against lock abuse, a client could still use excessive amounts of texture memory (thus causing lots of swap) or emit rendering calls that take extremely long to execute. That kills latency and makes the system virtually unusable. Perhaps the process that authorizes DRI clients should be able to revoke or suspend that authorization. A suspend would essentially mean that drmGetLock waits until the suspend is lifted. I know that actually implementing these things in such a way that they Just Work is not a pleasant task. I just felt like sharing a brain dump. cu, Nicolai pgpkLU7ArzKbS.pgp Description: PGP signature
Re: Multiple hardware locks
Thomas Hellström wrote: On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote: Keith Whitwell wrote: Thomas Hellström wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. The first question is - have you found that lock contention is actually a problem? I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises "Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers"? But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence. The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. Do you not have interrupts that either signal MPEG engine idle, or just sw interrupts you can drop in the command stream? That would let you sleep waiting for them (rather than spinning, a win in itself) and you wouldn't have to hold the hardware lock. You're right. Unfortunately the MPEG interrupt is not functioning on the CLE266 (HW bug according to VIA). Also there doesn't seem to be a SW command stream interrupt either. Not even a command stream completion interrupt. How frustrating... I'd like to investigate all possiblities for getting some sort of synchronization information out of the hardware as this would seem to address your problem more directly & would hopefully keep the VIA driver looking more like the other drivers. At very worst, there is the technique of adding a tiny little blit command to write a timestamp (ie 32bit color) to a piece of offscreen memory. Processes waiting for certain events should be able to poll the timestamp without holding the lock. Better would be to have the hardware blit or write back to a piece of system memory. You're still stuck with polling unless there is some IRQ (any IRQ) that can be enlisted for synchronization. Keith --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
> On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote: >> Keith Whitwell wrote: >> >> > Thomas Hellström wrote: >> > >> >> Hi, list! >> >> >> >> With display cards that have more and more hardware on them, >> >> (TV-capture, mpeg decoders) etc. that can work independently of >> >> oneanother, but share the same DMA engine I've find the need for more >> >> than one hardware lock. >> > >> > >> > The first question is - have you found that lock contention is >> > actually a problem? >> > >> >> I've done a simple implementation for the mpeg decoder of the via >> >> driver, but that one doesn't cover the DMA case. The question arises >> >> "Why should I need to wait for DMA quiescent to check whether the >> >> decoder is done with a frame, if there is no decoder data in any of >> >> the pending DMA buffers"? >> > >> > >> > But this question isn't really answered by having multiple locks - it >> > sounds more like you want some sort of IRQ notification or >> > timestamping mechanism. Under normal circumstances grabbing the lock >> > doesn't mean waiting for DMA quiescence. >> > >> The typical case here: >> >> I want a DRI client to flip a video frame to screen, using a hardware >> entity called the HQV. This is a rather time critical operation. To do >> this I have to take the hardware lock. >> >> While this is happening, another thread is waiting for the mpeg decoder >> to complete a frame. To to that, this thread needs to take the hardware >> lock, wait for quiescent DMA, and then wait for the mpeg decoder to >> signal idle. It might be that the DMA command queue does not even >> contain mpeg data. This waiting delays the frame flip enough to create a >> visible jump in the video. >> >> With multiple locks: >> >> The first thread checks the HQV lock, it is available and frame flipping >> is done immediately. >> >> The other thread meanwhile takes the MPEG engine lock, waits until the >> DMA engine has processed all MPEG commands in the command queue and then >> waits for the MPEG engine to be idle. DMA might still be processing 3D >> commands. > > Do you not have interrupts that either signal MPEG engine idle, or just > sw interrupts you can drop in the command stream? That would let you > sleep waiting for them (rather than spinning, a win in itself) and you > wouldn't have to hold the hardware lock. You're right. Unfortunately the MPEG interrupt is not functioning on the CLE266 (HW bug according to VIA). Also there doesn't seem to be a SW command stream interrupt either. Not even a command stream completion interrupt. /Thomas > > -- > Eric Anholt[EMAIL PROTECTED] > http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] > > --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
> --- Thomas Hellström <[EMAIL PROTECTED]> wrote: > >> Keith Whitwell wrote: >> >> The typical case here: >> >> I want a DRI client to flip a video frame to screen, using a hardware >> entity called the HQV. This is a rather time critical operation. To do >> this I have to take the hardware lock. >> >> While this is happening, another thread is waiting for the mpeg decoder >> to complete a frame. To to that, this thread needs to take the hardware >> lock, wait for quiescent DMA, and then wait for the mpeg decoder to >> signal idle. It might be that the DMA command queue does not even >> contain mpeg data. This waiting delays the frame flip enough to create a >> >> visible jump in the video. >> >> With multiple locks: >> >> The first thread checks the HQV lock, it is available and frame flipping >> >> is done immediately. >> >> The other thread meanwhile takes the MPEG engine lock, waits until the >> DMA engine has processed all MPEG commands in the command queue and then >> >> waits for the MPEG engine to be idle. DMA might still be processing 3D >> commands. >> >> Only while submitting command buffer data. This will hopefully be a very >> >> fast operation. The IOCTL copying this data to the ringbuffer will check >> >> that all locks are held for the hardware entities that the submitted >> command batch touches. The user will have to tell the IOCTL which >> entities these are, or possibly the command verifier checks this but I >> consider that an overkill since that is more of a bug-check than a >> security check. >> > Part of security is making sure authorised users can't make changes to > other users tasks. In this case killing all the tasks, by causing a > hardware fault, is a good example. It's a fackt that any user with rights > to the DRM device can use any other code or program to play with the card > or send junk into the cmd streem. The DRM should detect and prevent this, > even if it means a slight proformance loss. > > Can I get an AMEN? You are probably right, and it would be quite easy to implement such checks in the via command verifier as long as each lock is associated with a certain hardware address range. However, I don't quite see the point in plugging such a security hole when there are a similar ways to accomplish DOS, hardware crashes and even complete lockups using DRI. On via, for example, writing random data to the framebuffer, writing random data to the sarea, taking the hardware lock and sleeping for an indefinite amount of time. Writing certain data sequences to the HQV locks the north bridge etc. Seems like DRI allow authorized clients to do these things by design? /Thomas > > > > > > __ > Do you Yahoo!? > Yahoo! Mail - You care about security. So do we. > http://promotions.yahoo.com/new_mail > --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström <[EMAIL PROTECTED]> wrote: > Keith Whitwell wrote: > > The typical case here: > > I want a DRI client to flip a video frame to screen, using a hardware > entity called the HQV. This is a rather time critical operation. To do > this I have to take the hardware lock. > > While this is happening, another thread is waiting for the mpeg decoder > to complete a frame. To to that, this thread needs to take the hardware > lock, wait for quiescent DMA, and then wait for the mpeg decoder to > signal idle. It might be that the DMA command queue does not even > contain mpeg data. This waiting delays the frame flip enough to create a > > visible jump in the video. > > With multiple locks: > > The first thread checks the HQV lock, it is available and frame flipping > > is done immediately. > > The other thread meanwhile takes the MPEG engine lock, waits until the > DMA engine has processed all MPEG commands in the command queue and then > > waits for the MPEG engine to be idle. DMA might still be processing 3D > commands. > > Only while submitting command buffer data. This will hopefully be a very > > fast operation. The IOCTL copying this data to the ringbuffer will check > > that all locks are held for the hardware entities that the submitted > command batch touches. The user will have to tell the IOCTL which > entities these are, or possibly the command verifier checks this but I > consider that an overkill since that is more of a bug-check than a > security check. > Part of security is making sure authorised users can't make changes to other users tasks. In this case killing all the tasks, by causing a hardware fault, is a good example. It's a fackt that any user with rights to the DRM device can use any other code or program to play with the card or send junk into the cmd streem. The DRM should detect and prevent this, even if it means a slight proformance loss. Can I get an AMEN? __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote: > Keith Whitwell wrote: > > > Thomas Hellström wrote: > > > >> Hi, list! > >> > >> With display cards that have more and more hardware on them, > >> (TV-capture, mpeg decoders) etc. that can work independently of > >> oneanother, but share the same DMA engine I've find the need for more > >> than one hardware lock. > > > > > > The first question is - have you found that lock contention is > > actually a problem? > > > >> I've done a simple implementation for the mpeg decoder of the via > >> driver, but that one doesn't cover the DMA case. The question arises > >> "Why should I need to wait for DMA quiescent to check whether the > >> decoder is done with a frame, if there is no decoder data in any of > >> the pending DMA buffers"? > > > > > > But this question isn't really answered by having multiple locks - it > > sounds more like you want some sort of IRQ notification or > > timestamping mechanism. Under normal circumstances grabbing the lock > > doesn't mean waiting for DMA quiescence. > > > The typical case here: > > I want a DRI client to flip a video frame to screen, using a hardware > entity called the HQV. This is a rather time critical operation. To do > this I have to take the hardware lock. > > While this is happening, another thread is waiting for the mpeg decoder > to complete a frame. To to that, this thread needs to take the hardware > lock, wait for quiescent DMA, and then wait for the mpeg decoder to > signal idle. It might be that the DMA command queue does not even > contain mpeg data. This waiting delays the frame flip enough to create a > visible jump in the video. > > With multiple locks: > > The first thread checks the HQV lock, it is available and frame flipping > is done immediately. > > The other thread meanwhile takes the MPEG engine lock, waits until the > DMA engine has processed all MPEG commands in the command queue and then > waits for the MPEG engine to be idle. DMA might still be processing 3D > commands. Do you not have interrupts that either signal MPEG engine idle, or just sw interrupts you can drop in the command stream? That would let you sleep waiting for them (rather than spinning, a win in itself) and you wouldn't have to hold the hardware lock. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote: On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström <[EMAIL PROTECTED]> wrote: Wouldn't this severely break backwards binary compatibility with dri clients compiled with the old size of drm_sarea_t? You can't put them in drm_sarea_t. There is definitely code that will break if you do. I don't see anyway to extend drm_sarea_t without causing binary incompatibility. drm_sarea_t was just not designed with binary extension in mind. I haven't located any code that will break if you put them in the card specific sareas. Also you only have to check the driver for the card if you do it this way. The thing is that if I do that, and at some time in the future want to extend the number of locks, and at the same time have added other stuff after the locks in the private part of the sarea, I have a problem. Using the private part of the sarea also makes producing generic code somewhat harder. That's really why I wanted to allocate a separate sarea. /Thomas
Re: Multiple hardware locks
On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström <[EMAIL PROTECTED]> wrote: > Wouldn't this severely break backwards binary compatibility with dri clients > compiled with the old size of drm_sarea_t? You can't put them in drm_sarea_t. There is definitely code that will break if you do. I don't see anyway to extend drm_sarea_t without causing binary incompatibility. drm_sarea_t was just not designed with binary extension in mind. I haven't located any code that will break if you put them in the card specific sareas. Also you only have to check the driver for the card if you do it this way. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote:
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Data does not fit in SAREA\n");
return FALSE;
}
pDRIInfo->SAREASize = SAREA_MAX;
So if locks are going to be squeezed in somewhere I'd either have to fit
them in the XF86DRISAREARec or put them into every driver's private area.
You can't put them into XF86DRISAREARec because of code like this:
drmInfo.sarea_priv_offset = sizeof(drm_sarea_t);
drm_sarea_t is the same structure as XF86DRISAREARec.
Wouldn't this severely brake backwards binary compatibility with dri
clients compiled with the old size of drm_sarea_t?
Are the locks generic enough that all hardware needs them?
The idea was that if such an implementation exists and works, It could
be
used by any driver that found a potential gain.
The generic part would be just a number of locks sitting there if
somebody wanted
to use them. Each driver would have to assign a certain meaning to each
lock used.
For each lock there would be a way to resolve contention and to clear
the lock if the holder dies.
Still I'd have to make a working trial implementation for the VIA
driver. The important thing at this stage is to get the basic thoughts
right.
/Thomas
You can extend VIASAREAPriv (drm_via_sarea_t) without messing up the
above check. drm_via_sarea_t is much smaller than SAREA_MAX.
You will still need to negotiate an interface version since some
servers will know about the extended locks and others won't. You'll
have to revert to the big lock if all of the clients don't know about
the new lock scheme.
/Thomas
Re: Multiple hardware locks
--- Thomas Hellström <[EMAIL PROTECTED]> wrote: > Such a case would be a client submitting 2D engine commands while the X > server waits for 2D engine idle. Either this has to be implemented in > the command verifier or considered acceptable behaviour. Today any dri > client can continously clear the screen without taking the hardware > lock. > There are many factors that come into play. However if a potentialy hamfull interface can be fixed easily there may be no reason not to. __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Mike Mestnik wrote: --- Thomas Hellström <[EMAIL PROTECTED]> wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises "Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers"? In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected There is a problem with A "client" being able to lock/unlock resources it may/may not be using. It's important that Client's arn't able to DOS the system by submitting junk cmds /wo setting the right locs for that junk. Such a case would be a client submitting 2D engine commands while the X server waits for 2D engine idle. Either this has to be implemented in the command verifier or considered acceptable behaviour. Today any dri client can continously clear the screen without taking the hardware lock. by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
Re: Multiple hardware locks
Keith Whitwell wrote: Thomas Hellström wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. The first question is - have you found that lock contention is actually a problem? I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises "Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers"? But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence. The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. For many cards, there is a single dma-driven command queue, and the lock is used to protect that queue. All sorts of stuff (video, 2d, 3d) is delivered on the same queue. It sounds like the VIA driver follows a similar single-queue model. Yes. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. But it still sounds like there is a single ring buffer, right? Won't you need a lock to protect the ringbuffer? Won't everything have to grab that lock? Only while submitting command buffer data. This will hopefully be a very fast operation. The IOCTL copying this data to the ringbuffer will check that all locks are held for the hardware entities that the submitted command batch touches. The user will have to tell the IOCTL which entities these are, or possibly the command verifier checks this but I consider that an overkill since that is more of a bug-check than a security check. Also, how does direct framebuffer access work? The X server presumably now has to grab all of the locks, and likewise 3d fallbacks, to prevent all access to the framebuffer? The current heavyweight lock will protect framebuffer areas that are not managed by the drm memory manager. The IOCTL checking dma submission will check that this lock is held for 3d and 2d engine command submissions that touch this area. This will guarantee compatibility with the current DRI locking mechanism. Still, it will be possible to submit, for example. mpeg data to the command queue without taking the heavywieght lock, or submit 2d engine commands that blits one off-screen mpeg frame-buffer to another. These operations should not need to wait for software rendering into other parts of the frame-buffer. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? I guess I'm not sure which problem you're trying to solve. There are a couple I can think of so I'll list them here: - Lock contention. Under what circumstances? - Unnecessary flushing of the DMA queue/ringbuffer. IE. If you want to write to/read from a surface in video ram, how do you know when the video card has finished with it? - Something else? Keith
Re: Multiple hardware locks
--- Thomas Hellström <[EMAIL PROTECTED]> wrote: > Hi, list! > > With display cards that have more and more hardware on them, > (TV-capture, mpeg decoders) etc. that can work independently of > oneanother, but share the same DMA engine I've find the need for more > than one hardware lock. I've done a simple implementation for the mpeg > decoder of the via driver, but that one doesn't cover the DMA case. The > question arises "Why should I need to wait for DMA quiescent to check > whether the decoder is done with a frame, if there is no decoder data in > > any of the pending DMA buffers"? > > In the VIA / Unichrome case alone there is a need for even more such > locks for different parts of the chip if one were to make a clean > implementation of drivers for all features that are on the chip. > > My idea would be to extend drm with options for multiple locks, and I > suspect not only VIA cards could benefit from this. I was thinking of. > > 1. A separate sarea to contain these locks, to avoid messing up the > current sarea with binary incompatibilities as a consequence. > 2. Other kernel modules should be able to take and release these locks. > (V4L for example). > 3. Each DMA buffer is marked (or in the VIA case, each submission to the > > ring-buffer is marked) wether it accesses the resource that is protected > There is a problem with A "client" being able to lock/unlock resources it may/may not be using. It's important that Client's arn't able to DOS the system by submitting junk cmds /wo setting the right locs for that junk. > by a certain lock. > 4. A resource will become available to a client when the client has > taken the lock and there are no pending DMA buffers / parts of buffers > that are marked touching this resource. > 5. The client is responsible for reinitializing the resource once the > lock is taken. > > These are just initial thoughts. Is there a mechanism for this in DRM > today or could > it be done in a better way? > > /Thomas > > > > > > > > > --- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Thomas Hellström wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. The first question is - have you found that lock contention is actually a problem? I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises "Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers"? But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence. In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. For many cards, there is a single dma-driven command queue, and the lock is used to protect that queue. All sorts of stuff (video, 2d, 3d) is delivered on the same queue. It sounds like the VIA driver follows a similar single-queue model. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. But it still sounds like there is a single ring buffer, right? Won't you need a lock to protect the ringbuffer? Won't everything have to grab that lock? Also, how does direct framebuffer access work? The X server presumably now has to grab all of the locks, and likewise 3d fallbacks, to prevent all access to the framebuffer? These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? I guess I'm not sure which problem you're trying to solve. There are a couple I can think of so I'll list them here: - Lock contention. Under what circumstances? - Unnecessary flushing of the DMA queue/ringbuffer. IE. If you want to write to/read from a surface in video ram, how do you know when the video card has finished with it? - Something else? Keith --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
>
> /* For now the mapping works by using a fixed size defined
> * in the SAREA header
> */
> if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
> xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
> "Data does not fit in SAREA\n");
> return FALSE;
> }
> pDRIInfo->SAREASize = SAREA_MAX;
>
> So if locks are going to be squeezed in somewhere I'd either have to fit
> them in the XF86DRISAREARec or put them into every driver's private area.
You can't put them into XF86DRISAREARec because of code like this:
drmInfo.sarea_priv_offset = sizeof(drm_sarea_t);
drm_sarea_t is the same structure as XF86DRISAREARec.
Are the locks generic enough that all hardware needs them?
You can extend VIASAREAPriv (drm_via_sarea_t) without messing up the
above check. drm_via_sarea_t is much smaller than SAREA_MAX.
You will still need to negotiate an interface version since some
servers will know about the extended locks and others won't. You'll
have to revert to the big lock if all of the clients don't know about
the new lock scheme.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote:
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström
<[EMAIL PROTECTED]> wrote:
The idea of using a separate sarea is that it would be easy to extend the
number of locks and more suitable for more drivers than via. Otherwise one
idea would be to
fill the private sarea from the back, but that would break DDX tests for
size of usable area.
Different sareas are allocated using drmAddMap with type=DRM_SHM. The one
containing the current hardware lock is specified with the flag
DRM_CONTAINS_LOCK.
Shouldn't the sarea have been allocated by the driver in the first
place? Maybe this is another place for pemanent maps. I will probably
have to change this for multihead support running indenpendent X
servers. The current design assumes a master process that
creates/deletes sarea and that isn't the case for indepenent
multi-head.
Code like this is a mistake:
drmInfo.sarea_priv_offset = sizeof(drm_sarea_t);
The first member of drm_sarea_t should have been an offset to the
private sarea. Doing it that way would automatically adjust if the
size of drm_sarea_t is changed. Offset should have been filled in by
the DRM driver.
I don't see any code computing sizeof(drm_sarea_t) +
sizeof(drm_xxx_sarea_t). What is getting stored in the SAREA page
after the private area?
X contains code like
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) > SAREA_MAX) {
xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
"Data does not fit in SAREA\n");
return FALSE;
}
pDRIInfo->SAREASize = SAREA_MAX;
So if locks are going to be squeezed in somewhere I'd either have to
fit them in the
XF86DRISAREARec or put them into every driver's private area.
BTW, The "Old" drm functionality and design was very well documented by
precision insight / VAlinux. Now that permanent maps are introduced
and new requirements are made on the hw-specific drivers, is there a
chance that these documents could be updated?
Regards
Thomas
Re: Multiple hardware locks
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström <[EMAIL PROTECTED]> wrote: > The idea of using a separate sarea is that it would be easy to extend the > number of locks and more suitable for more drivers than via. Otherwise one > idea would be to > fill the private sarea from the back, but that would break DDX tests for > size of usable area. > > Different sareas are allocated using drmAddMap with type=DRM_SHM. The one > containing the current hardware lock is specified with the flag > DRM_CONTAINS_LOCK. Shouldn't the sarea have been allocated by the driver in the first place? Maybe this is another place for pemanent maps. I will probably have to change this for multihead support running indenpendent X servers. The current design assumes a master process that creates/deletes sarea and that isn't the case for indepenent multi-head. Code like this is a mistake: drmInfo.sarea_priv_offset = sizeof(drm_sarea_t); The first member of drm_sarea_t should have been an offset to the private sarea. Doing it that way would automatically adjust if the size of drm_sarea_t is changed. Offset should have been filled in by the DRM driver. I don't see any code computing sizeof(drm_sarea_t) + sizeof(drm_xxx_sarea_t). What is getting stored in the SAREA page after the private area? -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote: On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström <[EMAIL PROTECTED]> wrote: 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. It would probably be better to extend the current driver specific sarea. You can negotiate the driver interface version to enable the new functions. There should be room: #define SAREA_MAX 0x2000 Where is sarea allocated? I looked for five minutes and couldn't find it Hi! The idea of using a separate sarea is that it would be easy to extend the number of locks and more suitable for more drivers than via. Otherwise one idea would be to fill the private sarea from the back, but that would break DDX tests for size of usable area. Different sareas are allocated using drmAddMap with type=DRM_SHM. The one containing the current hardware lock is specified with the flag DRM_CONTAINS_LOCK. /Thomas 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström <[EMAIL PROTECTED]> wrote: > 1. A separate sarea to contain these locks, to avoid messing up the > current sarea with binary incompatibilities as a consequence. It would probably be better to extend the current driver specific sarea. You can negotiate the driver interface version to enable the new functions. There should be room: #define SAREA_MAX 0x2000 Where is sarea allocated? I looked for five minutes and couldn't find it. > 2. Other kernel modules should be able to take and release these locks. > (V4L for example). > 3. Each DMA buffer is marked (or in the VIA case, each submission to the > ring-buffer is marked) wether it accesses the resource that is protected > by a certain lock. > 4. A resource will become available to a client when the client has > taken the lock and there are no pending DMA buffers / parts of buffers > that are marked touching this resource. > 5. The client is responsible for reinitializing the resource once the > lock is taken. > > These are just initial thoughts. Is there a mechanism for this in DRM > today or could > it be done in a better way? > > /Thomas > > --- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > -- > ___ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel > -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88&alloc_id065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Multiple hardware locks
Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises "Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers"? In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
