Re: 2.6.14-rt4: via DRM errors

From: Thomas Hellström (unichrome_at_shipmail.org)
Date: 11/24/05

  • Next message: Andi Kleen: "Re: [PATCH] tiny improvement to x86_64 asm aes encryption" 
    Date:	Thu, 24 Nov 2005 13:50:21 +0100 (CET)
To: "Lee Revell" <rlrevell@joe-job.com>

    > On Thu, 2005-11-24 at 10:52 +0100, Thomas Hellström wrote:
    >> I made a fix to the locking code in main drm a couple of months ago.
    >>
    >> The X server tries to get the DRM_QUIESCENT lock, but when the wait
    >> was interrupted by a signal (like when you move a window around), the
    >> locking function returned without error. This made the X server
    >> release other clients' locks.
    >>
    >> This does affect all drivers with a quiescent() function. Not only
    >> via.
    >>
    >> But it looks like this fix never made it into the kernel source?
    >
    > Thanks.
    >
    > BTW can you point me to a good explanation of DRM locking? There's so
    > much indirection in the DRM code I can't even tell whether there's one
    > DRM lock or several, what kind of lock it is or what it's protecting
    > (beyond "access to the hardware"). Is it just an advisory lock used by
    > DRM clients to keep from stepping on each other? It doesn't seem
    > related to spinlocks or mutexes or any of the other types of lock in the
    > kernel.
    >
    > Lee

    There is some info in the old precision insight documentation about the
    DRI infrastructure, (can't seem to find a link right now) But generally
    there is only one global lock and something called the drawable spinlock
    that is apparently not used anymore. The global lock is similar to a
    futex, with the exception that the kernel is called both to resolve
    contention and whenever a new context is about to take the lock, so that
    optional context switching can take place, and also if the client requests
    that some special action should take place after locking is done, like
    wait for dma ready or quiescent. The lock should be taken before writing
    to the hardware or before submitting DMA commands. If you want to be
    _sure_ that noone else uses the hardware (like you want to read a
    particular register or something), you have to take the lock and wait for
    DMA quiescent. For example, if you want to make sure the video scaler is
    idle so you can write to it, you first take the lock so that noone else
    writes to it or to the DMA queue, then you wait for the DMA queue to be
    empty or make sure there are no pending commands for the scaler, then you
    wait for the scaler to become idle.

    The lock value is easily manipulated from user space and resides in one of
    the shared memory areas. I guess this means that with the current drm
    security policy it should be regarded as an advisory lock between drm
    clients.

    At one point I was about to implement a scheme for via with a number of
    similar locks, one for each independent function on the video chip, Like
    2D, 3D, Mpeg decoder, Video scaler 1 and 2, so that they didn't have to
    wait for eachother. The global lock would then only be taken to make sure
    that no drawables were touched by the X server or other clients while the
    lock was held, which would be compatible with how the X server works
    today. Never got around to do that, however, but the mpeg decoders have a
    futex scheme to prevent clients stepping on eachother. With that it is
    possible to have multiple clients use the same hw decoder.

    /Thomas

    >
    >
    >
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Andi Kleen: "Re: [PATCH] tiny improvement to x86_64 asm aes encryption"

    Relevant Pages

    • Re: Why Sony Will Die
      ... save for having used a codec and DRM which Microsoft developed. ... It's not the player that was the problem...it was the DRM system. ... I suppose when you buy a lock at the hardware store ... "Perfect for locking a child in a closet!" ...
      (alt.tv.tech.hdtv)
    • Re: 2.6.14-rt4: via DRM errors
      ... > I made a fix to the locking code in main drm a couple of months ago. ... BTW can you point me to a good explanation of DRM locking? ... DRM lock or several, what kind of lock it is or what it's protecting ...
      (Linux-Kernel)
    • Re: Why Sony Will Die
      ... It's not the player that was the problem...it was the DRM system. ... I suppose when you buy a lock at the hardware store ... "Perfect for locking a child in a closet!" ... How about the fact that they call it "Media Digital Rights ...
      (alt.tv.tech.hdtv)
    • Re: Electronic Publication
      ... >>> This discussion has involved both DRM and the DMCA. ... >> Don't you see a distinction between a lock on my door, ... > something where, if it is stolen, the owner won't know, or at least ...
      (rec.arts.sf.composition)
    • Re: Electronic Publication
      ... >> I lock my front door. ... >> DRM is locking everyone else in their houses, ... Laws which form the only protection you and I have from somebody ...
      (rec.arts.sf.composition)