1. 12 Apr, 2012 20 commits
    • Daniel Vetter's avatar
      drm/i915: re-init modeset hw state after gpu reset · f817586c
      Daniel Vetter authored
      After a gpu reset we need to re-init some of the hw state we only
      initialize when modeset is enabled, like rc6, hw contexts or render/GT
      core clock gating and workaround register settings.
      
      Note that this patch has a small change in the resume code:
      - rc6 on gen6+ is only restored for the modeset case (for more
        consistency with other callsites). This is no problem because recent
        kernels refuse to load drm/i915 without kms on gen6+
      - rc6/emon on ilk is only restored for the modeset case. This is no
        problem because rc6 is disabled by default on ilk, and ums on ilk
        has never really been a supported option outside of horrible rhel
        backports.
      
      v2: Chris Wilson noticed that we not only fail to restore the clock
      gating settings after gpu reset.
      
      v3: Move the call to modeset_init_hw in _reset out of the
      struct_mutext protected area - other callers don't hold it, too.
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f817586c
    • Chris Wilson's avatar
      drm/i915: Allow concurrent read access between CPU and GPU domain · f8413190
      Chris Wilson authored
      Similar to allowing a buffer to be simultaneously read by the GPU and
      through the GTT, we wish to allow readback of the pages through the CPU
      domain whilst they are also being read by the GPU. Domain coherency
      is managed by allowing multiple readers, but only a single writer.
      
      This is used by mesa for its program cache which it may search for every
      new program every frame and then renews should it need to add. During
      renewal, mesa copies the program bo currently executing through a CPU
      mapping onto the new bo. This patch allows the search and that copy to
      proceed without causing a stall on the current batch.
      
      Testcase: i-g-t/tests/gem_cpu_concurrent_blit
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      f8413190
    • Daniel Vetter's avatar
      drm/i915: simplify ppgtt setup · 211c568b
      Daniel Vetter authored
      We don't need the pt_addr for the !dmar case, so drop the else and
      move the if (dmar) condition out of the loop.
      
      v2: Fixup whitespace damage noticed by Chris Wilson.
      
      v3: Collapse the two identical if blocks. Chris Wilson makes me look
      like a moron right now ...
      Noticed-by: default avatarKonstantin Belousov <kostikbel@gmail.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wislon.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      211c568b
    • Jesse Barnes's avatar
      drm/i915: make DP configuration vars less confusing in ironlake_crtc_mode_se · e3aef172
      Jesse Barnes authored
      Both PCH and CPU eDP are DP, so set the is_dp flag to true.  Add
      is_cpu_edp and is_pch_edp bools to make checking for each less verbose
      (rather than has_edp_encoder && !intel_encoder_is_pch_edp() sprinkled
      everywhere).  And rename the "has_edp_encoder" variable to just
      "edp_encoder".
      
      With the above variables cleaned up, the rest of the code becomes a bit
      more readable and clear.
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e3aef172
    • Ben Widawsky's avatar
      drm/i915: rc6 in sysfs · 0136db58
      Ben Widawsky authored
      Merge rc6 information into the power group for our device. Until now the
      i915 driver has not had any sysfs entries (aside from the connector
      stuff enabled by drm core). Since it seems like we're likely to have
      more in the future I created a new file for sysfs stubs, as well as the
      rc6 sysfs functions which don't really belong elsewhere (perhaps
      i915_suspend, but most of the stuff is in intel_display,c).
      
      displays rc6 modes enabled (as a hex mask):
      cat /sys/class/drm/card0/power/rc6_enable
      
      displays #ms GPU has been in rc6 since boot:
      cat /sys/class/drm/card0/power/rc6_residency_ms
      
      displays #ms GPU has been in deep rc6 since boot:
      cat /sys/class/drm/card0/power/rc6p_residency_ms
      
      displays #ms GPU has been in deepest rc6 since boot:
      cat /sys/class/drm/card0/power/rc6pp_residency_ms
      
      Important note: I've seen on SNB that even when RC6 is *not* enabled the
      rc6 register seems to have a random value in it. I can only guess at the
      reason reason for this. Those writing tools that utilize this value need
      to be careful and probably want to scrutinize the value very carefully.
      
      v2: use common rc6 residency units to milliseconds for the other RC6 types
      
      v3: don't create sysfs files for GEN <= 5
      add a rc6_enable to show a mask of enabled rc6 types
      use unmerge instead of remove for sysfs group
      squash intel_enable_rc6() extraction into this patch
      
      v4: rename sysfs files (Chris)
      
      CC: Chris Wilson <chris@chris-wilson.co.uk>
      CC: Daniel Vetter <daniel.vetter@ffwll.ch>f
      CC: Arjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarBen Widawsky <benjamin.widawsky@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      [danvet: squash in the 64bit division fix by Chris Wilson.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0136db58
    • Chris Wilson's avatar
      drm/i915: Ironlake shares the same video sprite controls as Sandybridge · d1686ae3
      Chris Wilson authored
      Well, almost. Just a couple of differences, Ironlake lacks a few of the
      RGB formats, only exposing x8r8g8b8, and lacks a couple of unused
      features. Given the similarities, we can then reuse the same routines as
      already written for Sandybridge to enable overlay support for Ironlake as
      well.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d1686ae3
    • Daniel Kurtz's avatar
      drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers · e2ba4fb3
      Daniel Kurtz authored
      The POSTING_READ() calls were originally added to make sure the writes
      were flushed before any timing delays and across loops.
      Now that the code has settled a bit, let's remove them.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e2ba4fb3
    • Daniel Kurtz's avatar
      drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop · 90e6b26d
      Daniel Kurtz authored
      Save the GMBUS2 value read while polling for state changes, and then
      reuse this value when determining for which reason the loops were exited.
      This is a small optimization which saves a couple of bus accesses for
      memory mapped IO registers.
      
      To avoid "assigning in if clause" checkpatch errors", use a ret variable
      to store the wait_for macro return value.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      90e6b26d
    • Daniel Kurtz's avatar
      drm/i915/intel_i2c: use INDEX cycles for i2c read transactions · 56f9eac0
      Daniel Kurtz authored
      It is very common for an i2c device to require a small 1 or 2 byte write
      followed by a read.  For example, when reading from an i2c EEPROM it is
      common to write and address, offset or index followed by a reading some
      values.
      
      The i915 gmbus controller provides a special "INDEX" cycle for performing
      such a small write followed by a read.  The INDEX can be either one or two
      bytes long.  The advantage of using such a cycle is that the CPU has
      slightly less work to do once the read with INDEX cycle is started.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      56f9eac0
    • Daniel Kurtz's avatar
      drm/i915/intel_i2c: use WAIT cycle, not STOP · 72d66afd
      Daniel Kurtz authored
      The i915 is only able to generate a STOP cycle (i.e. finalize an i2c
      transaction) during a DATA or WAIT phase.  In other words, the
      controller rejects a STOP requested as part of the first transaction in a
      sequence.
      
      Thus, for the first transaction we must always use a WAIT cycle, detect
      when the device has finished (and is in a WAIT phase), and then either
      start the next transaction, or, if there are no more transactions,
      generate a STOP cycle.
      
      Note: Theoretically, the last transaction of a multi-transaction sequence
      could initiate a STOP cycle.  However, this slight optimization is left
      for another patch.  We return -ETIMEDOUT if the hardware doesn't
      deactivate after the STOP cycle.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      [danvet: added comment to the code that gmbus can't generate STOP on
      the very first cycle.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      72d66afd
    • Daniel Kurtz's avatar
      drm/i915/intel_i2c: always wait for IDLE before clearing NAK · e646d577
      Daniel Kurtz authored
      The GMBUS controller can report a NAK condition while a transaction is
      still active. If the driver is fast enough, and the bus is slow enough,
      the driver may clear the NAK condition while the controller is still
      busy, resulting in a confused GMBUS controller.  This will leave the
      controller in a bad state such that the next transaction may fail.
      
      Also, return -ENXIO if a device NAKs a transaction.
      
      Note: this patch also refactors gmbus_xfer to remove the "done" label.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      e646d577
    • Daniel Kurtz's avatar
      drm/i915/intel_i2c: use double-buffered writes · 7a39a9d4
      Daniel Kurtz authored
      The GMBUS controller GMBUS3 register is double-buffered.  Take advantage
      of this  by writing two 4-byte words before the first wait for HW_RDY.
      This helps keep the GMBUS controller from becoming idle during long writes.
      
      In fact, during experiments using the GMBUS interrupts, the HW_RDY
      interrupt would only trigger for transactions >4 bytes after 2 writes
      to GMBUS3.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7a39a9d4
    • Daniel Kurtz's avatar
      drm/i915/intel_i2c: handle zero-length writes · 26883c31
      Daniel Kurtz authored
      A common method of probing an i2c bus is trying to do a zero-length write.
      Handle this case by checking the length first before decrementing it.
      
      This is actually important, since attempting a zero-length write is one
      of the ways that i2cdetect and i2c_new_probed_device detect whether
      there is device present on the bus with a given address.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      26883c31
    • Jesse Barnes's avatar
      drm/i915: use register name when disabling VGA · 3fdcf431
      Jesse Barnes authored
      Just noticed this while verifying the VGA disable code.
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      3fdcf431
    • Ben Widawsky's avatar
      drm/i915: use semaphores for the display plane · 2911a35b
      Ben Widawsky authored
      In theory this will have performance and power improvements. Performance
      because we don't need to stall when the scanout BO is busy, and power
      because we don't have to stall when the BO is busy (and the ring can
      even go to sleep if the HW supports it).
      
      v2:
      squash 2 patches into 1 (me)
      un-inline the enable_semaphores function (Daniel)
      remove comment about SNB hangs from i915_gem_object_sync (Chris)
      rename intel_enable_semaphores to i915_semaphore_is_enabled (me)
      removed page flip comment; "no why" (Chris)
      
      To address other comments from Daniel (irc):
      update the comment to say 'vt-d is crap, don't enable semaphores'
        - I think you misinterpreted Chris' comment, it already exists.
      checking out whether we can pageflip on the render ring on ivb (didn't
      work on early silicon)
        - We don't want to enable workarounds for early silicon unless we have
          to.
        - I can't find any references in the docs about this.
      optionally use it if the fb is already busy on the render ring
        - This should be how the code already worked, unless I am
          misunderstanding your meaning.
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      2911a35b
    • Chris Wilson's avatar
      drm/i915: Reorganise rules for get_fence/put_fence · 9a5a53b3
      Chris Wilson authored
      By simplifying the rules to calling get_fence when writing to the
      through the GTT in a tiled manner, and calling put_fence before writing
      to the object through the GTT in a linear manner, the code becomes
      clearer and there is less chance of making a mistake.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      [danvet: fixed up conflict with ppgtt code and spelling in a new
      comment.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9a5a53b3
    • Ben Widawsky's avatar
      drm/i915: add rc6 residency times to debugfs · cce66a28
      Ben Widawsky authored
      RC6 residency should be in intervals of 1.28us, and the counter wraps.
      Here is an example using awk to get the various RC6 and RC6+ residency
      times in seconds, since boot.
      
      cat /sys/kernel/debug/dri/0/i915_drpc_info  | grep residency | awk -F':' -F' '  '{print $5 * 1.28 / 1000000}'
      
      This is primarily for QA, but has other applications as well. An
      upcoming patch to add interfaces should be more interesting to
      application developers.
      
      v2: move comment to the correct place
      
      v3: display with %u instead of %d, for Ouping
      
      CC: Ouping Zhang <ouping.zhang@intel.com>
      Reviewed-by: default avatarEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: default avatarBen Widawsky <benjamin.widawsky@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      cce66a28
    • Dave Airlie's avatar
      Merge branch 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next · effbc4fd
      Dave Airlie authored
      Daniel Vetter wrote
      First pull request for 3.5-next, slightly large than usual because new
      things kept coming in since the last pull for 3.4.
      Highlights:
      - first batch of hw enablement for vlv (Jesse et al) and hsw (Eugeni). pci
       ids are not yet added, and there's still quite a few patches to merge
       (mostly modesetting). To make QA easier I've decided to merge this stuff
       in pieces.
      - loads of cleanups and prep patches spurred by the above. Especially vlv
       is a real frankenstein chip, but also hsw is stretching our driver's
       code design. Expect more to come in this area for 3.5.
      - more gmbus fixes, cleanups and improvements by Daniel Kurtz. Again,
       there are more patches needed (and some already queued up), but I wanted
       to split this a bit for better testing.
      - pwrite/pread rework and retuning. This series has been in the works for
       a few months already and a lot of i-g-t tests have been created for it.
       Now it's finally ready to be merged.  Note that one patch in this series
       touches include/pagemap.h, that patch is acked-by akpm.
      - reduce mappable pressure and relocation throughput improvements from
       Chris.
      - mmap offset exhaustion mitigation by Chris Wilson.
      - a start at figuring out which codepaths in our messy dri1/ums+gem/kms
       driver we actually need to support by bailing out of unsupported case.
       The driver now refuses to load without kms on gen6+ and disallows a few
       ioctls that userspace never used in certain cases. More of this will
       definitely come.
      - More decoupling of global gtt and ppgtt.
      - Improved dual-link lvds detection by Takashi Iwai.
      - Shut up the compiler + plus fix the fallout (Ben)
      - Inverted panel brightness handling (mostly Acer manages to break things
       in this way).
      - Small fixlets and adjustements and some minor things to help debugging.
      
      Regression-wise QA reported quite a few issues on ivb, but all of them
      turned out to be hw stability issues which are already fixed in
      drm-intel-fixes (QA runs the nightly regression tests on -next alone,
      without -fixes automatically merged in). There's still one issue open on
      snb, it looks like occlusion query writes are not quite as cache coherent
      as we've expected. With some of the pwrite adjustements we can now
      reliably hit this. Kernel workaround for it is in the works."
      
      * 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits)
        drm/i915: VCS is not the last ring
        drm/i915: Add a dual link lvds quirk for MacBook Pro 8,2
        drm/i915: make quirks more verbose
        drm/i915: dump the DMA fetch addr register on pre-gen6
        drm/i915/sdvo: Include YRPB as an additional TV output type
        drm/i915: disallow gem init ioctl on ilk
        drm/i915: refuse to load on gen6+ without kms
        drm/i915: extract gt interrupt handler
        drm/i915: use render gen to switch ring irq functions
        drm/i915: rip out old HWSTAM missed irq WA for vlv
        drm/i915: open code gen6+ ring irqs
        drm/i915: ring irq cleanups
        drm/i915: add SFUSE_STRAP registers for digital port detection
        drm/i915: add WM_LINETIME registers
        drm/i915: add WRPLL clocks
        drm/i915: add LCPLL control registers
        drm/i915: add SSC offsets for SBI access
        drm/i915: add port clock selection support for HSW
        drm/i915: add S PLL control
        drm/i915: add PIXCLK_GATE register
        ...
      
      Conflicts:
      	drivers/char/agp/intel-agp.h
      	drivers/char/agp/intel-gtt.c
      	drivers/gpu/drm/i915/i915_debugfs.c
      effbc4fd
    • Dave Airlie's avatar
      drm/radeon/kms: attempt to avoid copying data twice on coherent cards. (v3) · 6a7068b4
      Dave Airlie authored
      On coherent systems (not-AGP) the IB should be in cached memory so should
      be just as fast, so we can avoid copying to temporary pages and just use it
      directly.
      
      provides minor speedups on rv530: gears ~1820->1860, ipers: 29.9->30.6,
      but always good to use less CPU if we can.
      
      v3: cleanup unneeded bits.
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      6a7068b4
    • Dave Airlie's avatar
      drm/radeon: enable pci bus mastering after card is initialised (v2) · 2099810f
      Dave Airlie authored
      This closes a race seen with kexec where we enable PCI bus mastering
      but the card has been reinitialised fully yet.
      
      This was previously fixed by a patch from Jerome, but this should
      close the race completely.
      
      v2: add SI support as suggested by Alex.
      Reported-and-tested-by: default avatarMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      2099810f
  2. 09 Apr, 2012 20 commits