1. 25 May, 2012 4 commits
    • Ben Widawsky's avatar
      drm/i915: s/i915_wait_request/i915_wait_seqno/g · 199b2bc2
      Ben Widawsky authored
      
      
      Wait request is poorly named IMO. After working with these functions for
      some time, I feel it's much clearer to name the functions more
      appropriately.
      
      Of course we must update the callers to use the new name as well.
      
      This leaves room within our namespace for a *real* wait request function
      at some point.
      
      Note to maintainer: this patch is optional.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      199b2bc2
    • Ben Widawsky's avatar
      drm/i915: wait render timeout ioctl · 23ba4fd0
      Ben Widawsky authored
      
      
      This helps implement GL_ARB_sync but stops short of allowing full blown
      sync objects. Finally we can use the new timed seqno waiting function
      to allow userspace to wait on a buffer object with a timeout. This
      implements that interface.
      
      The IOCTL will take as input a buffer object handle, and a timeout in
      nanoseconds (flags is currently optional but will likely be used for
      permutations of flush operations). Users may specify 0 nanoseconds to
      instantly check.
      
      The wait ioctl with a timeout of 0 reimplements the busy ioctl. With any
      non-zero timeout parameter the wait ioctl will wait for the given number
      of nanoseconds on an object becoming unbusy. Since the wait itself does
      so holding struct_mutex the object may become re-busied before this
      completes. A similar but shorter race condition exists in the busy
      ioctl.
      
      v2: ETIME/ERESTARTSYS instead of changing to EBUSY, and EGAIN (Chris)
      Flush the object from the gpu write domain (Chris + Daniel)
      Fix leaked refcount in good case (Chris)
      Naturally align ioctl struct (Chris)
      
      v3: Drop lock after getting seqno to avoid ugly dance (Chris)
      
      v4: check for 0 timeout after olr check to allow polling (Chris)
      
      v5: Updated the comment. (Chris)
      
      v6: Return -ETIME instead of -EBUSY when timeout_ns is 0 (Daniel)
      Fix the commit message comment to be less ugly (Ben)
      Add a warning to check the return timespec (Ben)
      
      v7: Use DRM_AUTH for the ioctl. (Eugeni)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      23ba4fd0
    • Ben Widawsky's avatar
      drm/i915: improve i915_wait_request_begin trace · f3fd3768
      Ben Widawsky authored
      
      
      The trace events adds whether or not the wait was blocking. Blocking in
      this case means to hold struct_mutex (ie. no new work can be submitted
      during the wait). The information is inherently racy.
      
      The blocking information is racy since mutex_is_locked doesn't check
      that the current thread holds the lock. The only other option would be
      to pass the boolean information of whether or not the class was blocking
      down through the stack which is less desirable.
      
      v2: Don't do a trace event per loop. (Chris)
      Only get blocking/non-blocking info (Chris)
      
      v3: updated comment in code as well as commit msg (Daniel)
      Add "(NB)" to trace information to remind us in 6 months (Ben)
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f3fd3768
    • Ben Widawsky's avatar
      drm/i915: timeout parameter for seqno wait · 5c81fe85
      Ben Widawsky authored
      
      
      Insert a wait parameter in the code so we can possibly timeout on a
      seqno wait if need be. The code should be functionally the same as
      before because all the callers will continue to retry if an arbitrary
      timeout elapses.
      
      We'd like to have nanosecond granularity, but the only way to do this is
      with hrtimer, and that doesn't fit well with the needs of this code.
      
      v2: Fix rebase error (Chris)
      Return proper time even in wedged + signal case (Chris + Ben)
      Use timespec constructs (Ben)
      Didn't take Daniel's advice regarding the Frankenstein-ness of the
        function. I did try his advice, but in the end I liked the way the
        original code looked, better.
      
      v3: Make wakeups far less frequent for infinite waits (Chris)
      
      v4: Remove dummy_wait variable (Daniel)
      Use raw monotonic time instead of jiffies (made the code a bit cleaner) (Ben)
      Added a couple of warnings (Ben)
      
      v5: Remove warnings (Daniel)
      Use more accurate time diff for default case (Daniel)
      Bikeshed for setting the return timespec in timeout case (Daniel)
      s/jiffies/time in one of the comments
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      5c81fe85
  2. 22 May, 2012 2 commits
  3. 21 May, 2012 6 commits
    • Chris Wilson's avatar
    • Chris Wilson's avatar
      drm/i915/hdmi: Query the live connector status bit for G4x · 8ec22b21
      Chris Wilson authored
      
      
      Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to
      whether the connector is active prior to attempting to retrieve the EDID.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      8ec22b21
    • Chris Wilson's avatar
      drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x · 084b612e
      Chris Wilson authored
      
      
      Note that gen3 is the only platform where we've got the bit
      definitions right, hence the workaround of disabling sdvo hotplug
      support on i945g/gm is not due to misdiagnosis of broken hotplug irq
      handling ...
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: add some blurb about sdvo hotplug fail on i945g/gm I've
      wondered about while reviewing.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      084b612e
    • Chris Wilson's avatar
      drm/i915: Inspect the right status bits for DP/HDMI hotplug on gen4 · 10f76a38
      Chris Wilson authored
      
      
      The status bits corresponding to the interrupt enable bits are the
      "live" hotplug status bits, and reflect the current status of the port
      (high for a detected connection, low for a disconnect). The actual bits
      corresponding to the interrupt source are elsewhere. The actual event is
      then determined by a combination of the interrupt flag and the current
      live status (if the interrupt is active, but the current status is not,
      then we have detected a disconnect.)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      10f76a38
    • Chris Wilson's avatar
      drm/i915: All members of gen4 have hotplug, so unconditionally enable its irq · adca4730
      Chris Wilson authored
      
      
      Also as we set the HOTPLUG_EN to 0 during pre-install, we can simply set
      it during post-install, and nor do we wish to enable unwanted hotplug
      events.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      adca4730
    • Dave Airlie's avatar
      Merge tag 'drm-intel-next-2012-05-20' of... · f15b4ca2
      Dave Airlie authored
      Merge tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next
      
      Daniel wrote:
      
      The last pull I'd like to squeeze into 3.5, safe for the hsw stuff mostly
      bugfixes:
      - last few patches for basic hsw enabling (Eugeni, infoframe support by
       Paulo)
      - Fix up infoframe support, we've hopefully squashed all the cargo-culting
       in there (Paulo). Among all the issues, this finally fixes some of the
       infoframe regressions seen on g4x and snb systems.
      - Fixup sdvo infoframe support, this fixes a regression from 2.6.37.
      - Correctly enable semaphores on snb, we've enabled it already for 3.5,
       but the dmar check was slightly wrong.
      - gen6 irq fixlets from Chris.
      - disable gmbus on i830, the hw seems to be simply broken.
      - fix up the pch pll fallout (Chris & me).
      - for_each_ring macro from Chris - I've figured I'll merge this now to
       avoid backport pain.
      - complain when the rps state isn't what we expect (Chris). Note that this
       is shockingly easy to hit and hence pretty much will cause a regression
       report. But it only tells us that the gpu turbo state got out of whack,
       a problem we know off since a long time (it cause the gpu to get stuck a
       a fixed frequency, usually the lowest one). Chris is working on a fix,
       but we haven't yet found a magic formula that works perfectly (only
       patches that massively reduce the frequency of this happening).
      - MAINTAINERS patch, I'm now officially the guy to beat up."
      
      * tag 'drm-intel-next-2012-05-20' of git://people.freedesktop.org/~danvet/drm-intel: (57 commits)
        drm/i915: IBX has a fixed pch pll to pch pipe mapping
        drm/i915: implement hsw_write_infoframe
        drm/i915: small hdmi coding style cleanups
        drm/i915: fixup infoframe support for sdvo
        drm/i915: Enable the PCH PLL for all generations after link training
        drm/i915: Convert BUG_ON(!pll->active) and friends to a WARN
        drm/i915: don't clobber the pipe param in sanitize_modesetting
        drm/i915: disable gmbus on i830
        drm/i915: Replace the feature tests for BLT/BSD with ring init checks
        drm/i915: Check whether the ring is initialised prior to dispatch
        drm/i915: Introduce for_each_ring() macro
        drm/i915: Assert that the transcoder is indeed off before modifying it
        drm/i915: hook Haswell devices in place
        drm/i915: prepare HDMI link for Haswell
        drm/i915: move HDMI structs to shared location
        drm/i915: add WR PLL programming table
        drm/i915: add support for DDI-controlled digital outputs
        drm/i915: detect digital outputs on Haswell
        drm/i915: program iCLKIP on Lynx Point
        drm/i915: program WM_LINETIME on Haswell
        ...
      f15b4ca2
  4. 20 May, 2012 5 commits
  5. 19 May, 2012 23 commits