1. 10 10月, 2013 1 次提交
    • T
      drm/i915: Finish enabling rps before use by sysfs or debugfs · 5c9669ce
      Tom O'Rourke 提交于
      Enabling rps (turbo setup) was put in a work queue because it may
      take quite awhile.  This change flushes the work queue to initialize
      rps values before use by sysfs or debugfs.  Specifically,
      rps.delayed_resume_work is flushed before using rps.hw_max,
      rps.max_delay, rps.min_delay, or rps.cur_delay.
      
      This change fixes a problem in sysfs where show functions using
      uninitialized values show incorrect values and store functions
      using uninitialized values in range checks incorrectly fail to
      store valid input values.  This change also addresses similar use
      before initialized problems in debugfs.
      Signed-off-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5c9669ce
  2. 01 10月, 2013 1 次提交
  3. 21 9月, 2013 1 次提交
  4. 20 9月, 2013 6 次提交
    • J
      drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYT · 5ffd494b
      Jesse Barnes 提交于
      Byt doesn't have rc6p and rc6pp support and even more important the
      the offsets of the residency registers there's something else. So Just
      return a constant 0 to avoid upsetting userspace tools like powertop.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      [danvet: Explain a bit in the commit message what's going on.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5ffd494b
    • B
      drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF · 040d2baa
      Ben Widawsky 提交于
      We'd only ever used this define to denote whether or not we have the
      dynamic parity feature (DPF) and never to determine whether or not L3
      exists. Baytrail is a good example of where L3 exists, and not DPF.
      
      This patch provides clarify in the code for future use cases which might
      want to actually query whether or not L3 exists.
      
      v2: Add /* DPF == dynamic parity feature */
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      040d2baa
    • B
      drm/i915: Do remaps for all contexts · 3ccfd19d
      Ben Widawsky 提交于
      On both Ivybridge and Haswell, row remapping information is saved and
      restored with context. This means, we never actually properly supported
      the l3 remapping because our sysfs interface is asynchronous (and not
      tied to any context), and the known faulty HW would be reused by the
      next context to run.
      
      Not that due to the asynchronous nature of the sysfs entry, there is no
      point modifying the registers for the existing context. Instead we set a
      flag for all contexts to load the correct remapping information on the
      next run. Interested clients can use debugfs to determine whether or not
      the row has been remapped.
      
      One could propose at this point that we just do the remapping in the
      kernel. I guess since we have to maintain the sysfs interface anyway,
      I'm not sure how useful it is, and I do like keeping the policy in
      userspace; (it wasn't my original decision to make the
      interface the way it is, so I'm not attached).
      
      v2: Force a context switch when we have a remap on the next switch.
      (Ville)
      Don't let userspace use the interface with disabled contexts.
      
      v3: Don't force a context switch, just let it nop
      Improper context slice remap initialization, 1<<1 instead of 1<<i, but I
      rewrote it to avoid a second round of confusion.
      Error print moved to error path (All Ville)
      Added a comment on why the slice remap initialization happens.
      
      CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3ccfd19d
    • B
      drm/i915: Make l3 remapping use the ring · c3787e2e
      Ben Widawsky 提交于
      Using LRI for setting the remapping registers allows us to stream l3
      remapping information. This is necessary to handle per context remaps as
      we'll see implemented in an upcoming patch.
      
      Using the ring also means we don't need to frob the DOP clock gating
      bits.
      
      v2: Add comment about lack of worry for concurrent register access
      (Daniel)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Bikeshed the comment a bit by doing a s/XXX/Note - there's
      nothing to fix.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c3787e2e
    • B
      drm/i915: Add second slice l3 remapping · 35a85ac6
      Ben Widawsky 提交于
      Certain HSW SKUs have a second bank of L3. This L3 remapping has a
      separate register set, and interrupt from the first "slice". A slice is
      simply a term to define some subset of the GPU's l3 cache. This patch
      implements both the interrupt handler, and ability to communicate with
      userspace about this second slice.
      
      v2:  Remove redundant check about non-existent slice.
      Change warning about interrupts of unknown slices to WARN_ON_ONCE
      Handle the case where we get 2 slice interrupts concurrently, and switch
      the tracking of interrupts to be non-destructive (all Ville)
      Don't enable/mask the second slice parity interrupt for ivb/vlv (even
      though all docs I can find claim it's rsvd) (Ville + Bryan)
      Keep BYT excluded from L3 parity
      
      v3: Fix the slice = ffs to be decremented by one (found by Ville). When
      I initially did my testing on the series, I was using 1-based slice
      counting, so this code was correct. Not sure why my simpler tests that
      I've been running since then didn't pick it up sooner.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      35a85ac6
    • B
      drm/i915: Fix HSW parity test · 1c966dd2
      Ben Widawsky 提交于
      Haswell changed the log registers to be WO, so we can no longer read
      them to determine the programming (which sucks, see later note). For
      now, simply use the cached value, and hope HW doesn't screw us over.
      
      v2: Simplify the logic to avoid an extra !, remove last, and fix the
      buffer offset which broke along the rebase (Ville)
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441
      CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1c966dd2
  5. 13 9月, 2013 2 次提交
  6. 03 9月, 2013 1 次提交
  7. 02 7月, 2013 1 次提交
  8. 24 5月, 2013 2 次提交
  9. 11 5月, 2013 1 次提交
  10. 18 4月, 2013 3 次提交
    • J
      drm/i915: turbo & RC6 support for VLV v7 · 0a073b84
      Jesse Barnes 提交于
      Uses slightly different interfaces than other platforms.
      
      v2: track actual set freq, not requested (Rohit)
          fix debug prints in init code (Jesse)
      v3: don't write sleep reg (Jesse)
          re-add RC6 wake limit write (Ben)
          fixup thresholds to match other platforms (Ben)
          clean up mem freq calculation (Ben)
          clean up debug prints (Ben)
      v4: move defines from punit patch (Ville)
      v5: remove writes to nonexistent regs (Jesse)
          put RP and RC regs together (Jesse)
          fix RC6 enable (Jesse)
      v6: use correct fuse reads from NC (Jesse)
          split out min/max funcs for use in sysfs (Jesse)
          add debugfs & sysfs freq controls (Jesse)
      v7: update with Ben's hw_max changes (Jesse)
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6)
      [danvet: Follow checkpatch sugggestion to use min_t to avoid casting
      fun.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0a073b84
    • M
      drm/i915: Return stored value from max freq sysfs entry · 182642b0
      Mika Kuoppala 提交于
      commit 4f9b2fe0441d4bdf5666a306156b5d6755de2584
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Fri Apr 5 14:29:22 2013 -0700
      
          drm/i915: Better overclock support
      
      changed the sysfs read semantics for 'gt_max_freq_mhz'. By
      always returning overclock max instead of stored value.
      
      Fix this by returning the stored value. Separate sysfs entry
      should be considered for overclocking max freq.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63415
      Cc: Ben Widawsky <ben@bwidawsk.net>
      Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      182642b0
    • B
      drm/i915: Better overclock support · 31c77388
      Ben Widawsky 提交于
      Most importantly this will allow users to set overclock frequencies in
      sysfs. Previously the max was limited by the RP0 max as opposed to the
      overclock max. This is useful if one wants to either limit the max
      overclock frequency, or set the minimum frequency to be in the overclock
      range. It also fixes an issue where if one sets the max frequency to be
      below the overclock max, they wouldn't be able to set back the proper
      overclock max.
      
      In addition I've added a couple of other bits:
      Show the overclock freq. as max in sysfs
      Print the overclock max in debugfs.
      Print a warning if the user sets the min frequency to be in the
      overclock range.
      
      In this patch I've decided to store the hw_max when we read it from the
      pcode at init. The reason I do this is the pcode reads can fail, and are
      slow.
      
      v2: Report when user requested overclocked max (Daniel)
      Remove when user sets min to overclock range (Daniel)
      
      Reported-by: freezer from #intel-gfx on irc
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
      [danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
      that Mika spotted.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      31c77388
  11. 20 2月, 2013 1 次提交
  12. 06 12月, 2012 1 次提交
  13. 12 11月, 2012 2 次提交
  14. 20 9月, 2012 5 次提交
  15. 06 9月, 2012 1 次提交
    • B
      drm/i915: Enable some sysfs stuff without CONFIG_PM · 8c3f929b
      Ben Widawsky 提交于
      The original patch was actually incorrect in stubbing out the sysfs for
      l3 parity.
      commit 5ab3633d
      Author: Hunt Xu <mhuntxu@gmail.com>
      Date:   Sun Jul 1 03:45:07 2012 +0000
      
          drm/i915: make rc6 in sysfs functions conditional
      
      Unfortunately Hunt didn't respond to my review comments, and Daniel
      sucked in the patch again ignoring. Worst of all, I'm too lazy to write
      the patch for what I originally wanted, which was to keep rc6 sysfs even
      without CONFIG_PM. This simpler patch does enough to enable us to add
      more sysfs entries though.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      8c3f929b
  16. 07 8月, 2012 1 次提交
  17. 26 7月, 2012 1 次提交
    • B
      drm/i915: Macro to determine DPF support · e1ef7cc2
      Ben Widawsky 提交于
      Originally I had a macro specifically for DPF support, and Daniel, with
      good reason asked me to change it to this. It's not the way I would have
      gone (and indeed I didn't), but for now there is no distinction as all
      platforms with L3 also have DPF.
      
      Note: The good reasons are that dpf is a l3$ feature (at least on
      currrent hw), hence I don't expect one to go without the other.
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      [danvet: added note]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e1ef7cc2
  18. 01 6月, 2012 1 次提交
  19. 31 5月, 2012 1 次提交
    • B
      drm/i915: l3 parity sysfs interface · 84bc7581
      Ben Widawsky 提交于
      Dumb binary interfaces which allow root-only updates of the cache
      remapping registers. As mentioned in a previous patch, software using
      this interface needs to know about HW limits, and other programming
      considerations as the kernel interface does no checking for these things
      on the root-only interface.
      
      v1: Drop extra posting reads (Chris)
      Return negative values in the sysfs interfaces on errors (Chris)
      
      v2: Return -EINVAL for offset % 4 (Jesse)
      Move schizo userspace check out (Jesse)
      Cleaner sysfs item initializers (Daniel)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      84bc7581
  20. 23 4月, 2012 1 次提交
  21. 13 4月, 2012 1 次提交
    • B
      drm/i915: rc6 in sysfs · 0136db58
      Ben Widawsky 提交于
      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: NBen Widawsky <benjamin.widawsky@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [danvet: squash in the 64bit division fix by Chris Wilson.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0136db58